Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled? Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.61.0 Commit: Date: 2021-10-07T18:11:58.853Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: the Terminal Sample from the vscode-extension-sample repository the a task that reuses a terminal. For example, I used a user task like: On the first run of the task the 'link' text will create a hover link correctly. If you re-run the task so the terminal has 2 (or more) runs of the task in the same terminal then the link will fail to detect correctly. Adding a breakpoint to there appears to be 1 call per execution of the task in the terminal. I think when the terminal is re-used it re-registers the link provider and if two link providers have overlapping links they both seem to fail (which is a known issue but due to this bug all link providers start failing if tasks are run multiple times).
Putting a breakpoint in the registerLinkProvider call for xterm (here ) I see multiple copies of all of the link providers: <img width="574" alt="Screen Shot 2021-10-12 at 9 15 30 AM" src="https://user-"

// Init winpty compat and link handler after process creation as they rely on the // underlying process OS this._processManager.onProcessReady((processTraits) => { <ins> // If links are ready, do not re-create the manager. if (this._areLinksReady) { return; } </ins> if (this._processManager.os === OperatingSystem.Windows) { xterm.setOption('windowsMode', processTraits.requiresWindowsMode || false); // Force line data to be sent when the cursor is moved, the main purpose for


Question:
Issue Type: <bBug</bI'm using MacOS. After opening VSCode and getting into full-screen mode: If I use the integrated terminal of VSCode to create a new file, e.g.: VSCcode switches my screen to my previous workspace that causes interruption of work. Everytime I use to create a new file, I'll have to use + to move back to VSCode. VS Code version: Code 1.61.1 (, 2021-10-14T01:23:30.274Z) OS version: Darwin x64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ code-runner0.11.6 terminal0.0.10 go0.28.1 vscode-docker1.17.0 python2021.10. vscode-pylance2021.10.1 jupyter2021.9. jupyter-keymap1.0.0 jupyter-renderers1.0.3 remote-containers0.202.4 remote-ssh0.65.8 remote-ssh-edit0.65.8 remote-wsl0.58.2 vscode-remote-extensionpack0.21.0 vscode-yaml0.23.0 code-settings-sync3.4.3 open-in-browser2.0.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I am not sure if this could be a regression from the work we did to use the command.
I just built a version without the open cmd fix, but still saw the behaviour. I'm wondering if it could actually be caused by changes made during Edit: It seems reverting both commits fixes the issue.
It is unrelated to my changes. When I simply change this line to always go into the of : It does not reproduce anymore. Looks like when we are using , macOS does not really know whether a new window opens or an existing one reused. I feel this is a pretty bad regression actually.
I see that has fixed this bug and merged the PR. It seems like this is in (not sure what that means) but the issue still persists. I wonder when will this be fixed? In the next VSCode update? Thanks.
It should be fixed in our current latest stable release ().
Thanks, Just updated to today and I confirm that it's fixed.

// similar to if the app was launched from the dock // https://github.com/microsoft/vscode/issues/102975 <del> const spawnArgs = ['-n'];				// -n: launches even when opened already </del> <ins> // The following args are for the open command itself, rather than for VS Code: // -n creates a new instance. //    Without -n, the open command re-opens the existing instance as-is. // -g starts the new instance in the background. //    Later, Electron brings the instance to the foreground. //    This way, Mac does not automatically try to foreground the new instance, which causes //    focusing issues when the new instance only sends data to a previous instance and then closes. const spawnArgs = ['-n', '-g']; // -a opens the given application. </ins> spawnArgs.push('-a', process.execPath); // -a: opens a specific application if (verbose) {


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: n/a <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: latest OS Version: macOS 11.2.3 Steps to Reproduce: repo npm version < 14 or ≥ 17 to see this message message or just read the commit diff to see the problem
from check is for ≥ 17 but error message says to use ≤ 17, thus exactly v17 is both valid and invalid

const majorNodeVersion = parseInt(/^(d+)./.exec(process.versions.node)[1]); if (majorNodeVersion < 14 || majorNodeVersion >= 17) { <del> console.error('033[1;31m*** Please use node.js versions >=14 and <=17.033[0;0m'); </del> <ins> console.error('033[1;31m*** Please use node.js versions >=14 and <17.033[0;0m'); </ins> err = true; }


Question:
Copied from My workaround is export VSCODEGITASKPASSEXTRAARGS="--title=foobar" but the proper bugfix should happen in VSCode's GIT_ASKPASS implementation.
I experience the same problem, from the moment been released. Working through remote ssh the git processes stay open, without anything happening.
Still facing this issue on WSL.
Will be fixed in upcoming 1.62.2. Meanwhile a workaround is to and then manually
I can confirm that this is fixed after updating to 1.62.2 ().

#!/bin/sh VSCODE_GIT_ASKPASS_PIPE=`mktemp` <del> ELECTRON_RUN_AS_NODE="1" VSCODE_GIT_ASKPASS_PIPE="$VSCODE_GIT_ASKPASS_PIPE" "$VSCODE_GIT_ASKPASS_NODE" "$VSCODE_GIT_ASKPASS_EXTRA_ARGS" "$VSCODE_GIT_ASKPASS_MAIN" $* </del> <ins> ELECTRON_RUN_AS_NODE="1" VSCODE_GIT_ASKPASS_PIPE="$VSCODE_GIT_ASKPASS_PIPE" "$VSCODE_GIT_ASKPASS_NODE" "$VSCODE_GIT_ASKPASS_MAIN" $VSCODE_GIT_ASKPASS_EXTRA_ARGS $* </ins> cat $VSCODE_GIT_ASKPASS_PIPE rm $VSCODE_GIT_ASKPASS_PIPE


Question:
! It could be that I caused this, but I doubt it (injected text has nothing to do with the gutter, maybe they shared a CSS rule).
I can reproduce but I'm not aware of any changes in that area from the debug side.
I would like to work on this issue!
Before fixing anything we should do a "git bisect" to find the commit that broke this.
commit . it should
thanks for pointing out the commit! If you like, you can provide a PR, that would be awesome!
PR

