Last Updated: 10/8/2016 Setting the Stage: The Need for an Extensibility Point As of the 1.1.0-insider release of Visual Studio Code, there is support for configuring which command shell launches […]
Last Updated: 10/8/2016
Setting the Stage: The Need for an Extensibility Point
As of the 1.1.0-insider release of Visual Studio Code, there is support for configuring which command shell launches upon selecting the “Open New Command Prompt” (Windows) or the “Open in Terminal” (Linux & OS X) option from Command Palette. It may come as no surprise that the default shell for Windows is cmd.exe. And by the way, this default command shell setting is also configurable for both Linux and Mac OS X users. We’ll focus on improving the quality of Windows users’ lives for the remainder of this blog post.
While Windows 10 introduced some welcomed improvements to the native command shell, it’s still not enough to get me excited. Developers’ expectations, in terms of usability and productivity, have evolved; cmd.exe has largely ignored the demand for an improved user experience. For various reasons, my favorite choice for Windows is still Cmder. After all, extensive theming capabilities, a tabbed interface, Git integration, and pasting via the Ctrl + V keyboard shortcut are features I expect to have. The blatantly honest vernacular on their website echoes the frustrations of Windows users around the world:
Cmder is a software package created out of pure frustration over the absence of nice console emulators on Windows.
Configuring the Editor to Launch Cmder
As is the case with virtually any setting within the editor, there exists two options for persisting such settings. If the reach of your changes is intended to be merely the current project, Workspace Settings is the appropriate configuration file. If, on the other hand, you’d like the setting applied system-wide, User Settings is most apposite. Either JSON-based settings file can be opened via the File -> Preferences menu.
After a program such as Cmder has been installed, the first critical step is to add it to the system’s Path environment variable. This is necessary so that Visual Studio Code can locate and launch its executable. In my case, Cmder was installed at C:\Program Files\Cmder. Consequently, a new entry corresponding to this path should be added to the system’s Path variable (see highlighted entry in screenshot).
Now that Visual Studio Code can locate the Cmder.exe file, configure the editor to launch it for every project on the system by going to File -> Preferences -> User Settings. A split-pane view will appear. In the left pane is a master list of settings which can be overridden. The right pane provides an opportunity to override settings. As a pro tip, you can easily traverse the contents of the left pane by setting your cursor there, opening Command Palette, and replacing “>” with “@“. After the “@“, simply type the name of the symbol to locate, and notice that the matches are filtered as you type.
In the aforementioned right pane, override the setting as follows:
Save the settings.json file, open Command Palette, select the “Open New Command Prompt“ command, and observe that Cmder is the new sheriff in town. No restart of Visual Studio Code is required.
Find below a screen capture demonstrating, from beginning to end, the configuring of Visual Studio Code to launch Cmder for all projects.
Extensibility is a wonderful thing, and sometimes it’s the smallest extensibility points that make a world of difference in your development workflow. I really think the Visual Studio Code team nailed it with this feature. My only feature request would be to allow for the passing of CLI parameters to the executable. Oh, and in case Cmder isn’t your command shell of choice, you can use PowerShell, Git Bash, or whatever else you desire. In the case of PowerShell, simply use the following in User Settings’ settings.json file: