Related to #291, the idea is to detect more editors and offer them as a choice. For example, VS Code can be detected by looking at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\Code.exe\shell\open\command which should be of the form "C:\Program Files\Microsoft VS Code\Code.exe" "%1". We can take the presence of that registry entry as a hint that VS Code is installed, and also how to start it: we simply need to copy the value, substitute the trailing "%1" by --wait and use the result as the value of the Git config option core.editor.

More choices for editors (and how to configure core.editor) are listed here: https://stackoverflow.com/questions/2596805/how-do-i-make-git-use-the-editor-of-my-choice-for-commits

As the editor page is already pretty cramped, it would probably be a good idea to replace the radio buttons by a combobox.

This ticket is an excellent candidate for the Up For Grabs campaign.

So how to get started?

Install the Git for Windows SDK

When working on anything related to the Git for Windows installer, one needs a Git for Windows SDK. Currently, the easiest way to get one is to use the SDK installer.

This will download quite a bit of stuff, so you may want to grab a coffee or a tea or do something else entirely while this is running.

Once the SDK is done, you have a Git SDK Bash window, and also a Desktop shortcut to open the Git SDK Bash again. This will be the environment in which to work on the installer.

Test the Editor page of the installer

Pretty much all of the files, scripts and resources to build the installer are located in /usr/src/build-extra/, which corresponds to https://github.com/git-for-windows/build-extra, so go ahead and:

cd /usr/src/build-extra

You could now build an installer by calling ./installer/release.sh 0-test (which would generate a file called Git-0-test-64-bit.exe in your home directory), but that would take quite a while because it has to compress several hundred megabytes worth of files, and you would overwrite your current Git for Windows while testing it.

Therefore, we introduced a convenient method to work on the installer pages without doing all that stuff:

./installer/release.sh -d Editor

will build a tiny installer that won't actually install anything but show you just the Editor "wizard page" of the installer.

Time to go hack on that page...

Add a new editor option

Most of the installer is defined in the file installer/install.iss. Most notably, this file contains the code to generate the pages and to handle the selected options: in the case of the Editor page, it has to configure the core.editor Git config setting.

The code to generate the Editor page is located in the InitializeWizard procedure (InnoSetup, the system we use to generate our installers, uses a Pascal dialect as scripting language, where functions that do not have a return value are called procedures).

No worries about the language, any developer with a little knowledge of Javascript, Python or C will be able to read the code and modify it by following the example of the surrounding code.

To add support for VS Code, you simply need to follow the example of Notepad++: just search for NotepadPlusPlus and copy-edit the respective code:

• the global variable holding the path to the executable,
• the radio button,
• whether it should be enabled or not,
• how previous choices should be replayed,
• how the current choice should be recorded, and
• how core.editor is set if VS Code was picked by the user

Once you did that, run ./installer/release.sh -d Editor again, to see how it looks.

Please note: whenever you run into any problem with all of this, do not hesitate to ask away in this ticket (describing the problem in enough detail to follow what you did).

Replace the radio buttons on the Editor page by a combo box

Now, it may just be the case that a nice description of VS Code will be too long, that it will be cut off at the bottom of the installer page. The obvious solution is to switch to a combo box for the editor options, and to show only one description at a time.

So how do we go about replacing the radio button by a combobox? The relevant command is TNewComboBox.Create(Page). See e.g. https://stackoverflow.com/questions/31211733/inno-setup-combobox-how-to-store-access-values#31350903 for an example.

As there is no previous code in our installer to add a combobox, we will have to replace the calls to CreateRadioButton() (which abstract away quite a bit of functionality) by new, more verbose code.

To switch between descriptions, we would need to pull the code to generate a label (https://github.com/git-for-windows/build-extra/blob/c5a89e1f4928c2cf654ea426ce30d3e476001d7a/installer/install.iss#L923-L1039) out of the CreateRadioButton() function into its own function, say, CreateLabel(). This new function would need to be called several times, once for each editor description, resetting the Top variable after each call so that they would be all at the same location, setting the Visible attribute of the label to False so that none of them are shown at all, store all of these TLabels in a new array, and add an OnChange callback to show the current one (using the ItemIndex attribute of the combobox.

Of course, after figuring out which one is the current one, we also have to set the ItemIndex of the combobox accordingly.