How to Change Visual Studio Code Terminal Default Permanently [duplicate] - bash

When I woke up this morning and launched VSCode my default terminal on launch, and when running tasks is now powershell, instead of Git Bash. I am on windows. I have tried changing the settings.json to no avail. Is there something I'm missing?
{
"workbench.startupEditor": "newUntitledFile",
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
"[javascript]": {
"editor.defaultFormatter": "rvest.vs-code-prettier-eslint"
},
"aws.samcli.location": "C:\\Users\\king\\AppData\\Roaming\\npm\\sam.exe",
"typescript.updateImportsOnFileMove.enabled": "always",
"[html]": {
"editor.defaultFormatter": "vscode.html-language-features"
},
"editor.formatOnSave": true,
"editor.formatOnPaste": true,
"javascript.updateImportsOnFileMove.enabled": "always",
"explorer.confirmDragAndDrop": false,
"diffEditor.maxComputationTime": 0,
"extensions.ignoreRecommendations": true,
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.renderControlCharacters": true,
"[jsonc]": {
"editor.quickSuggestions": {
"strings": true
},
"editor.suggest.insertMode": "replace"
},
"window.zoomLevel": 0,
"editor.accessibilitySupport": "off",
"workbench.editor.untitled.hint": "hidden",
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.external.windowsExec": "C:\\Program Files\\Git\\bin\\bash.exe",
"terminal.explorerKind": "external",
"terminal.integrated.automationShell.linux": ""
}
I found this related SO post making the default powershell, but I didn't see anything that was incorrect about my setting...especially because my goal is the opposite- to stop Powershell!

Update: Version v1.60.0 had a bug. Upgrade to v1.60.1 or higher for a fix.
The bug manifested in the following symptoms:
The Open in Integrated Terminal shortcut-menu command in the Explorer pane's shortcut always uses the built-in default shell (PowerShell on Windows), ignoring the configured one.
The same goes for running tasks (with or without a separate terminal.integrated.automationShell.* setting).
Also, if a given folder or workspace happened to have an integrated terminal open when quitting Visual Studio Code, the shell that is launched when the integrated terminal automatically reopens the next time is again the built-in default shell, not the configured one. By contrast, if reopening doesn't auto-open the integrated terminal, opening it manually does respect the configured default shell, and so does manually creating another shell instance later.
See GitHub issue #132150
The following information turned out to be unrelated to the bug, but is hopefully still useful general information about Visual Studio Code's recent change in how shells for the integrated terminal are configured:
Migrating from the legacy default shell settings to shell profiles:
Recently, the "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings were deprecated and replaced with a more flexible model that allows defining multiple shells to select from, via so-called shell profiles, optionally defined in setting "terminal.integrated.profiles.*", with an associated mandatory "terminal.integrated.defaultProfile.*" setting referencing the name of the profile to use by default - which may be an explicitly defined custom profile or one of the built-in, platform-appropriate default profiles.
Note: * in the setting names above represents the appropriate platform identifier, namely windows, linux, or osx (macOS).
As of v1.60.1, if legacy "terminal.integrated.shell.*" settings are also present, the new settings take precedence (even though the tooltip when editing "terminal.integrated.shell.*" in settings.json suggests that this change is yet to come).
In the absence of both settings, Visual Studio Code's built-in default shell is used, which on Windows is PowerShell,[1] and on Unix-like platforms the user's default shell, as specified in the SHELL environment variable.
Recent Visual Studio Code versions, starting before v1.60 - seemingly as one-time opportunity - displayed a prompt offering to migrate the deprecated settings to the new ones.
Accepting the migration results in the following:
Creation of setting "terminal.integrated.shell.*" containing a custom shell profile derived from the values of legacy settings "terminal.integrated.shell.*" and, if present, "terminal.integrated.shellArgs.*"; that custom profile's name has the suffix (migrated)
Creation of setting terminal.integrated.defaultProfile.* whose value is the migrated profile's name, making it the default shell.
Removal of legacy settings "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*"
If you decline the migration, you can later effectively perform it by re-choosing the default shell, as described below.
Note: The new "terminal.integrated.defaultProfile.*" setting that is created in the process then effectively overrides the legacy "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings, but the latter won't be removed automatically. To avoid confusion, it's best to remove them from settings.json manually.
Choose the default shell profile to use in order to (re)specify the default shell:
Click on the down-arrow part of the shell-selector icon () on the right side of the integrated terminal, select Select Default Profile, which presents a list of the defined profiles to select the default from - in the absence of explicitly defined profiles, standard profiles are offered (see below).
This translates into a terminal.integrated.defaultProfile.* setting in settings.json, whose value is the name of the chosen shell profile - which may be the name of a built-in profile or one of the ones explicitly defined in "terminal.integrated.profiles.*"
Note: This shell is by default also used for tasks (defined in tasks.json), but that can be overridden with a "terminal.integrated.automationShell.*" setting pointing to the executable of an alternative shell.
Optionally, in your settings.json file, you may create a platform-appropriate terminal.integrated.profiles.* setting with shell profiles of interest:
Note: Even if your settings.json contains no (platform-appropriate) "terminal.integrated.profiles.*" setting, Visual Studio code has built-in standard profiles it knows of and offers them for selection when choosing the default shell.
These standard profiles are a mix of shells that come with the host platform as well as some that Visual Studio detects dynamically on a given system, such as Git Bash on Windows.
To create the standard profiles explicitly, do the following:
Note: You may choose to do this in order to customize the standard profiles. However, if your intent is merely to add custom profiles - see this answer for an example - it isn't necessary to create the standard profiles inside the "terminal.integrated.profiles.*" setting, because Visual Studio Code knows about them even if not explicitly defined.
Via File > Preferences > Settings (Ctrl-,), search for profiles and click on Edit in settings.json below the platform-appropriate Terminal > Integrated > Profiles > * setting; this will open settings.json for editing, with the standard profiles added; simply saving the file is sufficient.
Note: If the "terminal.integrated.profiles.*" setting shown doesn't contain the expected, platform-appropriate standard profiles, a setting by that name may already be present; to force creation of the standard profiles, remove or comment out the existing setting and save the file, then try again.
On Windows, you'll end up with something like the following:
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
"${env:windir}\\Sysnative\\cmd.exe",
"${env:windir}\\System32\\cmd.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
}
}
The answer you link to in your question, which provides an overview of the various types of shells used in Visual Studio Code, has been updated to reflect the information about the new shell profiles.
[1] Note: If a PowerShell (Core) v6+ installation is found, it takes precedence over the built-in Windows PowerShell version.

Edit:1
Note: Now this bug has been fixed by VSCode. Just update your VSCode to the latest version. (17-Sep-2021)
I have a temporary solution.
First paste this code in settings.json and save
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.integrated.profiles.windows": {
"C:\\Program Files\\Git\\bin\\bash.exe": {
"path": "",
"args": []
}
},
Before closing VSCode select Output instead of Terminal
Now you can open VSCode
After VSCode is loaded, you need to click on Terminal. After this you will now see bash.
Select output before whenever you close VSCode.
Reference: VSCode is suddenly defaulting to PowerShell for integrated terminal instead of $Bash in Windows
Note: This is not an solution. I shared this because maybe it can save you from getting disappointed.
This is my first post, if there is any mistake please let me know so that I can correct it.

You can always download and install previous releases from the official website https://code.visualstudio.com/updates/v1_59 (currently at the top).
As version 1.60 was bugged, v1.59 is a good candidate.
Disable automatic updates
Explained here.
Open User Settings File > Preferences > Settings.
Add "update.mode": "none" to your settings.
Install older version
Afterwards you can just overwrite current version with the installation of downloaded version.
Note: Wait for next version to fix it, so remember you had automatic update disabled!

I have same problem but I try run command prompt. I fix it by adding to ...\Code\User\settings.json
"terminal.integrated.automationShell.windows": "cmd.exe",

This could be related to issue 138999 which will add a mitigation/enhancement to VSCode 1.70 (July 2022) with PR 154290 and commit 91b82c0
increase barrier for available profiles to be ready
Wait up to 20 seconds for profiles to be ready so it's assured that we know the actual default terminal before launching the first terminal.
This isn't expected to ever take this long.
For VSCode with synchronized user settings, the profile might take more time than expected to fully load, hence the advantage of that workaround.

Simply replaced the CMD by Git Bash :-) in the settings.json
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
//"${env:windir}\\Sysnative\\cmd.exe",
//"${env:windir}\\System32\\cmd.exe"
"C:\\PrivateProgramms\\Git\\bin\\bash.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
//"path": [ "C:\\PrivateProgramms\\Git\\bin\\bash.exe" ],
//"args": [],
//"icon": "terminal-cmd"
}
},
"terminal.integrated.defaultProfile.windows": "Command Prompt"

Related

The Debugger in VS Code is starting but closing right after with no Terminal outputs

My Setup is the following:
I use a quite big python repository and code with VS Code with the following setup:
Version: 1.66.0 (user setup)
Commit: e18005f0f1b33c29e81d732535d8c0e47cafb0b5
Date: 2022-03-30T05:50:14.623Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: 9.8.177.11-electron.0
OS: Windows_NT x64 10.0.19041
Since yesterday the debugger doesn't start anymore. When I start it with the buttons or with F5, the debug toolbar shows up for a second and then it vanishes again. The normal run works perfectly, as well as when I run my file from a terminal.
I didn't really change something that I can remember, only that VS Code did an automatic update on Monday evening.
There is no Terminal output that I can show, since it is not opening a Debugging Console.
I used the debugger always directly from the file that I needed to debug and didn't specify any launch.json files.
What I already tried, is as mentioned using not the Debugger, but the Run command and started the files from a terminal outside of VS Code. Then my code runs as intended. But since I need the debugger for my work, this is not a good solution.
I also went back a few commits to the last step where I know it was working, but this didn't change it at all.
I tried to debug a simple "hello World" python script but there I have the same problem.
I used the automatic add configuration from VS Code and it added the following launch.json file to the .vscode folder in the repo. Together with this file it added a configuration called "Python: Aktuelle Datei" (german for current file). This also didn't help when I'm trying to launch it with this configuration.
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Python: Aktuelle Datei",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal",
"justMyCode": true
}
]
}
Is there anyone who encountered a similar issue?

Use "Terminal" instead of "Debug Console" as the I/O feed, when debugging in Visual Studio Code

Is it possible to debug Go files on VS code using the Terminal as the I/O feed for the debugging process instead of the Debug Console (like with Nodejs for example)? A special config on launch.json perhaps?
Current behavior:
Desired behavior:
"console": "integratedTerminal" or "console": "externalTerminal" in your launch.json configuration.
This is a relatively new feature that was added to Go extension v0.31.0 (Jan 2022).

How can I stop PowerShell integrated terminal from appearing on VScode startup? [duplicate]

