Configure VS Code keybinding to open a new Powershell script?

Question

I have the MS Powershell extension installed in VS Code. Other language extensions, e.g. Python, have the ability to assign a keybinding for creating a new file (python.createNewFile). I don't see this option in the Powershell extension. There isn't even an option with Ctrl-Shift-P.

EDIT: Expanding on the Python example, using a keybinding sequence for python.createNewFile will create a new file that already has Python syntax highlighting defined. I don't have to create the file, then save it with a .py extension to achieve this. I can get right into the scripting. I'd like to be able to do the same with Powershell.

The only options I have at the moment are to Ctrl + N, Ctrl + S, and give it a file name with a .ps1 extension, or Ctrl + N and choose "Powershell" from the Select a Language list.

Is there another way to do this? A macro or something? There are other Powershell extensions, but as far as I can tell the only way to know the abilities they provide, is to install each one.

Answer 1

You can place an adapted version of the following in your keybindings.json file:

• Open it for editing via the command palette (select menu command View > Command Palette... or press Ctrl+Shift+P), command Preferences: Open Keyboard Shortcuts (JSON); searching for keyb json should be enough to to locate it.

  // Be sure to place this inside the overall enclosing [...]
  // and, if other objects are present, place a "," before/after
  // it to ensure that all objects are ","-separated.
  {
    "key": "shift+f12", // adapt as needed
    "command": "workbench.action.files.newUntitledFile",
    "args": {
      "languageId": "powershell"
    }
  }

Thereafter, pressing Shift+F12 will open a new, untitled file and set its language mode to PowerShell, which entails:

• PowerShell-specific syntax highlighting of code in the file.

• The suggested file name when first saving will have extension .ps1

• Additionally, if you have the PowerShell extension installed (which is advisable for a rich PowerShell authoring and debugging experience):

  • the PIC (PowerShell-Integrated Console) is started in the integrated terminal, which is automatically shown by default.
  • editing is assisted by PowerShell-specific IntelliSense, PowerShell-specific snippets are available, as is debugging of scripts.

---

Optional reading: How to discover Visual Studio Code's available API commands:

• As of this writing, the official documentation only describes a subset of all built-in commands, in Built-in commands, which seems to be focused on commands that optionally accept or require arguments, i.e. have parameters.

• However, as the linked topic notes, a current list of all (publicly available) built-in commands can be gleaned from:

  • Interactively, via the GUI, using the view that the Preferences: Open Keyboard Shortcuts command palette entry (Ctrl+K, Ctrl+S) opens:

    • You can search for keywords such as language mode there.

  • Alternatively, via the virtual JSON-based view of the same information that opens in an editor tab, by choosing Preferences: Open Default Keyboard Shortcuts (JSON) from the command palette.

    • There, the commands are listed by their full names, such as workbench.action.editor.changeLanguageMode

  • That said, neither of these views reveal the arguments (parameter names) supported by these commands,^[1] except - in the latter view only - if bound keyboard shortcuts happen to use arguments ("args" properties).

    • In fact, workbench.action.editor.changeLanguageMode - which seems like the logical command to use - is purely a UI-based command and therefore doesn't accept arguments; see next point.

• While the Built-in commands topic does describe the specific arguments a given command supports, that description is sometimes lacking, requiring digging into the source code, which is indeed how the specific parameter name (languageID) was discovered in the case at hand.

---

^{[1] Neither does the Gist you mention in a comment, whose results are based on authoring a dummy extension (and seemingly includes non-public commands, prefixed with _). The results there are a snapshot of the available commands at a given point in time. Fellow users have provided updated snapshots over time, but using the methods described above is preferable, as they are guaranteed to be current for a given Visual Studio Code installation.}