margin-top: -1px; } <ins> .codicon-debug-breakpoint.codicon-debug-stackframe-focused::after, .codicon-debug-breakpoint.codicon-debug-stackframe::after { content: 'eb8a'; position: absolute; } </ins> .monaco-editor .debug-top-stack-frame-column { font: normal normal normal 16px/1 codicon; text-rendering: auto;


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: git commit (1 Dec 2021), with openvscode-server patches until commit Browser: Firefox OS Version: Ubuntu 20.04 Steps to Reproduce: a freshly opened window, open or type some text in it. Try using Ctrl + Shift + Right, text should be selected at word boundaries. a terminal, then close it using command. using Ctrl + Shift + Right again. Expected: Text should be selected at word boundaries. Actual: No text is selected. Cursor doesn't move at all. This is the the same issue as filed at [1] and [2]. If it's reproducible in 3 server implementations (counting openvscode-server), then it's probably an upstream issue. Sadly I don't have an access to GitHub Codespaces, so I can't verify it with an "official" implementation [3]. You'll notice in keyboard troubleshooting log below the following 2 lines: It's been suggested in [1] that vscode might still think that is active despite the terminal is closed. Thus, a workaround I've been using is to have the following in (with default unbind): That is, wherever exists, augment it with . [3] I mean, doesn't have terminals. I've tried using Live Share; that doesn't change. See Keyboard shortcuts troubleshooting. The first keypress is before the terminal is opened. The other two are after it's closed. <details<pre[2021-12-03 01:36:00.490] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control [2021-12-03 01:36:00.503] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl') [2021-12-03 01:36:00.509] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:00.513] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 16, key: Shift [2021-12-03 01:36:00.517] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 4 ('Shift') [2021-12-03 01:36:00.521] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:00.808] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:00.813] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:00.817] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:00.821] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched cursorWordLeftSelect, when: textInputFocus, source: built-in. [2021-12-03 01:36:01.146] [window] [info] [KeybindingService]: + Ignoring single modifier shift due to it being pressed together with other keys. [2021-12-03 01:36:03.304] [window] [info] [KeybindingService]: | Resolving [KeyE] [2021-12-03 01:36:03.310] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.401] [window] [info] [KeybindingService]: | Resolving [KeyE] [2021-12-03 01:36:03.406] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.737] [window] [info] [KeybindingService]: | Resolving [KeyX] [2021-12-03 01:36:03.744] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.832] [window] [info] [KeybindingService]: | Resolving [KeyX] [2021-12-03 01:36:03.838] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.210] [window] [info] [KeybindingService]: | Resolving [KeyI] [2021-12-03 01:36:04.218] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.344] [window] [info] [KeybindingService]: | Resolving [KeyI] [2021-12-03 01:36:04.348] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.396] [window] [info] [KeybindingService]: | Resolving [KeyT] [2021-12-03 01:36:04.404] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.518] [window] [info] [KeybindingService]: | Resolving [KeyT] [2021-12-03 01:36:04.523] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.762] [window] [info] [KeybindingService]: | Resolving [Enter] [2021-12-03 01:36:04.769] [window] [info] [KeybindingService]:  From 20 keybinding entries, no when clauses matched the context. [2021-12-03 01:36:04.824] [window] [info] [KeybindingService]: | Resolving [Enter] [2021-12-03 01:36:04.827] [window] [info] [KeybindingService]:  From 20 keybinding entries, no when clauses matched the context. [2021-12-03 01:36:06.677] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control [2021-12-03 01:36:06.685] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl') [2021-12-03 01:36:06.689] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:06.692] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 16, key: Shift [2021-12-03 01:36:06.696] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 4 ('Shift') [2021-12-03 01:36:06.700] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:06.766] [window] [error] Cannot refresh property when process is undefined: [2021-12-03 01:36:07.142] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:07.147] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:07.151] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:07.155] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched , when: terminalFocus && terminalHasBeenCreated terminalFocus && terminalProcessSupported, source: built-in. [2021-12-03 01:36:07.913] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:07.920] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:07.925] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:07.930] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched , when: terminalFocus && terminalHasBeenCreated terminalFocus && terminalProcessSupported, source: built-in. [2021-12-03 01:36:08.344] [window] [info] [KeybindingService]: + Ignoring single modifier ctrl due to it being pressed together with other keys. </pre</details
I can't reproduce this issue in Firefox or Safari.
you mentioned Safari, which implied that you have macOS. Could you please re-try using Linux or Windows? macOS uses Command key for those keybindings, and so duplicated keybindings doesn't exist. Folks at cdr/code-server can't reproduce it on macOS either, but subsequently can reproduce it on Linux. Please re-open this issue.
doesn't reproduce for me there either !
That looks like Microsoft Edge, based on Chromium engine. Could you please try again on Firefox?
I can reproduce this in Ubuntu/Firefox
Does not repro on Ubuntu/Edge
Created a PR with a workaround