When I woke up this morning and launched VSCode my default terminal on launch, and when running tasks is now powershell, instead of Git Bash. I am on windows. I have tried changing the settings.json to no avail. Is there something I'm missing?
{
"workbench.startupEditor": "newUntitledFile",
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
"[javascript]": {
"editor.defaultFormatter": "rvest.vs-code-prettier-eslint"
},
"aws.samcli.location": "C:\\Users\\king\\AppData\\Roaming\\npm\\sam.exe",
"typescript.updateImportsOnFileMove.enabled": "always",
"[html]": {
"editor.defaultFormatter": "vscode.html-language-features"
},
"editor.formatOnSave": true,
"editor.formatOnPaste": true,
"javascript.updateImportsOnFileMove.enabled": "always",
"explorer.confirmDragAndDrop": false,
"diffEditor.maxComputationTime": 0,
"extensions.ignoreRecommendations": true,
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.renderControlCharacters": true,
"[jsonc]": {
"editor.quickSuggestions": {
"strings": true
},
"editor.suggest.insertMode": "replace"
},
"window.zoomLevel": 0,
"editor.accessibilitySupport": "off",
"workbench.editor.untitled.hint": "hidden",
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.external.windowsExec": "C:\\Program Files\\Git\\bin\\bash.exe",
"terminal.explorerKind": "external",
"terminal.integrated.automationShell.linux": ""
}
I found this related SO post making the default powershell, but I didn't see anything that was incorrect about my setting...especially because my goal is the opposite- to stop Powershell!
Update: Version v1.60.0 had a bug. Upgrade to v1.60.1 or higher for a fix.
The bug manifested in the following symptoms:
The Open in Integrated Terminal shortcut-menu command in the Explorer pane's shortcut always uses the built-in default shell (PowerShell on Windows), ignoring the configured one.
The same goes for running tasks (with or without a separate terminal.integrated.automationShell.* setting).
Also, if a given folder or workspace happened to have an integrated terminal open when quitting Visual Studio Code, the shell that is launched when the integrated terminal automatically reopens the next time is again the built-in default shell, not the configured one. By contrast, if reopening doesn't auto-open the integrated terminal, opening it manually does respect the configured default shell, and so does manually creating another shell instance later.
See GitHub issue #132150
The following information turned out to be unrelated to the bug, but is hopefully still useful general information about Visual Studio Code's recent change in how shells for the integrated terminal are configured:
Migrating from the legacy default shell settings to shell profiles:
Recently, the "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings were deprecated and replaced with a more flexible model that allows defining multiple shells to select from, via so-called shell profiles, optionally defined in setting "terminal.integrated.profiles.*", with an associated mandatory "terminal.integrated.defaultProfile.*" setting referencing the name of the profile to use by default - which may be an explicitly defined custom profile or one of the built-in, platform-appropriate default profiles.
Note: * in the setting names above represents the appropriate platform identifier, namely windows, linux, or osx (macOS).
As of v1.60.1, if legacy "terminal.integrated.shell.*" settings are also present, the new settings take precedence (even though the tooltip when editing "terminal.integrated.shell.*" in settings.json suggests that this change is yet to come).
In the absence of both settings, Visual Studio Code's built-in default shell is used, which on Windows is PowerShell,[1] and on Unix-like platforms the user's default shell, as specified in the SHELL environment variable.
Recent Visual Studio Code versions, starting before v1.60 - seemingly as one-time opportunity - displayed a prompt offering to migrate the deprecated settings to the new ones.
Accepting the migration results in the following:
Creation of setting "terminal.integrated.shell.*" containing a custom shell profile derived from the values of legacy settings "terminal.integrated.shell.*" and, if present, "terminal.integrated.shellArgs.*"; that custom profile's name has the suffix (migrated)
Creation of setting terminal.integrated.defaultProfile.* whose value is the migrated profile's name, making it the default shell.
Removal of legacy settings "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*"
If you decline the migration, you can later effectively perform it by re-choosing the default shell, as described below.
Note: The new "terminal.integrated.defaultProfile.*" setting that is created in the process then effectively overrides the legacy "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings, but the latter won't be removed automatically. To avoid confusion, it's best to remove them from settings.json manually.
Choose the default shell profile to use in order to (re)specify the default shell:
Click on the down-arrow part of the shell-selector icon () on the right side of the integrated terminal, select Select Default Profile, which presents a list of the defined profiles to select the default from - in the absence of explicitly defined profiles, standard profiles are offered (see below).
This translates into a terminal.integrated.defaultProfile.* setting in settings.json, whose value is the name of the chosen shell profile - which may be the name of a built-in profile or one of the ones explicitly defined in "terminal.integrated.profiles.*"
Note: This shell is by default also used for tasks (defined in tasks.json), but that can be overridden with a "terminal.integrated.automationShell.*" setting pointing to the executable of an alternative shell.
Optionally, in your settings.json file, you may create a platform-appropriate terminal.integrated.profiles.* setting with shell profiles of interest:
Note: Even if your settings.json contains no (platform-appropriate) "terminal.integrated.profiles.*" setting, Visual Studio code has built-in standard profiles it knows of and offers them for selection when choosing the default shell.
These standard profiles are a mix of shells that come with the host platform as well as some that Visual Studio detects dynamically on a given system, such as Git Bash on Windows.
To create the standard profiles explicitly, do the following:
Note: You may choose to do this in order to customize the standard profiles. However, if your intent is merely to add custom profiles - see this answer for an example - it isn't necessary to create the standard profiles inside the "terminal.integrated.profiles.*" setting, because Visual Studio Code knows about them even if not explicitly defined.
Via File > Preferences > Settings (Ctrl-,), search for profiles and click on Edit in settings.json below the platform-appropriate Terminal > Integrated > Profiles > * setting; this will open settings.json for editing, with the standard profiles added; simply saving the file is sufficient.
Note: If the "terminal.integrated.profiles.*" setting shown doesn't contain the expected, platform-appropriate standard profiles, a setting by that name may already be present; to force creation of the standard profiles, remove or comment out the existing setting and save the file, then try again.
On Windows, you'll end up with something like the following:
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
"${env:windir}\\Sysnative\\cmd.exe",
"${env:windir}\\System32\\cmd.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
}
}
The answer you link to in your question, which provides an overview of the various types of shells used in Visual Studio Code, has been updated to reflect the information about the new shell profiles.
[1] Note: If a PowerShell (Core) v6+ installation is found, it takes precedence over the built-in Windows PowerShell version.
Edit:1
Note: Now this bug has been fixed by VSCode. Just update your VSCode to the latest version. (17-Sep-2021)
I have a temporary solution.
First paste this code in settings.json and save
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.integrated.profiles.windows": {
"C:\\Program Files\\Git\\bin\\bash.exe": {
"path": "",
"args": []
}
},
Before closing VSCode select Output instead of Terminal
Now you can open VSCode
After VSCode is loaded, you need to click on Terminal. After this you will now see bash.
Select output before whenever you close VSCode.
Reference: VSCode is suddenly defaulting to PowerShell for integrated terminal instead of $Bash in Windows
Note: This is not an solution. I shared this because maybe it can save you from getting disappointed.
This is my first post, if there is any mistake please let me know so that I can correct it.
You can always download and install previous releases from the official website https://code.visualstudio.com/updates/v1_59 (currently at the top).
As version 1.60 was bugged, v1.59 is a good candidate.
Disable automatic updates
Explained here.
Open User Settings File > Preferences > Settings.
Add "update.mode": "none" to your settings.
Install older version
Afterwards you can just overwrite current version with the installation of downloaded version.
Note: Wait for next version to fix it, so remember you had automatic update disabled!
I have same problem but I try run command prompt. I fix it by adding to ...\Code\User\settings.json
"terminal.integrated.automationShell.windows": "cmd.exe",
This could be related to issue 138999 which will add a mitigation/enhancement to VSCode 1.70 (July 2022) with PR 154290 and commit 91b82c0
increase barrier for available profiles to be ready
Wait up to 20 seconds for profiles to be ready so it's assured that we know the actual default terminal before launching the first terminal.
This isn't expected to ever take this long.
For VSCode with synchronized user settings, the profile might take more time than expected to fully load, hence the advantage of that workaround.
Simply replaced the CMD by Git Bash :-) in the settings.json
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
//"${env:windir}\\Sysnative\\cmd.exe",
//"${env:windir}\\System32\\cmd.exe"
"C:\\PrivateProgramms\\Git\\bin\\bash.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
//"path": [ "C:\\PrivateProgramms\\Git\\bin\\bash.exe" ],
//"args": [],
//"icon": "terminal-cmd"
}
},
"terminal.integrated.defaultProfile.windows": "Command Prompt"

