🚀 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.

TL;DR: 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.
You can also choose to download a very slim version of Cmder, which doesn't come with a bundled terminal and is a great choice for using as a shell profile in any terminal you like.

• Optimizations for improving speed #2825 Great optimizations for speed!
• Windows Terminal Support #2877 Support Windows-Terminal
• Support Windows 11 New Shell Context Menu
• Include fzf and clink-fzf ([Feature request] fzf integration #2927) as well as clink-gizmos
• Properly handle spaces in CMDER_ROOT path in all areas (shells, launcher, etc)
• 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
  • Disable some of the initial setup checks and post installs when the /f parameter is used
• Provide installer (e.g. Improvements to shells and general fixes #2779) 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 update Cmder core itself along the dependencies
  (Updating CMDer, not just conemu and showing version #2875)
• 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

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 I just saw your comment now, sorry for replying late

• 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.