🚀 Cmder's next major release backlog

[DRSDavidSoft]

Upcoming plans for the next major release of Cmder

Currently, there are some areas of Cmder that could benefit from a smoother experience for the first-time user.

Highlights: Remove old 32-bit support. Installing to Program Files or any other path with spaces and/or lack of permissions will be correctly handled. Improvements to the speed, look and feel of the project.

📌 Please vote for your preferred Terminal to be used with Cmder in #2864
New! Cmder now comes in two flavors, Cmder + ConEmu (the classic terminal) and Cmder + Windows Terminal. More discussion at #2878
You can also choose to download Cmder Launcher, a build of Cmder without a bundled terminal emulator. It is a great choice for using Cmder as a shell profile in any terminal you like (formerly discussed as "Cmder for Windows" or "cmder4win").

The v1.2.x releases are the last one to support Windows 7 as it has been EOL'd for quite a while now by Microsoft; and the biggest burden to continue supporting it is the dependencies we use themselves. With Git-for-windows project dropping support for it, I see no reason to continue Windows 7 support unless a user specifically request it.

We will be either completely dropping x86 (32-bit) binaries that are included in the package (e.g. both ConEmu and Clink has those), or alternatively consider providing an optional launcher file that is capable of running under 32-bit.

• Preprations for merging `development` to `master` #2878 Cmder development merge with master
  • Optimizations for improving speed #2825 Great optimizations for speed!
  • Windows Terminal Support #2877 Support Windows-Terminal
  • Implemented in Merging Cmder's development branch to master branch #2898