import { XtermTerminal } from 'vs/workbench/contrib/terminal/browser/xterm/xtermTerminal'; import { escapeNonWindowsPath } from 'vs/platform/terminal/common/terminalEnvironment'; import { IWorkspaceTrustRequestService } from 'vs/platform/workspace/common/workspaceTrust'; <ins> import { isFirefox } from 'vs/base/browser/browser'; </ins> const enum Constants { /**


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: git commit (1 Dec 2021), with openvscode-server patches until commit Browser: Firefox OS Version: Ubuntu 20.04 Steps to Reproduce: a freshly opened window, open or type some text in it. Try using Ctrl + Shift + Right, text should be selected at word boundaries. a terminal, then close it using command. using Ctrl + Shift + Right again. Expected: Text should be selected at word boundaries. Actual: No text is selected. Cursor doesn't move at all. This is the the same issue as filed at [1] and [2]. If it's reproducible in 3 server implementations (counting openvscode-server), then it's probably an upstream issue. Sadly I don't have an access to GitHub Codespaces, so I can't verify it with an "official" implementation [3]. You'll notice in keyboard troubleshooting log below the following 2 lines: It's been suggested in [1] that vscode might still think that is active despite the terminal is closed. Thus, a workaround I've been using is to have the following in (with default unbind): That is, wherever exists, augment it with . [3] I mean, doesn't have terminals. I've tried using Live Share; that doesn't change. See Keyboard shortcuts troubleshooting. The first keypress is before the terminal is opened. The other two are after it's closed. <details<pre[2021-12-03 01:36:00.490] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control [2021-12-03 01:36:00.503] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl') [2021-12-03 01:36:00.509] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:00.513] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 16, key: Shift [2021-12-03 01:36:00.517] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 4 ('Shift') [2021-12-03 01:36:00.521] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:00.808] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:00.813] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:00.817] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:00.821] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched cursorWordLeftSelect, when: textInputFocus, source: built-in. [2021-12-03 01:36:01.146] [window] [info] [KeybindingService]: + Ignoring single modifier shift due to it being pressed together with other keys. [2021-12-03 01:36:03.304] [window] [info] [KeybindingService]: | Resolving [KeyE] [2021-12-03 01:36:03.310] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.401] [window] [info] [KeybindingService]: | Resolving [KeyE] [2021-12-03 01:36:03.406] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.737] [window] [info] [KeybindingService]: | Resolving [KeyX] [2021-12-03 01:36:03.744] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.832] [window] [info] [KeybindingService]: | Resolving [KeyX] [2021-12-03 01:36:03.838] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.210] [window] [info] [KeybindingService]: | Resolving [KeyI] [2021-12-03 01:36:04.218] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.344] [window] [info] [KeybindingService]: | Resolving [KeyI] [2021-12-03 01:36:04.348] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.396] [window] [info] [KeybindingService]: | Resolving [KeyT] [2021-12-03 01:36:04.404] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.518] [window] [info] [KeybindingService]: | Resolving [KeyT] [2021-12-03 01:36:04.523] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.762] [window] [info] [KeybindingService]: | Resolving [Enter] [2021-12-03 01:36:04.769] [window] [info] [KeybindingService]:  From 20 keybinding entries, no when clauses matched the context. [2021-12-03 01:36:04.824] [window] [info] [KeybindingService]: | Resolving [Enter] [2021-12-03 01:36:04.827] [window] [info] [KeybindingService]:  From 20 keybinding entries, no when clauses matched the context. [2021-12-03 01:36:06.677] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control [2021-12-03 01:36:06.685] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl') [2021-12-03 01:36:06.689] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:06.692] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 16, key: Shift [2021-12-03 01:36:06.696] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 4 ('Shift') [2021-12-03 01:36:06.700] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:06.766] [window] [error] Cannot refresh property when process is undefined: [2021-12-03 01:36:07.142] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:07.147] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:07.151] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:07.155] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched , when: terminalFocus && terminalHasBeenCreated terminalFocus && terminalProcessSupported, source: built-in. [2021-12-03 01:36:07.913] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:07.920] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:07.925] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:07.930] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched , when: terminalFocus && terminalHasBeenCreated terminalFocus && terminalProcessSupported, source: built-in. [2021-12-03 01:36:08.344] [window] [info] [KeybindingService]: + Ignoring single modifier ctrl due to it being pressed together with other keys. </pre</details
I can't reproduce this issue in Firefox or Safari.
you mentioned Safari, which implied that you have macOS. Could you please re-try using Linux or Windows? macOS uses Command key for those keybindings, and so duplicated keybindings doesn't exist. Folks at cdr/code-server can't reproduce it on macOS either, but subsequently can reproduce it on Linux. Please re-open this issue.
doesn't reproduce for me there either !
That looks like Microsoft Edge, based on Chromium engine. Could you please try again on Firefox?
I can reproduce this in Ubuntu/Firefox
Does not repro on Ubuntu/Edge
Created a PR with a workaround

} this.xterm?.dispose(); <ins> // HACK: Workaround for Firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=559561, // as 'blur' event in xterm.raw.textarea is not triggered on xterm.dispose() // See https://github.com/microsoft/vscode/issues/138358 if (isFirefox) { this._terminalFocusContextKey.reset(); this._terminalHasTextContextKey.reset(); this._onDidBlur.fire(this); } </ins> if (this._pressAnyKeyToCloseListener) { this._pressAnyKeyToCloseListener.dispose(); this._pressAnyKeyToCloseListener = undefined;


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes In make a new keybinding: Intellisense shows many arg keys that are inaccurate or not implemented. Here is what I get for intellisense: These appear to be the correct and implemented args to this command: Version: 1.63.0-insider (user setup) Commit: Date: 2021-12-02T05:15:40.605Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.
Related:
This issue persists as of vscode I was going to open an bug issue mentioning that some params were not working... when in fact I was using the ones suggested by the intellisense e.g. instead of . A while back I opened: about how the command does not resolve variables whereas does. Also related I guess needs some love to be more consistent feature-wise with .

properties: { searchString: { type: 'string' }, replaceString: { type: 'string' }, <del> regex: { type: 'boolean' }, regexOverride: { type: 'number', description: nls.localize('actions.find.isRegexOverride', 'Overrides "Use Regular Expression" flag.nThe flag will not be saved for the future.n0: Do Nothingn1: Truen2: False') }, wholeWord: { type: 'boolean' }, wholeWordOverride: { type: 'number', description: nls.localize('actions.find.wholeWordOverride', 'Overrides "Match Whole Word" flag.nThe flag will not be saved for the future.n0: Do Nothingn1: Truen2: False') }, matchCase: { type: 'boolean' }, matchCaseOverride: { type: 'number', description: nls.localize('actions.find.matchCaseOverride', 'Overrides "Math Case" flag.nThe flag will not be saved for the future.n0: Do Nothingn1: Truen2: False') }, </del> <ins> isRegex: { type: 'boolean' }, matchWholeWord: { type: 'boolean' }, isCaseSensitive: { type: 'boolean' }, </ins> preserveCase: { type: 'boolean' }, <del> preserveCaseOverride: { type: 'number', description: nls.localize('actions.find.preserveCaseOverride', 'Overrides "Preserve Case" flag.nThe flag will not be saved for the future.n0: Do Nothingn1: Truen2: False') }, </del> findInSelection: { type: 'boolean' }, } }


Question:
Issue Type: <bBug</b(sorry, these are not good steps because I can't figure out exactly what triggers this) a language pack installed (I have the german pack) a new workspace or reload VS Code Bug Sometimes I get a prompt to switch display languages. I select no but the prompt will come back again later I see this maybe once or twice a day and haven't figured out exactly what is causing it VS Code version: Code - Insiders 1.64.0-insider (Universal) (, 2021-12-14T13:26:59.630Z) OS version: Darwin x64 21.1.0 Restricted Mode: No <details<summaryExtensions (53)</summaryExtensionVersion ------ salesforce-soql-editor1.8.0 tsl-problem-matcher0.5.0 comment-tagged-templates0.3.1 docs-view0.0.9 emojisense0.9.0 folder-source-actions0.2.1 jsdoc-markdown-highlighting0.0.1 markdown-checkbox0.3.2 markdown-emoji0.2.1 markdown-yaml-preamble0.1.0 test-ext0.0.1 vscode-eslint2.2.2 dendron0.73.0 dendron-paste-image1.1.0 typescript-notebook2.0.6 gitlens11.7.0 EditorConfig0.16.4 codespaces1.4.2 copilot1.7.4273 remotehub0.20.0 vscode-pull-request-github0.35. vscode-drawio1.6.3 vscode-postfix-ts1.9.4 latex-workshop8.22.0 vscode-platform-specific-sample1.15.0 vscode-platform-specific-sample1.5.0 vscode-memfs0.0.3 template-string-converter0.5.5 vscode-azurefunctions1.6.0 vscode-azureresourcegroups0.4.0 vscode-docker1.18.0 vscode-language-pack-de1.63.3 python2022.0.-dev vscode-pylance2021.12.2 jupyter2022.1. jupyter-keymap1.0.0 jupyter-renderers1.0.4 remote-containers0.209.6 remote-ssh0.70.0 remote-ssh-edit0.70.0 azure-account0.9.11 hexeditor1.8.2 js-debug-nightly2021.11.1217 live-server0.2.11 vscode-github-issue-notebooks0.0.113 vsliveshare1.0.5196 debugger-for-chrome4.13.0 vetur0.35.0 code-spell-checker2.0.13 rest-book5.0.1 ayu1.0.5 luna-paint0.11.0 sort-lines1.9.0 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
please ping if you need help with this.
Here's the code that seems to trigger this: Would extension updates also trigger this?
and I looked into this with and we were shocked to see that background updating of an extension had an InstallOperation of "Install" and not "Update" Is this correct Easy repro steps: Using OSS with the marketplace Place a breakpoint on the line linked above ^ (or just at the top of ) Install an old version of a language pack No longer "Ingore Updates" Reload the window Your breakpoint will hit when the language pack updates to the latest version again and you'll notice the is set to (aka 2) instead of .
Yeah, it's a bug on my side that I am not propagating the operation properly. Sorry about that. Fixed.
I did a lang pack install and used it for half a day and didn't seen any prompts to switch display language. Is there anything other way to verify this?
I have the German language pack installed but haven't been using it. I haven't seen any prompts to switch to German recently so :+1:

readonly identifier = this.task.identifier; readonly source = this.task.source; <del> readonly operation = this.task.operation; </del> <ins> get operation() { return this.task.operation; } </ins> get verificationStatus() { return this.task.verificationStatus;


Question:
I do not see the notification toast when I select "New Terminal" from command palette. But I see this issue that the OP reported I think: ! ! Originally posted by in
I see this problem: Start a new terminal - full screen Drag to bottom or right = non-functional If you split the panel right, it is fine
Reproes only when you have more than one terminal in the editor area
Can do it with a single terminal, clean open of VSCode (mac), no other windows. !
Thanks, I specifically meant when dragging and dropping into the panel.
/verified second terminal is no longer blank

this._container = undefined; } attachToElement(container: HTMLElement): Promise<void> | void { // The container did not change, do nothing if (this._container === container) {


Question:
I do not see the notification toast when I select "New Terminal" from command palette. But I see this issue that the OP reported I think: ! ! Originally posted by in
I see this problem: Start a new terminal - full screen Drag to bottom or right = non-functional If you split the panel right, it is fine
Reproes only when you have more than one terminal in the editor area
Can do it with a single terminal, clean open of VSCode (mac), no other windows. !
Thanks, I specifically meant when dragging and dropping into the panel.
/verified second terminal is no longer blank

this._attachBarrier.open(); <del> this.xterm?.attachToElement(container); </del> // Attach has not occurred yet if (!this._wrapperElement) { return this._attachToElement(container); } <ins> this.xterm?.attachToElement(this._wrapperElement); </ins> // The container changed, reattach this._container = container;


Question:
allows extensions to disable the "Open Preview" button in markdown files. This option should also disable the "Open Preview" button in the context menus. ! Originally posted by in
/verified In stable: ! In insiders: !

"explorer/context": [ { "command": "markdown.showPreview", <del> "when": "resourceLangId == markdown", </del> <ins> "when": "resourceLangId == markdown && !hasCustomMarkdownPreview", </ins> "group": "navigation" } ], "editor/title/context": [ { "command": "markdown.showPreview", <del> "when": "resourceLangId == markdown", </del> <ins> "when": "resourceLangId == markdown && !hasCustomMarkdownPreview", </ins> "group": "1_open" } ],


Question:
Parent issue Update: Activate the fish shell integration by following these instructions: We're keeping this open until automatic injection is looked into.
Deferring to focus on polishing how shell integration works in general
Final implementation details aside, fish's event handing will make at least some of this dead easy: Some will be more difficult, at least to deploy auto-magically, because fish's are the output of shell functions, not the contents of variables: So to transparently preserve the user's original prompt, like the bash script does, would require modifying a shell function on-the-fly, not just a variable. Yikes. That said, I put the above code, plus the following, in my own config— —and I had all of VS Code's working perfectly with VS Code v1.70.0 + fish 3.5.1. It's only a proof of concept, but hopefully this saves somebody a few web searches down the line, at least. :)
very handy info thanks! The bash script handles both PS1 and PRONPT_COMMAND, might be able to wrap the function automatically in a similar way?
Well, fish doesn't have either: if you want something to run right before the prompt displays, you put it in a function with . There is, alas, no event handler that runs after displaying the prompt but before accepting input (which is where you'd want ). There are also no events specific to the right-side prompt only. FWIW, there's also no equivalent in fish—"instead it leaves the lines indented to show that the commandline isn’t complete yet"—but the lack of and sequences in the above didn't seem to have any noticeable impact on VS Code's ability to parse the terminal in my testing.
ah I see, I think this stuff should still work though. We actually don't currently use some of these positions and the 633 E sequence kind of removes the need for them all together. So if there are limitations like this we can just take note for the future, like when finalizing the sequences this month. The limitations imposed on us by the Windows backend are much more frustrating to deal with than this sounds If you want to put a PR out with just the script as a starting point (just the script) we could then give it a try and see if we can get it in as an experimental thing. I guess just manually installing until it's considered stable, plus the automatic injection was a handful for the other shells. You could also move the 633 A to just after 633 D, I'd expect that to work fine.
I've been wanting to do this since last month, and comment finally motivated me to put up a fish plugin here: The trick I have seen in is that they wait for a event and then initialize the code, at which time the prompt function should be ready however they are defined.
FYI those sequences may change as they are yet to be finalized ().
Now that has reminded me fish can do e.g. (which I just... totally blanked on yesterday ), I think I could put together an experimental PR for this—one that could be easily tweaked if/when the escape sequences are finalized.
Also thanks to a PR from the fish history file is now loaded so pulls from it when fish is active !
that would be fantastic
Thanks everyone! The script should be available in tomorrow's Insiders, see for manual install instructions (replace with ) I'll keep this issue open until we no longer consider it experimental.
The new function does not work properly in my case. My fish configuration uses a right prompt and shows the exit code of the command (green check mark). The exit code is always shown as good, even if the executed program returns a non-0 code. The right prompt is also misaligned. It is one line below where it is supposed to be. ! The status code issue seems to be caused by executing first, because this will overwrite and . The misaligned right prompt seems to relate to some newline shenanigans fish does. It removes the last newline from the prompt, but since is after the prompt it doesn't work any longer. I found these related links: , I change the above snippet to this it seems to work better for me.
thanks for the report! Do you want to submit a PR or should I try out the fix?
I am not interested in progressing this further or submitting a PR.
no worries, thanks for reporting
Isn't this already done? Or is this about automatic integration?
I was keeping it open until the kinks were worked out, plus automatic injection would be great if it's possible. Not sure anyone has looked into it yet.
should we change the title of this issue or create a new one to capture automatic injection?
i think the right way to add automatic injection would be to append a directory to that contains the integration script in a subdirectory (see )
we wouldn't be able to stick it in XDGDATADIRS though in case a user has a file there already. Changing XDGDATADIRS also seems dangerous and I think this would only work on Linux
it sounds like you may be confused as to what XDGDATADIRS is so i whipped up a pr for this, with links to the relevant spec and fish docs. alternatively i'm confused as to what you might mean. XDGDATADIRS is a set of directories to search for data files, ordered by preference. we'd be adding a directory to the end of it so what a user may already have there is irrelevant, and our directory would be part of the vscode distribution so the user really shouldn't have any files in there. aside from that user things go in XDGDATAHOME, XDGDATADIRS is for system components. i'm not sure what danger you see there. we're adding another directory to find data files in; we're not preventing any other data files from being found. this is documented universal fish behavior on any system it supports. i linked the literal default fish configuration above that demonstrates this. also back when i last used a mac most tools did support the xdg base directories, including fish (and nix, which makes rather heavy use of XDGDATADIRS). the only ones that didn't still don't on linux (like electron ).
oh it's a list of dirs, I thought this was setting a single dir. And you're right we don't need to worry about Windows here. Thanks, will check out the PR soon
Since the issue is now closed, is the problem reported here something you would still want to fix? It doesn't seem to be fixed on main so far.
thanks for the reminder, I forked it off to
To verify: Make sure fish is installed on your system (macOS or Linux) Launch a fish shell and verify the shell integration decorations should up to the left of the terminal
yep, works for me!
Unfortunately this does not work in a newly-installed fish shell via homebrew on macOS. https://user- Pty host logs:
what's your ? Also what is the output of ?
works for me with this info: !
did you manually install shell integration? This issue is about automatic injection, the update in the original issue was to help users manually activate it before this was done.
Yes I did
and disabled automatic injection (set ) as you see in the screenshot. it also works for me in a subshell, so I know that i'm testing / verifying manual injection
it also works for me with automatic injection
is 3.6.0, and the shell integration path is
Looking at the code it doesn't look like we actually copy a file to :
hm, the path does appear to exist <img width="1045" alt="image" src="https://user-"Manually executing it with results in an exit code of 1 and no output, however
yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt
Argh, I had removed the manual integration but still have other FinalTerm-compatible shell integration and probably thought this was working because of that On 26. Jan 2023, at 18:19, Megan Rogge yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID:
To verify make sure you don't manually activate shell integration in your , then check with and without and make sure shell integration works and doesn't work respectively.
When I open a terminal in the fish shell and run some commands, then run "Run recent command", the commands in the fish terminal don't show up, I assume that means it's not working for me
works for me: <img width="741" alt="Screenshot 2023-05-30 at 2 43 13 pm" src=""Do you see the grey/blue/red dot?
No, I guess shell integration is not enabled in the fish profile, I'm not sure how to troubleshoot that.
Is there supposed to be automatic integration in stable VSCode now? It doesn't seem to be working for me, but manual integration still does. Open and make sure it contains the manual integration code:
he's trying to test the newly fixed automatic injection in Insiders
can you run ? Also enabling trace logs and getting the pty host log when launching would be helpful (be mindful of any sensitive environment variables)
Here's my pty host log which includes
this isn't working for me after I removed my !
what do you mean by removed your XDGDATADIRS? weird, it's there so it should be run afaik. any idea what could be going wrong here wrt the XDGDATADIR auto activation?
I think I had manually enabled fish shell integration which is why it was working. In order to undo that, to test automatic injection, I removed that directory. Then it didn't work
IE my expectation was after undoing manual injection, it would work automatically. That wasn't the case.
I had misunderstood how this injection works because it is different from that of and . Deleting my in the comment above was the reason I saw it not working. I now see it working. !
since it's working for and I we'll close this and include it in the release notes. It would be good to get to the bottom of your issue, we can track that in another issue? We can have a call to investigate when you're free if that works.
Sure, call any time
Not really, sorry. Maybe the snap packaging interferes somehow? From your shell session, are and present?
We investigated, it ended up being the fish version being too old. After the update it worked great! Thanks for all the help
This isn't working for me in 1.79.0 (non-insider), as far as I can see the fish config is there but XDGDATADIRS isn't getting set. And looking at the code I found -- what happened?
we had to disable it because it was printing an error when starting up for someone on the team: For some reason was undefined at the time, it got set later, after our applied.
Looking at again I believe this would happen when something we need, like , is configured in either or in a file with a basename that's sorted before the one we expose. The file is intentionally read last so people can override vendor configuration, so since we need to run after user configuration maybe providing vendor configuration is just not the way to go here… sorry Maybe instead we could invoke fish with ? That would ensure the integration happens after any configuration but before* interactive input. If I have the spoons and noone beats me to it I'll try to whip up a PR for that next week.
One way to make sure something runs after the user's but before interactive input is to put the necessary code in a self-erasing function tied to the , e.g.: This can be placed in the appropriate vendor-config directory as simply (e.g.) with no need to worry about sorting order. The function will be defined during startup, executed just before printing the first prompt, then immediately undefined so it doesn't run twice.
I tried something like that thanks to your suggestion. It's not working atm and not sure why... lmk if you see what could be wrong here
I think you also need to add to this function:
Removing verification-needed as this was covered by a test plan item.

'out-build/vs/base/node/ps.sh', // Terminal shell integration <del> 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration.fish', </del> 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration.ps1', 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh', 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration-env.zsh', 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration-profile.zsh', 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration-rc.zsh', 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration-login.zsh', <del> 'out-build/vs/workbench/contrib/terminal/browser/media/shellIntegration.fish', </del> <ins> 'out-build/vs/workbench/contrib/terminal/browser/media/fish_xdg_data/fish/vendor_conf.d/shellIntegration.fish', </ins> '!**/test/**' ];


Question:
Parent issue Update: Activate the fish shell integration by following these instructions: We're keeping this open until automatic injection is looked into.
Deferring to focus on polishing how shell integration works in general
Final implementation details aside, fish's event handing will make at least some of this dead easy: Some will be more difficult, at least to deploy auto-magically, because fish's are the output of shell functions, not the contents of variables: So to transparently preserve the user's original prompt, like the bash script does, would require modifying a shell function on-the-fly, not just a variable. Yikes. That said, I put the above code, plus the following, in my own config— —and I had all of VS Code's working perfectly with VS Code v1.70.0 + fish 3.5.1. It's only a proof of concept, but hopefully this saves somebody a few web searches down the line, at least. :)
very handy info thanks! The bash script handles both PS1 and PRONPT_COMMAND, might be able to wrap the function automatically in a similar way?
Well, fish doesn't have either: if you want something to run right before the prompt displays, you put it in a function with . There is, alas, no event handler that runs after displaying the prompt but before accepting input (which is where you'd want ). There are also no events specific to the right-side prompt only. FWIW, there's also no equivalent in fish—"instead it leaves the lines indented to show that the commandline isn’t complete yet"—but the lack of and sequences in the above didn't seem to have any noticeable impact on VS Code's ability to parse the terminal in my testing.
ah I see, I think this stuff should still work though. We actually don't currently use some of these positions and the 633 E sequence kind of removes the need for them all together. So if there are limitations like this we can just take note for the future, like when finalizing the sequences this month. The limitations imposed on us by the Windows backend are much more frustrating to deal with than this sounds If you want to put a PR out with just the script as a starting point (just the script) we could then give it a try and see if we can get it in as an experimental thing. I guess just manually installing until it's considered stable, plus the automatic injection was a handful for the other shells. You could also move the 633 A to just after 633 D, I'd expect that to work fine.
I've been wanting to do this since last month, and comment finally motivated me to put up a fish plugin here: The trick I have seen in is that they wait for a event and then initialize the code, at which time the prompt function should be ready however they are defined.
FYI those sequences may change as they are yet to be finalized ().
Now that has reminded me fish can do e.g. (which I just... totally blanked on yesterday ), I think I could put together an experimental PR for this—one that could be easily tweaked if/when the escape sequences are finalized.
Also thanks to a PR from the fish history file is now loaded so pulls from it when fish is active !
that would be fantastic
Thanks everyone! The script should be available in tomorrow's Insiders, see for manual install instructions (replace with ) I'll keep this issue open until we no longer consider it experimental.
The new function does not work properly in my case. My fish configuration uses a right prompt and shows the exit code of the command (green check mark). The exit code is always shown as good, even if the executed program returns a non-0 code. The right prompt is also misaligned. It is one line below where it is supposed to be. ! The status code issue seems to be caused by executing first, because this will overwrite and . The misaligned right prompt seems to relate to some newline shenanigans fish does. It removes the last newline from the prompt, but since is after the prompt it doesn't work any longer. I found these related links: , I change the above snippet to this it seems to work better for me.
thanks for the report! Do you want to submit a PR or should I try out the fix?
I am not interested in progressing this further or submitting a PR.
no worries, thanks for reporting
Isn't this already done? Or is this about automatic integration?
I was keeping it open until the kinks were worked out, plus automatic injection would be great if it's possible. Not sure anyone has looked into it yet.
should we change the title of this issue or create a new one to capture automatic injection?
i think the right way to add automatic injection would be to append a directory to that contains the integration script in a subdirectory (see )
we wouldn't be able to stick it in XDGDATADIRS though in case a user has a file there already. Changing XDGDATADIRS also seems dangerous and I think this would only work on Linux
it sounds like you may be confused as to what XDGDATADIRS is so i whipped up a pr for this, with links to the relevant spec and fish docs. alternatively i'm confused as to what you might mean. XDGDATADIRS is a set of directories to search for data files, ordered by preference. we'd be adding a directory to the end of it so what a user may already have there is irrelevant, and our directory would be part of the vscode distribution so the user really shouldn't have any files in there. aside from that user things go in XDGDATAHOME, XDGDATADIRS is for system components. i'm not sure what danger you see there. we're adding another directory to find data files in; we're not preventing any other data files from being found. this is documented universal fish behavior on any system it supports. i linked the literal default fish configuration above that demonstrates this. also back when i last used a mac most tools did support the xdg base directories, including fish (and nix, which makes rather heavy use of XDGDATADIRS). the only ones that didn't still don't on linux (like electron ).
oh it's a list of dirs, I thought this was setting a single dir. And you're right we don't need to worry about Windows here. Thanks, will check out the PR soon
Since the issue is now closed, is the problem reported here something you would still want to fix? It doesn't seem to be fixed on main so far.
thanks for the reminder, I forked it off to
To verify: Make sure fish is installed on your system (macOS or Linux) Launch a fish shell and verify the shell integration decorations should up to the left of the terminal
yep, works for me!
Unfortunately this does not work in a newly-installed fish shell via homebrew on macOS. https://user- Pty host logs:
what's your ? Also what is the output of ?
works for me with this info: !
did you manually install shell integration? This issue is about automatic injection, the update in the original issue was to help users manually activate it before this was done.
Yes I did
and disabled automatic injection (set ) as you see in the screenshot. it also works for me in a subshell, so I know that i'm testing / verifying manual injection
it also works for me with automatic injection
is 3.6.0, and the shell integration path is
Looking at the code it doesn't look like we actually copy a file to :
hm, the path does appear to exist <img width="1045" alt="image" src="https://user-"Manually executing it with results in an exit code of 1 and no output, however
yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt
Argh, I had removed the manual integration but still have other FinalTerm-compatible shell integration and probably thought this was working because of that On 26. Jan 2023, at 18:19, Megan Rogge yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID:
To verify make sure you don't manually activate shell integration in your , then check with and without and make sure shell integration works and doesn't work respectively.
When I open a terminal in the fish shell and run some commands, then run "Run recent command", the commands in the fish terminal don't show up, I assume that means it's not working for me
works for me: <img width="741" alt="Screenshot 2023-05-30 at 2 43 13 pm" src=""Do you see the grey/blue/red dot?
No, I guess shell integration is not enabled in the fish profile, I'm not sure how to troubleshoot that.
Is there supposed to be automatic integration in stable VSCode now? It doesn't seem to be working for me, but manual integration still does. Open and make sure it contains the manual integration code:
he's trying to test the newly fixed automatic injection in Insiders
can you run ? Also enabling trace logs and getting the pty host log when launching would be helpful (be mindful of any sensitive environment variables)
Here's my pty host log which includes
this isn't working for me after I removed my !
what do you mean by removed your XDGDATADIRS? weird, it's there so it should be run afaik. any idea what could be going wrong here wrt the XDGDATADIR auto activation?
I think I had manually enabled fish shell integration which is why it was working. In order to undo that, to test automatic injection, I removed that directory. Then it didn't work
IE my expectation was after undoing manual injection, it would work automatically. That wasn't the case.
I had misunderstood how this injection works because it is different from that of and . Deleting my in the comment above was the reason I saw it not working. I now see it working. !
since it's working for and I we'll close this and include it in the release notes. It would be good to get to the bottom of your issue, we can track that in another issue? We can have a call to investigate when you're free if that works.
Sure, call any time
Not really, sorry. Maybe the snap packaging interferes somehow? From your shell session, are and present?
We investigated, it ended up being the fish version being too old. After the update it worked great! Thanks for all the help
This isn't working for me in 1.79.0 (non-insider), as far as I can see the fish config is there but XDGDATADIRS isn't getting set. And looking at the code I found -- what happened?
we had to disable it because it was printing an error when starting up for someone on the team: For some reason was undefined at the time, it got set later, after our applied.
Looking at again I believe this would happen when something we need, like , is configured in either or in a file with a basename that's sorted before the one we expose. The file is intentionally read last so people can override vendor configuration, so since we need to run after user configuration maybe providing vendor configuration is just not the way to go here… sorry Maybe instead we could invoke fish with ? That would ensure the integration happens after any configuration but before* interactive input. If I have the spoons and noone beats me to it I'll try to whip up a PR for that next week.
One way to make sure something runs after the user's but before interactive input is to put the necessary code in a self-erasing function tied to the , e.g.: This can be placed in the appropriate vendor-config directory as simply (e.g.) with no need to worry about sorting order. The function will be defined during startup, executed just before printing the first prompt, then immediately undefined so it doesn't run twice.
I tried something like that thanks to your suggestion. It's not working atm and not sure why... lmk if you see what could be wrong here
I think you also need to add to this function:
Removing verification-needed as this was covered by a test plan item.

'out-build/vs/workbench/browser/media/*-theme.css', 'out-build/vs/workbench/contrib/debug/**/*.json', 'out-build/vs/workbench/contrib/externalTerminal/**/*.scpt', <del> 'out-build/vs/workbench/contrib/terminal/browser/media/*.fish', </del> <ins> 'out-build/vs/workbench/contrib/terminal/browser/media/fish_xdg_data/fish/vendor_conf.d/*.fish', </ins> 'out-build/vs/workbench/contrib/terminal/browser/media/*.ps1', 'out-build/vs/workbench/contrib/terminal/browser/media/*.sh', 'out-build/vs/workbench/contrib/terminal/browser/media/*.zsh',


Question:
Parent issue Update: Activate the fish shell integration by following these instructions: We're keeping this open until automatic injection is looked into.
Deferring to focus on polishing how shell integration works in general
Final implementation details aside, fish's event handing will make at least some of this dead easy: Some will be more difficult, at least to deploy auto-magically, because fish's are the output of shell functions, not the contents of variables: So to transparently preserve the user's original prompt, like the bash script does, would require modifying a shell function on-the-fly, not just a variable. Yikes. That said, I put the above code, plus the following, in my own config— —and I had all of VS Code's working perfectly with VS Code v1.70.0 + fish 3.5.1. It's only a proof of concept, but hopefully this saves somebody a few web searches down the line, at least. :)
very handy info thanks! The bash script handles both PS1 and PRONPT_COMMAND, might be able to wrap the function automatically in a similar way?
Well, fish doesn't have either: if you want something to run right before the prompt displays, you put it in a function with . There is, alas, no event handler that runs after displaying the prompt but before accepting input (which is where you'd want ). There are also no events specific to the right-side prompt only. FWIW, there's also no equivalent in fish—"instead it leaves the lines indented to show that the commandline isn’t complete yet"—but the lack of and sequences in the above didn't seem to have any noticeable impact on VS Code's ability to parse the terminal in my testing.
ah I see, I think this stuff should still work though. We actually don't currently use some of these positions and the 633 E sequence kind of removes the need for them all together. So if there are limitations like this we can just take note for the future, like when finalizing the sequences this month. The limitations imposed on us by the Windows backend are much more frustrating to deal with than this sounds If you want to put a PR out with just the script as a starting point (just the script) we could then give it a try and see if we can get it in as an experimental thing. I guess just manually installing until it's considered stable, plus the automatic injection was a handful for the other shells. You could also move the 633 A to just after 633 D, I'd expect that to work fine.
I've been wanting to do this since last month, and comment finally motivated me to put up a fish plugin here: The trick I have seen in is that they wait for a event and then initialize the code, at which time the prompt function should be ready however they are defined.
FYI those sequences may change as they are yet to be finalized ().
Now that has reminded me fish can do e.g. (which I just... totally blanked on yesterday ), I think I could put together an experimental PR for this—one that could be easily tweaked if/when the escape sequences are finalized.
Also thanks to a PR from the fish history file is now loaded so pulls from it when fish is active !
that would be fantastic
Thanks everyone! The script should be available in tomorrow's Insiders, see for manual install instructions (replace with ) I'll keep this issue open until we no longer consider it experimental.
The new function does not work properly in my case. My fish configuration uses a right prompt and shows the exit code of the command (green check mark). The exit code is always shown as good, even if the executed program returns a non-0 code. The right prompt is also misaligned. It is one line below where it is supposed to be. ! The status code issue seems to be caused by executing first, because this will overwrite and . The misaligned right prompt seems to relate to some newline shenanigans fish does. It removes the last newline from the prompt, but since is after the prompt it doesn't work any longer. I found these related links: , I change the above snippet to this it seems to work better for me.
thanks for the report! Do you want to submit a PR or should I try out the fix?
I am not interested in progressing this further or submitting a PR.
no worries, thanks for reporting
Isn't this already done? Or is this about automatic integration?
I was keeping it open until the kinks were worked out, plus automatic injection would be great if it's possible. Not sure anyone has looked into it yet.
should we change the title of this issue or create a new one to capture automatic injection?
i think the right way to add automatic injection would be to append a directory to that contains the integration script in a subdirectory (see )
we wouldn't be able to stick it in XDGDATADIRS though in case a user has a file there already. Changing XDGDATADIRS also seems dangerous and I think this would only work on Linux
it sounds like you may be confused as to what XDGDATADIRS is so i whipped up a pr for this, with links to the relevant spec and fish docs. alternatively i'm confused as to what you might mean. XDGDATADIRS is a set of directories to search for data files, ordered by preference. we'd be adding a directory to the end of it so what a user may already have there is irrelevant, and our directory would be part of the vscode distribution so the user really shouldn't have any files in there. aside from that user things go in XDGDATAHOME, XDGDATADIRS is for system components. i'm not sure what danger you see there. we're adding another directory to find data files in; we're not preventing any other data files from being found. this is documented universal fish behavior on any system it supports. i linked the literal default fish configuration above that demonstrates this. also back when i last used a mac most tools did support the xdg base directories, including fish (and nix, which makes rather heavy use of XDGDATADIRS). the only ones that didn't still don't on linux (like electron ).
oh it's a list of dirs, I thought this was setting a single dir. And you're right we don't need to worry about Windows here. Thanks, will check out the PR soon
Since the issue is now closed, is the problem reported here something you would still want to fix? It doesn't seem to be fixed on main so far.
thanks for the reminder, I forked it off to
To verify: Make sure fish is installed on your system (macOS or Linux) Launch a fish shell and verify the shell integration decorations should up to the left of the terminal
yep, works for me!
Unfortunately this does not work in a newly-installed fish shell via homebrew on macOS. https://user- Pty host logs:
what's your ? Also what is the output of ?
works for me with this info: !
did you manually install shell integration? This issue is about automatic injection, the update in the original issue was to help users manually activate it before this was done.
Yes I did
and disabled automatic injection (set ) as you see in the screenshot. it also works for me in a subshell, so I know that i'm testing / verifying manual injection
it also works for me with automatic injection
is 3.6.0, and the shell integration path is
Looking at the code it doesn't look like we actually copy a file to :
hm, the path does appear to exist <img width="1045" alt="image" src="https://user-"Manually executing it with results in an exit code of 1 and no output, however
yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt
Argh, I had removed the manual integration but still have other FinalTerm-compatible shell integration and probably thought this was working because of that On 26. Jan 2023, at 18:19, Megan Rogge yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID:
To verify make sure you don't manually activate shell integration in your , then check with and without and make sure shell integration works and doesn't work respectively.
When I open a terminal in the fish shell and run some commands, then run "Run recent command", the commands in the fish terminal don't show up, I assume that means it's not working for me
works for me: <img width="741" alt="Screenshot 2023-05-30 at 2 43 13 pm" src=""Do you see the grey/blue/red dot?
No, I guess shell integration is not enabled in the fish profile, I'm not sure how to troubleshoot that.
Is there supposed to be automatic integration in stable VSCode now? It doesn't seem to be working for me, but manual integration still does. Open and make sure it contains the manual integration code:
he's trying to test the newly fixed automatic injection in Insiders
can you run ? Also enabling trace logs and getting the pty host log when launching would be helpful (be mindful of any sensitive environment variables)
Here's my pty host log which includes
this isn't working for me after I removed my !
what do you mean by removed your XDGDATADIRS? weird, it's there so it should be run afaik. any idea what could be going wrong here wrt the XDGDATADIR auto activation?
I think I had manually enabled fish shell integration which is why it was working. In order to undo that, to test automatic injection, I removed that directory. Then it didn't work
IE my expectation was after undoing manual injection, it would work automatically. That wasn't the case.
I had misunderstood how this injection works because it is different from that of and . Deleting my in the comment above was the reason I saw it not working. I now see it working. !
since it's working for and I we'll close this and include it in the release notes. It would be good to get to the bottom of your issue, we can track that in another issue? We can have a call to investigate when you're free if that works.
Sure, call any time
Not really, sorry. Maybe the snap packaging interferes somehow? From your shell session, are and present?
We investigated, it ended up being the fish version being too old. After the update it worked great! Thanks for all the help
This isn't working for me in 1.79.0 (non-insider), as far as I can see the fish config is there but XDGDATADIRS isn't getting set. And looking at the code I found -- what happened?
we had to disable it because it was printing an error when starting up for someone on the team: For some reason was undefined at the time, it got set later, after our applied.
Looking at again I believe this would happen when something we need, like , is configured in either or in a file with a basename that's sorted before the one we expose. The file is intentionally read last so people can override vendor configuration, so since we need to run after user configuration maybe providing vendor configuration is just not the way to go here… sorry Maybe instead we could invoke fish with ? That would ensure the integration happens after any configuration but before* interactive input. If I have the spoons and noone beats me to it I'll try to whip up a PR for that next week.
One way to make sure something runs after the user's but before interactive input is to put the necessary code in a self-erasing function tied to the , e.g.: This can be placed in the appropriate vendor-config directory as simply (e.g.) with no need to worry about sorting order. The function will be defined during startup, executed just before printing the first prompt, then immediately undefined so it doesn't run twice.
I tried something like that thanks to your suggestion. It's not working atm and not sure why... lmk if you see what could be wrong here
I think you also need to add to this function:
Removing verification-needed as this was covered by a test plan item.

// Usage: `[[ "$TERM_PROGRAM" == "vscode" ]] && . "$(code --locate-shell-integration-path zsh)"` case 'zsh': file = 'shellIntegration-rc.zsh'; break; // Usage: `string match -q "$TERM_PROGRAM" "vscode"; and . (code --locate-shell-integration-path fish)` <del> case 'fish': file = 'shellIntegration.fish'; break; </del> <ins> case 'fish': file = 'fish_xdg_data/fish/vendor_conf.d/shellIntegration.fish'; break; </ins> default: throw new Error('Error using --locate-shell-integration-path: Invalid shell type'); } console.log(join(getAppRoot(), 'out', 'vs', 'workbench', 'contrib', 'terminal', 'browser', 'media', file));


Question:
Parent issue Update: Activate the fish shell integration by following these instructions: We're keeping this open until automatic injection is looked into.
Deferring to focus on polishing how shell integration works in general
Final implementation details aside, fish's event handing will make at least some of this dead easy: Some will be more difficult, at least to deploy auto-magically, because fish's are the output of shell functions, not the contents of variables: So to transparently preserve the user's original prompt, like the bash script does, would require modifying a shell function on-the-fly, not just a variable. Yikes. That said, I put the above code, plus the following, in my own config— —and I had all of VS Code's working perfectly with VS Code v1.70.0 + fish 3.5.1. It's only a proof of concept, but hopefully this saves somebody a few web searches down the line, at least. :)
very handy info thanks! The bash script handles both PS1 and PRONPT_COMMAND, might be able to wrap the function automatically in a similar way?
Well, fish doesn't have either: if you want something to run right before the prompt displays, you put it in a function with . There is, alas, no event handler that runs after displaying the prompt but before accepting input (which is where you'd want ). There are also no events specific to the right-side prompt only. FWIW, there's also no equivalent in fish—"instead it leaves the lines indented to show that the commandline isn’t complete yet"—but the lack of and sequences in the above didn't seem to have any noticeable impact on VS Code's ability to parse the terminal in my testing.
ah I see, I think this stuff should still work though. We actually don't currently use some of these positions and the 633 E sequence kind of removes the need for them all together. So if there are limitations like this we can just take note for the future, like when finalizing the sequences this month. The limitations imposed on us by the Windows backend are much more frustrating to deal with than this sounds If you want to put a PR out with just the script as a starting point (just the script) we could then give it a try and see if we can get it in as an experimental thing. I guess just manually installing until it's considered stable, plus the automatic injection was a handful for the other shells. You could also move the 633 A to just after 633 D, I'd expect that to work fine.
I've been wanting to do this since last month, and comment finally motivated me to put up a fish plugin here: The trick I have seen in is that they wait for a event and then initialize the code, at which time the prompt function should be ready however they are defined.
FYI those sequences may change as they are yet to be finalized ().
Now that has reminded me fish can do e.g. (which I just... totally blanked on yesterday ), I think I could put together an experimental PR for this—one that could be easily tweaked if/when the escape sequences are finalized.
Also thanks to a PR from the fish history file is now loaded so pulls from it when fish is active !
that would be fantastic
Thanks everyone! The script should be available in tomorrow's Insiders, see for manual install instructions (replace with ) I'll keep this issue open until we no longer consider it experimental.
The new function does not work properly in my case. My fish configuration uses a right prompt and shows the exit code of the command (green check mark). The exit code is always shown as good, even if the executed program returns a non-0 code. The right prompt is also misaligned. It is one line below where it is supposed to be. ! The status code issue seems to be caused by executing first, because this will overwrite and . The misaligned right prompt seems to relate to some newline shenanigans fish does. It removes the last newline from the prompt, but since is after the prompt it doesn't work any longer. I found these related links: , I change the above snippet to this it seems to work better for me.
thanks for the report! Do you want to submit a PR or should I try out the fix?
I am not interested in progressing this further or submitting a PR.
no worries, thanks for reporting
Isn't this already done? Or is this about automatic integration?
I was keeping it open until the kinks were worked out, plus automatic injection would be great if it's possible. Not sure anyone has looked into it yet.
should we change the title of this issue or create a new one to capture automatic injection?
i think the right way to add automatic injection would be to append a directory to that contains the integration script in a subdirectory (see )
we wouldn't be able to stick it in XDGDATADIRS though in case a user has a file there already. Changing XDGDATADIRS also seems dangerous and I think this would only work on Linux
it sounds like you may be confused as to what XDGDATADIRS is so i whipped up a pr for this, with links to the relevant spec and fish docs. alternatively i'm confused as to what you might mean. XDGDATADIRS is a set of directories to search for data files, ordered by preference. we'd be adding a directory to the end of it so what a user may already have there is irrelevant, and our directory would be part of the vscode distribution so the user really shouldn't have any files in there. aside from that user things go in XDGDATAHOME, XDGDATADIRS is for system components. i'm not sure what danger you see there. we're adding another directory to find data files in; we're not preventing any other data files from being found. this is documented universal fish behavior on any system it supports. i linked the literal default fish configuration above that demonstrates this. also back when i last used a mac most tools did support the xdg base directories, including fish (and nix, which makes rather heavy use of XDGDATADIRS). the only ones that didn't still don't on linux (like electron ).
oh it's a list of dirs, I thought this was setting a single dir. And you're right we don't need to worry about Windows here. Thanks, will check out the PR soon
Since the issue is now closed, is the problem reported here something you would still want to fix? It doesn't seem to be fixed on main so far.
thanks for the reminder, I forked it off to
To verify: Make sure fish is installed on your system (macOS or Linux) Launch a fish shell and verify the shell integration decorations should up to the left of the terminal
yep, works for me!
Unfortunately this does not work in a newly-installed fish shell via homebrew on macOS. https://user- Pty host logs:
what's your ? Also what is the output of ?
works for me with this info: !
did you manually install shell integration? This issue is about automatic injection, the update in the original issue was to help users manually activate it before this was done.
Yes I did
and disabled automatic injection (set ) as you see in the screenshot. it also works for me in a subshell, so I know that i'm testing / verifying manual injection
it also works for me with automatic injection
is 3.6.0, and the shell integration path is
Looking at the code it doesn't look like we actually copy a file to :
hm, the path does appear to exist <img width="1045" alt="image" src="https://user-"Manually executing it with results in an exit code of 1 and no output, however
yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt
Argh, I had removed the manual integration but still have other FinalTerm-compatible shell integration and probably thought this was working because of that On 26. Jan 2023, at 18:19, Megan Rogge yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID:
To verify make sure you don't manually activate shell integration in your , then check with and without and make sure shell integration works and doesn't work respectively.
When I open a terminal in the fish shell and run some commands, then run "Run recent command", the commands in the fish terminal don't show up, I assume that means it's not working for me
works for me: <img width="741" alt="Screenshot 2023-05-30 at 2 43 13 pm" src=""Do you see the grey/blue/red dot?
No, I guess shell integration is not enabled in the fish profile, I'm not sure how to troubleshoot that.
Is there supposed to be automatic integration in stable VSCode now? It doesn't seem to be working for me, but manual integration still does. Open and make sure it contains the manual integration code:
he's trying to test the newly fixed automatic injection in Insiders
can you run ? Also enabling trace logs and getting the pty host log when launching would be helpful (be mindful of any sensitive environment variables)
Here's my pty host log which includes
this isn't working for me after I removed my !
what do you mean by removed your XDGDATADIRS? weird, it's there so it should be run afaik. any idea what could be going wrong here wrt the XDGDATADIR auto activation?
I think I had manually enabled fish shell integration which is why it was working. In order to undo that, to test automatic injection, I removed that directory. Then it didn't work
IE my expectation was after undoing manual injection, it would work automatically. That wasn't the case.
I had misunderstood how this injection works because it is different from that of and . Deleting my in the comment above was the reason I saw it not working. I now see it working. !
since it's working for and I we'll close this and include it in the release notes. It would be good to get to the bottom of your issue, we can track that in another issue? We can have a call to investigate when you're free if that works.
Sure, call any time
Not really, sorry. Maybe the snap packaging interferes somehow? From your shell session, are and present?
We investigated, it ended up being the fish version being too old. After the update it worked great! Thanks for all the help
This isn't working for me in 1.79.0 (non-insider), as far as I can see the fish config is there but XDGDATADIRS isn't getting set. And looking at the code I found -- what happened?
we had to disable it because it was printing an error when starting up for someone on the team: For some reason was undefined at the time, it got set later, after our applied.
Looking at again I believe this would happen when something we need, like , is configured in either or in a file with a basename that's sorted before the one we expose. The file is intentionally read last so people can override vendor configuration, so since we need to run after user configuration maybe providing vendor configuration is just not the way to go here… sorry Maybe instead we could invoke fish with ? That would ensure the integration happens after any configuration but before* interactive input. If I have the spoons and noone beats me to it I'll try to whip up a PR for that next week.
One way to make sure something runs after the user's but before interactive input is to put the necessary code in a self-erasing function tied to the , e.g.: This can be placed in the appropriate vendor-config directory as simply (e.g.) with no need to worry about sorting order. The function will be defined during startup, executed just before printing the first prompt, then immediately undefined so it doesn't run twice.
I tried something like that thanks to your suggestion. It's not working atm and not sure why... lmk if you see what could be wrong here
I think you also need to add to this function:
Removing verification-needed as this was covered by a test plan item.

// The injection mechanism used for fish is to add a custom dir to $XDG_DATA_DIRS which // is similar to $ZDOTDIR in zsh but contains a list of directories to run from. const oldDataDirs = env?.XDG_DATA_DIRS ?? '/usr/local/share:/usr/share'; <del> const newDataDir = path.join(appRoot, 'out/vs/workbench/contrib/xdg_data'); </del> <ins> const newDataDir = path.join(appRoot, 'out/vs/workbench/contrib/terminal/browser/media/fish_xdg_data'); </ins> envMixin['XDG_DATA_DIRS'] = `${oldDataDirs}:${newDataDir}`; addEnvMixinPathPrefix(options, envMixin); return { newArgs: undefined, envMixin };