Merging Cmder's development branch to master branch

[DRSDavidSoft]

Summary

This PR merges the current development branch on top of master and brings in the accumulated Cmder work since the last sync.

The biggest themes in this branch are:

• Windows Terminal support and related launcher/runtime updates
• A refactor of the build/pack scripts around package profiles
• Workflow/CI cleanup and consistency fixes
• A batch of shell, launcher, and configuration improvements
• Documentation and repo hygiene updates

What’s included

Windows Terminal support

This branch adds and refines support for launching Cmder in Windows Terminal, including:

• new/default Windows Terminal settings
• launcher updates in Cmder.bat and launcher/src/CmderLauncher.cpp
• new helper scripts for Git Bash, Mintty, and profile generation
• updates to shell integration files like vendor/cmder.sh, vendor/profile.ps1, and vendor/psmodules/Cmder.ps1
• support files for Windows Terminal defaults in vendor/windows_terminal_default_settings.json

Build and packaging refactor

The build system has been modernized to use package profiles and shared helpers:

• new scripts/package-profiles.json
• new helper logic in scripts/utils.ps1
• updated scripts/build.ps1, scripts/pack.ps1, and scripts/update.ps1
• refreshed examples and documentation in scripts/README.md

This makes the packaging flow more structured and easier to extend.

Workflow and CI updates

The GitHub Actions workflows were cleaned up and aligned with the new scripts:

• build workflow updates
• tests workflow updates
• CodeQL workflow updates
• vendor workflow updates
• summary formatting and artifact handling improvements

Cmder launcher and runtime improvements

This branch also includes a substantial update to the launcher and core runtime behavior:

• launcher project and resource updates
• CmderLauncher.cpp changes for the new launch flow
• improvements to Cmder.bat
• updates to vendor/init.bat, vendor/lib/lib_base.cmd, and vendor/lib/lib_path.cmd
• shell startup and environment setup cleanup

Documentation and repo hygiene

A number of documentation and maintenance updates are included as well:

• README.md and config/Readme.md adjustments
• CHANGELOG.md updates
• .gitignore and packignore additions
• .git-blame-ignore-revs for cleaner blame history

Notes

This branch is mostly a consolidation of the Windows Terminal work, launcher/runtime improvements, and packaging refactors that have been developed on development.

Verification

The updated workflows were run successfully on development, including:

• Build
• Tests
• CodeQL

Files touched

This merge includes changes across:

• GitHub Actions workflows
• build and pack scripts
• launcher source
• Cmder startup and shell integration scripts
• Windows Terminal defaults and profile generation
• documentation and changelog files

[daxgames]

@DRSDavidSoft Questions:

1. Why are you still persisting on changing init.bat to init.cmd it is COMPLETELY unnecessary.

2. The smallest distro is still called slim_mini, I think I have expressed my feelings on this name, I even offered alternative names that actually make sense and describe what the package contains.

   • Cmder for Windows: cmder_for_windows.zip
   • Cmder Launcher: cmder_launcher.zip

I have looked at your latest merges to development you seem to be attempting to re-invent the whell by writing, rewriting, and rewriting again the same workflows. Theses same workflows have been in a state of flux for many, many months.

They are NEVER going to be perfect. You said a couple of weeks ago you wanted one more 1.x.x release, presumably v1.4.0 but we are still at v1.3.25 and the pursuit of perfection is still delaying a release.

Can you just get master to where you want it with documented deprecation, a pending v2.0.0 breaking change warning in the README.md and lets release v1.4.0?

Possible future actions to speed releases while maintaining 1.x.x code base:

1. Copy master to main as you have suggested.
   • master can be retained for a while if necessary for v1.4.x BUGFIXES ONLY.
   • Remove the branchesand maybevendorworkflows frommaster`.
   • Possibly add a _1x or _legacy suffix to build packages in a parallel release of v2.x.x to distinguish them from current.
2. Modify development so its intended merge target is main.
   • Change all references from master to main.
3. Merge development into main.
4. Release v2.x.x.

I don't mean to sound like a broken record but I just want to release something.

[daxgames]

This is why changing init.bat to init.cmd for NO REASON is a HORRIBLE IDEA! All I did is sync the latest development branch and try to start a new shell.

[daxgames]

After a little research on the deep technical differences between .bat and .cmd the init.bat -> init.cmd change needs to be retained but modified for better user experience.

The ONLY way I can see this working is to include the shim in the repo rather than creating it on on first run with a nag message with a link to docs on how to update his/her terminal config via the gui to use init.cmd instead of init.bat. The nag message needs to be in init.batso it is only ever shown ifinit.bat` is called.

There should be no instruction to delete init.bat because it will be put back on EVERY future update to maintain backward compatibility. When the user changes their terminal config the nag goes away, no need to delete anything.

[daxgames]

After a little research on the deep technical differences between .bat and .cmd the init.bat -> init.cmd change needs to be retained but modified for better user experience.

The ONLY way I can see this working is to include the shim in the repo rather than creating it on on first run with a nag message with a link to docs on how to update his/her terminal config via the gui to use init.cmd instead of init.bat. The nag message needs to be in init.batso it is only ever shown ifinit.bat` is called.

There should be no instruction to delete init.bat because it will be put back on EVERY future update to maintain backward compatibility. When the user changes their terminal config the nag goes away, no need to delete anything.

I have made the changes to allow migration to init.cmd while using an included init.bat backward compatibility shim for a better user experience. See #3104

[DRSDavidSoft]

@daxgames

I'm preparing the remaining work as discussed and a proper reply to the points you raised in a separate comment. Here are some quick notes while working on this to avoid keeping this left unanswered.

• Will remove the "slim" name in the commits I'm preparing to push and apply the other fixes you pointed out too and revert regressions that I might have caused.
• Appreciate the bat/cmd investigation - I agree with your points, will answer all soon, as I have some notes to add about this topic.
• Focusing on getting the new release done ASAP and later working on the "legacy" branch that takes the place of the current master instead as requested, to avoid blocking the merge and making a new release.
• Doing some syncs between edits on my local machine in the meanwhile as I have unfinished work here, pulling the latest changes.
• Will be back with a detailed reply to your points with the work done.

Also, with the new pipeline and the CI/CD tasks, it will be easy to release different branches at the same time, so it makes sense to release a 2.0 before one more 1.x

Since 2.0 will semantically be a breaking change, I'll limit the scope of further updates to the dev branch until this PR is done, these will land in 2.1, 2.2, etc.

I don't mean to sound like a broken record but I just want to release something.

My apologizes, you're completely right and I appreciate it. The blame is on me as you correctly pointed out. Working to resolve the issues now, including reducing the perfectionism. 🙏🏻