• Support Windows 11 New Shell Context Menu
• Include fzf and clink-fzf ([Feature request] fzf integration #2927) as well as clink-gizmos
• Include "rsync" from pacman package in the Cmder Full edition
• Properly handle spaces in CMDER_ROOT path in all areas (shells, launcher, etc)
• Use absolute path to findstr and doskey to avoid 'doskey' is not recognized as an internal or external command, operable program or batch file. #795 and similar
• Minimize and reduce the need for creating any temporary files (ref. [Bug] "Could Not Find C:\Users\abc\AppData\Local\Temp\cmder_lib_pathA" gets output when terminal opens #2990 (comment))
• Detect and deal with lack of permissions (e.g. handle Access Denied) (e.g. Failed to copy ConEmu.xml.default file at launch #2092)
  • Only the config directory should be writable by the user (Everyone:Write), all other directories must only work with Everyone:Read
  • Handle cases where Cmder is unable to create user config from default templates
• Better UI for the first time start
  • Use terminal colors to decorate the initial setup and indicate the result (success, failure)
  • Ability to run the git post-install in the background or new tab
  • Fix issue where user might be mislead by git post-install output ([Enhancement] First time Git Installation error is misleading: The batch file cannot be found #2980)
  • Disable some of the initial setup checks and post installs when the /f parameter is used
  • Fix issue when the PATH might contains illegal (") character [Bug] Issue with Cmder's first run when the PATH env variable contains double quotation (") character #2999
  • Additionally, implement changes from git-prompt.sh: remove annoying space when MSYSTEM not set git-for-windows/build-extra#472 and git-prompt.sh: remove duplicate space when $MSYSTEM not set git-for-windows/build-extra#625 by modifying/patching our https://github.com/cmderdev/cmder/blob/master/vendor/git-prompt.sh file due to uncooperativeness (The double space issue is already solved in Cmder, but as a side effect the MSYSTEM won't be shown, even if set)
• Provide installer (i.e. Provide Installer for Cmder (such as .msi package) #2729) and config tweak utility to the user
  • Installer must have options: system, user, portable
  • Allow selection of either shared or per-profile config storage
  • Ability to apply common tweaks through the CLI or first install
    • e.g. set the CMDER_ROOT env var when the project is installed
    • e.g. ability to add Cmder profile to VS Code and/or Windows Terminal
• Provide an update mechanism to auto update Cmder core itself along the dependencies
  (Updating Cmder, not just ConEmu and showing version #2875, discussions in [Feature request] Discussing the auto self updater in Cmder #3066) + Automatically apply vendor updates without breaking vendored dependencies (using a script to either fetch the latest Cmder zip package and extract each vendored directory and replace it in Cmder; and/or a script to fetch each vendored from their releases and replace them in Cmder. Using git commands like how scoop does them would also be nice)
• Add support for automatic git update notifications, see https://gitforwindows.org/faq.html#how-do-i-update-git-for-windows-upon-new-releases for git update-git-for-windows and implement in our Pacman scripts
• Unified config store (e.g. for prompt) (Modifying [cmder_prompt_config.lua] does not change "λ" prompt in bash/powershell #2716, How to store configuration #1695)
• Support core features for ARM64 (cmd.exe without Clink, PowerShell, bash), (probably in Windows Terminal instead of ConEmu) (Support for ARM64 (Windows 10/11) #2633)
• Consider adding WinGet support for easier installation ([Feature Request] Add Cmder to Winget #2552)
• Update/improve documentation
  • Split and move README.md entries to either separate files, or Wiki when suitable
  • Refresh screenshots used in README.md and the Website
  • Refresh documentation regarding features, and remove outdated info;
    Check if any part of the README.md is stale now, it needs to be modified/removed to match the current state

I propose organizing cluttered information from the README.md into groups. I'd like to move details from README.md into the Wiki and keep README.md simple and clean, and provide links to the Wiki in the README.md. Besides being more organized, this also allows us to update the documentation more frequently and also make use of community edits. I will monitor changes for possible vandalism.

We are in favor of completely removing 32-bit support from Cmder to reduce the size and improve simplicity. This also involves updating the init.bat to de-reference x86 32-bit in it. In my opinion, the only supported arches in init.bat should be x86_64, ARM and ARM64. (Hopefully ARM32 will also be deprecated soon). Preferably this should be done now since git-for-windows has already dropped 32-bit support. If the core team accepts, I'll modify the vendor scripts to strip any x84 32-bit editions of the vendored dependencies.

I can only recall one individual that was still using a 32-bit machine and was asking for this.

Additional Notes

Note 1: We're in the process of improving Cmder's initialization speed. In the next major release, the loading time is expected to be optimized significantly.

Note 2: Cmder is in the process of dropping 32-bit support of x86 edition when the upstream projects (such as Git-for-Windows) do so. In the next major releases of Cmder, the minimum Windows requirement will be bumped from Windows 7 SP1 to Windows 10, as well.

[daxgames]

• Properly handle spaces in CMDER_ROOT path in all areas (shells, launcher, etc

I was not aware this was a problem. I thought we handled spaces quite well

• Detect and deal with lack of permissions

Just default to putting the config folder in the users home folder when this happens. More secure this way anyway given the possible content of this folder. If cmder is not in the user home folder the config folder should be by default.

• Installer - WHY, ITS PORTABLE?

• Update mechanism - WHY, ITS PORTABLE?

[DRSDavidSoft]

@daxgames

• Properly handle spaces in CMDER_ROOT path in all areas (shells, launcher, etc

  I was not aware this was a problem. I thought we handled spaces quite well

  I haven't seen any issues with Cmder itself behaving incorrectly with paths that contain spaces. However, there are some pointers in our docs (e.g. README and the Wiki) that states issues with spaces in paths, I believe those needs to be removed after some testing to make sure there is no issues whatsoever with spaces in paths. There are improvements to be done regarding integration docs with other tools when pointing users to use our scripts.

• Detect and deal with lack of permissions

  Just default to putting the config folder in the users home folder when this happens. More secure this way anyway given the possible content of this folder. If cmder is not in the user home folder the config folder should be by default.

  This seems the correct approach to implement, I haven't yet started on it but I believe adding support for a pre-defined config path located in AppData would be a nice feature to have, especially if we add "installation" support like many people ask.

• Installer

  WHY, ITS PORTABLE?

  Good question, currently Cmder is only offered as a "portable"-only application for users.

  This means that there are no installers to be used, the user needs to manually download the ZIP file containing Cmder, extract them to an arbitrary place of their choosing, and if needed, adjust the security settings, add a custom shortcut to Desktop, add profiles to WT, register the context menu handlers, and configure the prompt using the config files.

  When there is no need for Cmder, the user has to go through these steps in reverse: un register the context menu handler, delete any custom made shortcuts, remove the WT profiles, and so on.

  Essentially, the concept of installers and uninstallers where made as a wizard that would facilitate the steps I outlined for the average user. As a power user, I wouldn't mind doing many of the steps above manually. There are also cases where Cmder is truly used in a portable fashion: moved between machines, kept on a USB stick, a network share, or cloud software. The same can't be said about the people who prefer to actually install Cmder in a permanent way on their systems, they don't plan to move Cmder files around. They just expect a wizard to guide them through some configuration steps, and upon clicking the Next > buttons, be able to use Cmder instantaneously. It's part of the user experience they have come to expect.

  Think about ConEmu and Git for Windows. Wouldn't you say that those applications can also be used in a portable way? In fact, we are doing the same thing when we bundle them in Cmder. However, it's not to say that those are portable applications, per se. Git for Windows has an excellent installation wizard, which guide the user to allow them to configure many parts of their Git installation to their liking. The same goes for the ConEmu installer, it allows an easy and intuitive wizard to take care of adding the directories to Program Files and the shortcut to remove ConEmu on a later date. The ability to "uninstall" the program is seen as a feature by the end users, and the installers provide the utility to "uninstall" the programs.

• Update mechanism

  WHY, ITS PORTABLE?

  That's another very good question. The reason is quite simple.

  Currently, when we publish newer versions of Cmder -- which might contain changes to the core code, such as the launcher, the batch scripts, and so on -- the user is expected to download and unpack a fresh ZIP archive each time.

  In the age of package managers, this is simply an unacceptable approach. Picture this: In a time where computers had limited network connectivity, it made sense to publish new installation packages for each software. When the internet connectivity sky rocketed and machines started to become always-online systems, people started to recognise the value of software that had the auto-update functionality: instead of the user manually checking if there is a newer version for the software, manually downloading and manually extracting the archive, the software itself would take care of this.

  If people had to download each new version of WT manually and extract them, it would make for an uncomfortable and unpleasant feeling, resulting in many users choosing not to update their WT installation, or doing so on a long interval basis.

  Both ConEmu and Clink has this feature. Even Git for Windows. This means that when users launch Cmder, they are bombarded with messages from different components of Cmder, asking them to update that particular component.

  This means the Cmder will be left out; if a user chooses to update Clink and ConEmu, they will for sure be missing on the great clink-completions additions that chris works so hard on. They will miss on the improvements to the Cmder core components and batch scripts.

  Even worse, in the age of package managers, many people simply opt for installing WT, VS Code, and maybe even WSL from some sort of a package manager, on Windows. They expect the package manager to manage the installed packages for them, including updating the package to benefit from all the great additions.

  Now, to a user that already has some sort of terminal setup, the features of Cmder might be useful, if those can be integrated into their terminal of choosing. Should they be forced to resort to downloading a ZIP package each time to benefit from updates?

  I argue, it would be beneficial, if Cmder also would contain some sort of small update mechanism to download the latest and greatest changes from the releases and unpack them for the user.

---

These are just my opinions on the matter, based on user input and the current experience. I would not ever suggest altering the current, nice portable package that we offer. That will stay. However, I suggest providing the users with the installer that they ask as well. This will be a separate CmderSetup.exe downloadable file that will present the user with the installation wizard and take them through the steps that they have come to expect.

Adding an update mechanism will be a huge time saver, allowing Cmder to benefit from a unified and concise approach to avoid visiting the Downloads page each time there is a nice addition to Cmder, or part of its bundled packages, such as clink-additions.

Thank you for listening to my opinions, sorry for the long wall of text.

[daxgames]

Can we just stop making changes and get this released now since the master branch is horribly broken with ConEmu in it.

Download the current Master release open a file in vim and it doesn't even display it's horrible.

I've been using up a branch based on the development Branch for years and it works great

Let's get it released and start making incremental changes AND releases again this has been a development project for a couple of years now.

[daxgames]

@DRSDavidSoft An addendum to the above.

• Detect and deal with lack of permissions

Just default to putting the config folder in the users home folder when this happens. More secure this way anyway given the possible content of this folder. If cmder is not in the user home folder the config folder should be by default.

We need to also be cognizant there are people that install Cmder as a managed install with a Global config folder located in the Cmder Root folder and User config folders specified by the /c [folder] argument.

This config loads the managed config from the Global config folder then loads the user config from the user config folder. It allows a shared configuration while allowing an individual to customize it to their own liking.

[chrisant996]

Can we just stop making changes and get this released now since the master branch is horribly broken with ConEmu in it.

Hear, hear! 😎

I don't actually use Cmder, but I spend time investigating and trying to support Clink in ConEmu. But ConEmu is a collection of hacks that were necessary in Windows 7, and the hacks (1) don't work well anymore and (2) aren't even needed anymore with the ConPTY architecture that Windows introduced in Windows 10 (and which is used by Windows Terminal, WezTerm, Alacritty, Terminus, and Tabby).