Small Basic & syntax highlighting in Visual Studio Code [duplicate]

Is there a way to extend the supported languages/grammars in Visual Studio Code?
I'd like to add a custom language syntax, but I've not been able to find any information on how language services are provided.
Can anybody point to any references or even examples of existing language implementations?
It's possible with the new version 0.9.0. There's an official documentation on how to add a custom language: https://github.com/microsoft/vscode-docs/blob/main/release-notes/v0_9_0.md
You need a .tmLanguage file for the language you want to add. You can find existing files e.g. on GitHub or you can define your own language file. Look here to get an idea of how to create one: http://manual.macromates.com/en/language_grammars
After finding a .tmLanguage file you have two ways to create an extension based on it.
Option 1: Using a Yeoman generator
Install node.js (if you haven't already done)
Install yo (if you haven't already done) by executing npm install -g yo
Install the Yo generator for code: npm install -g generator-code
Run yo code and select New language support
Follow the instructions (define the .tmLangauge file, define the plugin name, file extensions etc.)
The generator creates a directory for your extension with the name of the plugin in your current working directory.
Option 2: Create the directory on your own
Create a directory with the name of your plugin (only lowercase letters). Let's say we call it mylang.
Add a subfolder syntaxes and place the .tmlanguage file inside of it
Create a file package.json inside the root of the extension folder with content like this
{
"name": "mylang",
"version": "0.0.1",
"engines": {
"vscode": ">=0.9.0-pre.1"
},
"publisher": "me",
"contributes": {
"languages": [{
"id": "mylang",
"aliases": ["MyLang", "mylang"],
"extensions": [".mylang",".myl"]
}],
"grammars": [{
"language": "mylang",
"scopeName": "source.mylang",
"path": "./syntaxes/mylang.tmLanguage"
}]
}
}
Finally add your extension to Visual Studio Code
Copy the extension folder to the extension directory. This is:
on Windows %USERPROFILE%\.vscode\extensions
on Mac/Linux $HOME/.vscode/extensions
Restart Code. Now your extension will run automatically everytime you open a file with the specified file extension. You can see the name of the used plugin in the down right corner. You can change it by clicking on the name of the extension. If your extension is not the only one registered for a specific file extension then Code may chooses the wrong one.
To extend Wosi's .tmLanguage answer, using a .tmLanguage file is optional. Using a regular .json is a perfectly valid and—in my opinion—better readable alternative.
For an example, see VSCode_SQF: sqf.json
Inside the package.json, you would only need to change the path from ./syntaxes/mylang.tmLanguage to ./syntaxes/mylang.json.
Using reverse engineering you can add a new language to VSCode. You can take a look on how typescript is implemented as a JavaScript plugin and how it communicates with node.exe via pipe. But it's a hard thing since it's coming all without documentation
I'll provide a really short documentation here:
You can define a new plugin in the plugins folder C:\Users\USER\AppData\Local\Code\app-0.3.0\resources\app\plugins.
Copy the typescript plugin folder and rename mentioned file extensions and language names in all files to your new language, so that your new plugin is going to be used when a .mylang file is opened.
In typescriptServiceClient.js you see that a child process is being forked and that its stdout is coupled to a new WireProtocol.Reader. Bind your own mylanguage.exe (you'll probably need to write that exe on your own). VSCode asks that binary to get more language specific information.
In typescriptMain.js you find the feature registration for the language. Delete every call to monaco.Modes.XXXXXXSupport.register except monaco.Modes.DeclarationSupport.register.
Now open a directory in VSCode that contains .mylang files and open one of them via CTRL+P + FileName. Right click on an identifier and select Go to Definition. VSCode sends now a request like this via StdIn to your exe
{"seq":1,"type":"request","command":"definition","arguments":{"file":"d:/Projects/MyProj/Source/MyFile.mylang","line":45,"offset":9}}
VSCode expects an answer like this:
Content-Length: 251
[LINE BREAK]
{ "seq" : 1, "type" : "response", "command" : "definition", "request_seq" : 1, "success" : true, "body" : [{ "file" : "d:/Projects/MyProj/Source/MyOtherFile.mylang", "start" : { "line" : 125, "offset" : 3 }, "end" : { "line" : 145, "offset" : 11} }] }
If everything works VSCode will open MyOtherFile.mylang and set the cursor to line 124 in column 3.
Try it on your own ;-)
Simplest recipe IMHO as of 2021 Q2:
Follow Option 2 in Wosi's answer. You only need two files to get started. Just create the folder structure directly in your extensions directory.
Set "path": "./syntaxes/your_language.plist" in package.json
Use IRO to build your regexes.
Make sure that in the "Scope Information" screen, anything to do with Textmate is green. Don't worry about the other editors.
Save the contents of the "Textmate" tab into the path above, i.e., .syntaxes/your_language.plist
Reload VSCode
That's it. I also save the IRO (left pane) text into my own project.
You can read the source code of the built-in language extensions online:
https://github.com/microsoft/vscode/tree/main/extensions
You can pick an extension that is close to your language's syntax and change it as you wish. (e.g. you can do some modifications to the JavaScript extension and rebrand it for use with jQuery!)
It is important to note that this would be too much work if you choose a language that is so different from your desired language! If you didn't manage to find a language that is similar to your desired language, you may want to create a whole new extension from the ground up - https://stackoverflow.com/a/32996211/14467698 -.

Sublime Text: "MarGo: Missing required environment variables: GOPATH"

In order to program with Golang in a more productive way, I just installed GoSublime for Sublime Text 2, as explained on their official GitHub repository:
Installation
Sublime Package Control allows you to easily install or remove
GoSublime (and many other ST2 packages) from within the editor. It
offers automatically updating packages as well so you no longer need
to keep track of changes in GoSublime.
Install Sublime Package Control (if you haven't done so already) from
http://wbond.net/sublime_packages/package_control .
Be sure to restart
ST2 to complete the installation.
Bring up the command palette (default ctrl+shift+p or cmd+shift+p) and
start typing Package Control: Install Package then press return or
click on that option to activate it. You will be presented with a new
Quick Panel with the list of available packages. Type GoSublime and
press return or on its entry to install GoSublime. If there is no
entry for GoSublime, you most likely already have it installed.
Now, whenever I launch Sublime Text, I have the following error message:
MarGo: Missing required environment variables: GOPATH
See the `Quirks` section of USAGE.md for info
And a usage.md file opens automatically, with the following content:
Usage
=====
Note
----
* Unless otherwise mentioned, `super` replaces `ctrl` in key bindings on OS X.
* A mention of a (GO)PATH variable uses a colon(`:`) as the separator.
This is the PATH separator on Linux and OS X, Windows uses a semi-colon(`;`)
Settings
--------
You may customize GoSublime's behaviour by (creating and) customizing the file `Packages/User/GoSublime.sublime-settings`. Default settings are documented in `Packages/GoSublime/GoSublime.sublime-settings`. **WARNING** Do not edit any package file outside of `Packages/User/`, including files inside `Packages/GoSublime/` unless you have a reason to. These files are subject to being overwritten on update of the respective package and/or Sublime Text itself. You may also inadvertently prevent the respective package from being able to update via git etc.
Quirks
------
This section assumes you know what `GOPATH` is and how to set it. If you don't, please see http://golang.org/doc/code.html
In some systems, environment variables are not passed around as expected.
The result of which is that some commands e.g `go build` don't work
as the command cannot be found or `GOPATH` is not set. To get around this
the simplest thing to do is to set these variables in the settings file.
See the documentation for the `env` and/or `shell` setting, both documented in the default
settings file `Packages/User/GoSublime.sublime-settings`
Code Completion
---------------
Completion can be accessed by typing the (default) key combination `CTRL+[SPACE]` inside a Golang file.
Key Bindings
------------
By default, a number of key bindings are provided. They can be viewed by opening the command palette
and typing `GoSublime:` or via the key binding `ctrl+dot`,`ctrl+dot` (or `super+dot`,`super+dot` on OS X).
Wherever I refer to a key binding with `ctrl+` it is by default defined as `super+` on OS X unless stated otherwise.
Useful Key Bindings
-------------------
Often when commenting out a line, the immediate action following this is to move the cursor to the next line either to continue working or comment out the following line.
With this key binding, you can have the line commented out and the cursor automatically moved to the next line.
{ "keys": ["ctrl+/"], "command": "gs_comment_forward", "context": [{ "key": "selector", "operator": "equal", "operand": "source.go" }] },
Package Imports
---------------
Pressing `ctrl+dot`,`ctrl+p` will open the package list from which you can quickly import or delete a package import.
The usage is the same for both operations. If the package is already imported then it will appear near the top
and be marked as a *delete* operation, so in effect it is a toggle. If you want to edit the alias of a package e.g
a database driver: first import the package as normal and then press `ctrl+dot`,`ctrl+i` to quickly jump
the last imported package. Once edited you can return to where you were by pressing `ctrl+dot`,`ctrl+[`
Building, Testing and the Go command
------------------------------------
GoSublime comes with partial command/shell integration `9o`. For more information about 9o, see Packages/GoSublime/9o.md
or from within Sublime Text press `ctrl+9` or `super+9` and type `help`.
To run package tests you have 3 options.
* press `ctrl+dot`,`ctrl+t` to open the testing quick panel. This offers basic/common options such
as running all benchmark functions or running a single test function.
* inside a `_test.go` file, press `ctrl+shift` and left-click on the name of a Test, Benchmark or Example
function e.g. `TestAbc` to execute that function only.
* if the above options are too minimalistic or you would otherwise like to call `go test` with your own options,
open 9o by pressing `ctrl+9` where you have access to the `go` command.
In the case of building a package, 9o provides a replay command (see 9o.md for details) that will execute
the command if the pkg is a command pkg (package main) or run all tests if it's a normal pkg.
The replay command is bound to `ctrl+dot`,`ctrl+r` for easy access.
GoSublime provides an override for the Sublime Text build-system via `ctrl+b`. In the menu `Tools > Build System` it's named `GoSublime`.
`ctrl+b` is automatically handled by Sublime Text, so if you have another `Go` build system chosen, `ctrl+b`
will execute that instead. To access the `GoSublime` build system directly press `ctrl+dot`,`ctrl+b`.
This build system simply opens 9o and expand the last command. i.e. executes the 9o command `^1`.
Per-project Settings & Project-based GOPATH
-------------------------------------------
If you have a settings object called `GoSublime` in your project settings its values will override those
inside the `GoSublime.sublime-settings` file. As a side-effect you may set a specific GOPATH for a single
project.
`my-project.sublime-project`
{
"settings": {
"GoSublime": {
"env": {
"GOPATH": "$HOME/my-project"
}
}
},
"folders": []
}
If the only setting you use this functionality to change is the GOPATH, then you may be able to find
success by adding the string `$GS_GOPATH` to your global `GOPATH` setting e.g.
{
"env": { "GOPATH": "$HOME/go:$GS_GOPATH" }
}
`GS_GOPATH` is a pseudo-environment-variable. It's changed to match a possible GOPATH based on:
* the current working directory, e.g. `~/go/src/pkg` then `$GS_GOPATH` will be `~/go/`
* or the path the current `.go` file (or last activated `.go` file if the current file is not `.go`) e.g. if your file path is `/tmp/go/src/hello/main.go` then it will be `/tmp/go`
If you would like to use `GS_GOPATH` exclusively, you may set the option `use_gs_gopath` to true.
This automatically changes `GOPATH` to the value of `$GS_GOPATH` if `$GS_GOPATH` is not empty.
This allows you to e.g. automatically adapt `GOPATH` to your current project rather than
reverting to your normal `GOPATH`.
Lint/Syntax Check
-----------------
The source is continuously scanned for syntax errors. GoSublime will try to catch some common errors, like
forgetting to call flag.Parse (if this causes false positives, please file a bug report).
Apart from the highlighting in the view using a dot icon in the gutter and usually underlining the
first character of an error region. You are given an entry in the status bar in the form: `GsLint (N)`
where `N` is the number of errors found in that file. You can show the list of errors and navigate to
them by pressing `ctrl+dot`,`ctrl+e`. Errors for the current line are shown in the status bar.
Fmt
---
By default `ctrl+s` and `ctrl+shift+s` are overridden to fmt the the file before saving it. You may also
fmt a file without saving it by pressing `ctrl+dot`,`ctrl+f`
Godoc/Goto Definition
---------------------
To show the source and associated comments(documentation) of a variable press `ctrl+dot`,`ctrl+h` or
using the mouse `ctrl+shift+right-click`. This will show an output panel that presents the full
definition of the variable or function under the (first) cursor along with its comments.
To goto the definition instead, press `ctrl+dot`,`ctrl+g` or alternatively using the mouse `ctrl+shift+left-click`.
Declarations/Code Outline?
--------------------------
A very minimal form of code outline is provided. You can press `ctrl+dot`,`ctrl+d` to list all the declarations
in the current file.
New File
--------
Pressing `ctrl+dot`,`ctrl+n` will create a new Go file with the package declaration filled out.
It will try to be intelligent about it, so if the current directory contains package `mypkg` it will use that as the package name.
Misc. Helper Commands
---------------------
The following commands can be assigned key bindings to further improve your editing experience.
* gs_fmt - this command runs `gofmt` on the current buffer. Also available via the key binding `ctrl+dot`,`ctrl+f`.
* gs_fmt_save, gs_fmt_prompt_save_as - these commands will run the `go_fmt` followed by `save` or `prompt_save_as` - these are bound to `ctrl+s` and `ctrl+shift+s` respectively, by default.
* gs_comment_forward - this command will activate the `ctrl+/` commenting and move the cursor to the next line, allowing you to comment/uncomment multiple lines in sequence without breaking to move the cursor. You can replace the default behaviour by overriding it in your user key bindings (Preferences > Key Bindings - User) with `{ "keys": ["ctrl+/"], "command": "gs_comment_forward", "context": [{ "key": "selector", "operator": "equal", "operand": "source.go" }] }`
Some people seem to have had the same issue:
Idiotproof instructions for MarGo: Missing required environment variables: GOPATH #310
How come USAGE.MD opens everytime I open Sublime? #601
gopath is set, but still show "MarGo: Missing required environment variables: GOPATH" #520
And the root cause of the problem could be that the GOPATH has not been defined.
Mine has been — export GOPATH=$HOME/code/go — and I am able to run Go (and .go files) on my computer.
Any idea of how this can be fixed?
You need to set gopath in the GoSublime settings.
Go to:
Preferences -> Package Settings -> GoSublime -> Settings – User
And paste that code there:
{
"env": {
"GOPATH": "$HOME/code/go"
}
}

Resources