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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

deserialize(serialized: ISerializedCommandDetectionCapability): void; } <ins> export interface IHandleCommandStartOptions { /** * Whether to allow an empty command to be registered. This should be used to support certain * shell integration scripts/features where tracking the command line may not be possible. */ ignoreCommandLine?: boolean; } </ins> export interface INaiveCwdDetectionCapability { readonly type: TerminalCapability.NaiveCwdDetection; readonly onDidChangeCwd: Event<string>;


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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

import { debounce } from 'vs/base/common/decorators'; import { Emitter } from 'vs/base/common/event'; import { ILogService } from 'vs/platform/log/common/log'; <del> import { ICommandDetectionCapability, TerminalCapability, ITerminalCommand } from 'vs/platform/terminal/common/capabilities/capabilities'; </del> <ins> import { ICommandDetectionCapability, TerminalCapability, ITerminalCommand, IHandleCommandStartOptions } from 'vs/platform/terminal/common/capabilities/capabilities'; </ins> import { ISerializedCommand, ISerializedCommandDetectionCapability } from 'vs/platform/terminal/common/terminalProcess'; // Importing types is safe in any layer // eslint-disable-next-line code-import-patterns


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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

private _commandMarkers: IMarker[] = []; private _dimensions: ITerminalDimensions; private __isCommandStorageDisabled: boolean = false; <ins> private _handleCommandStartOptions?: IHandleCommandStartOptions; </ins> get commands(): readonly ITerminalCommand[] { return this._commands; } get executingCommand(): string | undefined { return this._currentCommand.command; } // TODO: as is unsafe here and it duplicates behavor of executingCommand


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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

this._logService.debug('CommandDetectionCapability#handleRightPromptEnd', this._currentCommand.commandRightPromptEndX); } <del> handleCommandStart(): void { </del> <ins> handleCommandStart(options?: IHandleCommandStartOptions): void { this._handleCommandStartOptions = options; </ins> // Only update the column if the line has already been set if (this._currentCommand.commandStartMarker?.line === this._terminal.buffer.active.cursorY) { this._currentCommand.commandStartX = this._terminal.buffer.active.cursorX;


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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

return; } <del> if (command !== undefined && !command.startsWith('')) { </del> <ins> if ((command !== undefined && !command.startsWith('')) || this._handleCommandStartOptions?.ignoreCommandLine) { </ins> const buffer = this._terminal.buffer.active; const timestamp = Date.now(); const executedMarker = this._currentCommand.commandExecutedMarker; const endMarker = this._currentCommand.commandFinishedMarker; const newCommand: ITerminalCommand = { <del> command, </del> <ins> command: this._handleCommandStartOptions?.ignoreCommandLine ? '' : (command || ''), </ins> marker: this._currentCommand.commandStartMarker, endMarker, executedMarker,


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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

} this._currentCommand.previousCommandMarker = this._currentCommand.commandStartMarker; this._currentCommand = {}; <ins> this._handleCommandStartOptions = undefined; </ins> } private _preHandleCommandFinishedWindows(): void {


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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

*--------------------------------------------------------------------------------------------*/ import { IShellIntegration } from 'vs/platform/terminal/common/terminal'; <del> import { Disposable, toDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { Disposable, dispose, IDisposable, toDisposable } from 'vs/base/common/lifecycle'; </ins> import { TerminalCapabilityStore } from 'vs/platform/terminal/common/capabilities/terminalCapabilityStore'; import { CommandDetectionCapability } from 'vs/platform/terminal/common/capabilities/commandDetectionCapability'; import { CwdDetectionCapability } from 'vs/platform/terminal/common/capabilities/cwdDetectionCapability';


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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

readonly capabilities = new TerminalCapabilityStore(); private _hasUpdatedTelemetry: boolean = false; private _activationTimeout: any; <ins> private _commonProtocolDisposables: IDisposable[] = []; </ins> constructor( private readonly _disableTelemetry: boolean | 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 <!-- 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: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

@ILogService private readonly _logService: ILogService ) { super(); <del> this._register(toDisposable(() => this._clearActivationTimeout())); </del> <ins> this._register(toDisposable(() => { this._clearActivationTimeout(); this._disposeCommonProtocol(); })); } private _disposeCommonProtocol(): void { dispose(this._commonProtocolDisposables); this._commonProtocolDisposables.length = 0; </ins> } activate(xterm: Terminal) { this._terminal = xterm; this.capabilities.add(TerminalCapability.PartialCommandDetection, new PartialCommandDetectionCapability(this._terminal)); this._register(xterm.parser.registerOscHandler(ShellIntegrationOscPs.VSCode, data => this._handleVSCodeSequence(data))); <ins> this._commonProtocolDisposables.push( xterm.parser.registerOscHandler(ShellIntegrationOscPs.FinalTerm, data => this._handleFinalTermSequence(data)) ); </ins> this._ensureCapabilitiesOrAddFailureTelemetry(); } <ins> private _handleFinalTermSequence(data: string): boolean { if (!this._terminal) { return false; } // Pass the sequence along to the capability // It was considered to disable the common protocol in order to not confuse the VS Code // shell integration if both happen for some reason. This doesn't work for powerlevel10k // when instant prompt is enabled though. If this does end up being a problem we could pass // a type flag through the capability calls const [command, ...args] = data.split(';'); switch (command) { case 'A': this._createOrGetCommandDetection(this._terminal).handlePromptStart(); return true; case 'B': // Ignore the command line for these sequences as it's unreliable for example in powerlevel10k this._createOrGetCommandDetection(this._terminal).handleCommandStart({ ignoreCommandLine: true }); return true; case 'C': this._createOrGetCommandDetection(this._terminal).handleCommandExecuted(); return true; case 'D': { const exitCode = args.length === 1 ? parseInt(args[0]) : undefined; this._createOrGetCommandDetection(this._terminal).handleCommandFinished(exitCode); return true; } } return false; } </ins> private _handleVSCodeSequence(data: string): boolean { const didHandle = this._doHandleVSCodeSequence(data); if (!this._hasUpdatedTelemetry && didHandle) {


Question:
When I press Ctrl+Shift+P to open the command panel and type "", it shows "No matching commands". So I can't execute this command by Ctrl+Shift+P. I can only bind a shortcut key to this command and then execute it via the shortcut key. I think this is a bug that the command panel search is incomplete.
Please edit this issue title to become:
indicates it may already be there and you just need to know what the command text is.
OK, but according to my observation, there are other commands that cannot be found in the panel. For example, "".
The issue I raised is different from him. His issue is that the shortcut key does not work after binding. My issue is that I can't find the command in the command panel. In fact, some other commands cannot be found, indicating that the search of the command panel is incomplete.
Some commands never appear in the Command Palette because they define their clause as
I open the page where I set the keyboard shortcut and see that their when clause is - not false.
Sorry, I wasn't clear. This is what I am referring to.
I read your link and I probably understand. Please set the when clause of "" to "inDebugMode" instead of false. This is more in line with our needs.
Looks like that command is missing from here: is also missing.
/confirm
I will submit a PR
Thanks!

import { LifecyclePhase } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { launchSchemaId } from 'vs/workbench/services/configuration/common/configuration'; import { LoadedScriptsView } from 'vs/workbench/contrib/debug/browser/loadedScriptsView'; <del> import { RunToCursorAction } from 'vs/workbench/contrib/debug/browser/debugEditorActions'; </del> <ins> import { RunToCursorAction, SelectionToReplAction, SelectionToWatchExpressionsAction } from 'vs/workbench/contrib/debug/browser/debugEditorActions'; </ins> import { WatchExpressionsView, ADD_WATCH_LABEL, REMOVE_WATCH_EXPRESSIONS_COMMAND_ID, REMOVE_WATCH_EXPRESSIONS_LABEL, ADD_WATCH_ID } from 'vs/workbench/contrib/debug/browser/watchExpressionsView'; import { VariablesView, SET_VARIABLE_ID, COPY_VALUE_ID, BREAK_WHEN_VALUE_CHANGES_ID, COPY_EVALUATE_PATH_ID, ADD_TO_WATCH_ID, BREAK_WHEN_VALUE_IS_ACCESSED_ID, BREAK_WHEN_VALUE_IS_READ_ID, VIEW_MEMORY_ID } from 'vs/workbench/contrib/debug/browser/variablesView'; import { Repl } from 'vs/workbench/contrib/debug/browser/repl';


Question:
When I press Ctrl+Shift+P to open the command panel and type "", it shows "No matching commands". So I can't execute this command by Ctrl+Shift+P. I can only bind a shortcut key to this command and then execute it via the shortcut key. I think this is a bug that the command panel search is incomplete.
Please edit this issue title to become:
indicates it may already be there and you just need to know what the command text is.
OK, but according to my observation, there are other commands that cannot be found in the panel. For example, "".
The issue I raised is different from him. His issue is that the shortcut key does not work after binding. My issue is that I can't find the command in the command panel. In fact, some other commands cannot be found, indicating that the search of the command panel is incomplete.
Some commands never appear in the Command Palette because they define their clause as
I open the page where I set the keyboard shortcut and see that their when clause is - not false.
Sorry, I wasn't clear. This is what I am referring to.
I read your link and I probably understand. Please set the when clause of "" to "inDebugMode" instead of false. This is more in line with our needs.
Looks like that command is missing from here: is also missing.
/confirm
I will submit a PR
Thanks!

import { DisassemblyViewInput } from 'vs/workbench/contrib/debug/common/disassemblyViewInput'; import { DebugLifecycle } from 'vs/workbench/contrib/debug/common/debugLifecycle'; import { Icon } from 'vs/platform/action/common/action'; <ins> import { EditorContextKeys } from 'vs/editor/common/editorContextKeys'; </ins> const debugCategory = nls.localize('debugCategory', "Debug"); registerColors();


Question:
When I press Ctrl+Shift+P to open the command panel and type "", it shows "No matching commands". So I can't execute this command by Ctrl+Shift+P. I can only bind a shortcut key to this command and then execute it via the shortcut key. I think this is a bug that the command panel search is incomplete.
Please edit this issue title to become:
indicates it may already be there and you just need to know what the command text is.
OK, but according to my observation, there are other commands that cannot be found in the panel. For example, "".
The issue I raised is different from him. His issue is that the shortcut key does not work after binding. My issue is that I can't find the command in the command panel. In fact, some other commands cannot be found, indicating that the search of the command panel is incomplete.
Some commands never appear in the Command Palette because they define their clause as
I open the page where I set the keyboard shortcut and see that their when clause is - not false.
Sorry, I wasn't clear. This is what I am referring to.
I read your link and I probably understand. Please set the when clause of "" to "inDebugMode" instead of false. This is more in line with our needs.
Looks like that command is missing from here: is also missing.
/confirm
I will submit a PR
Thanks!

registerDebugCommandPaletteItem(JUMP_TO_CURSOR_ID, nls.localize('jumpToCursor', "Jump to Cursor"), CONTEXT_JUMP_TO_CURSOR_SUPPORTED); registerDebugCommandPaletteItem(JUMP_TO_CURSOR_ID, nls.localize('SetNextStatement', "Set Next Statement"), CONTEXT_JUMP_TO_CURSOR_SUPPORTED); registerDebugCommandPaletteItem(RunToCursorAction.ID, RunToCursorAction.LABEL, ContextKeyExpr.and(CONTEXT_IN_DEBUG_MODE, CONTEXT_DEBUG_STATE.isEqualTo('stopped'))); <ins> registerDebugCommandPaletteItem(SelectionToReplAction.ID, SelectionToReplAction.LABEL, ContextKeyExpr.and(EditorContextKeys.hasNonEmptySelection, CONTEXT_IN_DEBUG_MODE)); registerDebugCommandPaletteItem(SelectionToWatchExpressionsAction.ID, SelectionToWatchExpressionsAction.LABEL, ContextKeyExpr.and(EditorContextKeys.hasNonEmptySelection, CONTEXT_IN_DEBUG_MODE)); </ins> registerDebugCommandPaletteItem(TOGGLE_INLINE_BREAKPOINT_ID, nls.localize('inlineBreakpoint', "Inline Breakpoint")); registerDebugCommandPaletteItem(DEBUG_START_COMMAND_ID, DEBUG_START_LABEL, ContextKeyExpr.and(CONTEXT_DEBUGGERS_AVAILABLE, CONTEXT_DEBUG_STATE.notEqualsTo(getStateLabel(State.Initializing)))); registerDebugCommandPaletteItem(DEBUG_RUN_COMMAND_ID, DEBUG_RUN_LABEL, ContextKeyExpr.and(CONTEXT_DEBUGGERS_AVAILABLE, CONTEXT_DEBUG_STATE.notEqualsTo(getStateLabel(State.Initializing))));


Question:
When I press Ctrl+Shift+P to open the command panel and type "", it shows "No matching commands". So I can't execute this command by Ctrl+Shift+P. I can only bind a shortcut key to this command and then execute it via the shortcut key. I think this is a bug that the command panel search is incomplete.
Please edit this issue title to become:
indicates it may already be there and you just need to know what the command text is.
OK, but according to my observation, there are other commands that cannot be found in the panel. For example, "".
The issue I raised is different from him. His issue is that the shortcut key does not work after binding. My issue is that I can't find the command in the command panel. In fact, some other commands cannot be found, indicating that the search of the command panel is incomplete.
Some commands never appear in the Command Palette because they define their clause as
I open the page where I set the keyboard shortcut and see that their when clause is - not false.
Sorry, I wasn't clear. This is what I am referring to.
I read your link and I probably understand. Please set the when clause of "" to "inDebugMode" instead of false. This is more in line with our needs.
Looks like that command is missing from here: is also missing.
/confirm
I will submit a PR
Thanks!

} } <del> class SelectionToReplAction extends EditorAction { </del> <ins> export class SelectionToReplAction extends EditorAction { public static readonly ID = 'editor.debug.action.selectionToRepl'; public static readonly LABEL = nls.localize('evaluateInDebugConsole', "Evaluate in Debug Console"); </ins> constructor() { super({ <del> id: 'editor.debug.action.selectionToRepl', label: nls.localize('evaluateInDebugConsole', "Evaluate in Debug Console"), alias: 'Evaluate', </del> <ins> id: SelectionToReplAction.ID, label: SelectionToReplAction.LABEL, alias: 'Debug: Evaluate in Console', </ins> precondition: ContextKeyExpr.and(EditorContextKeys.hasNonEmptySelection, CONTEXT_IN_DEBUG_MODE, EditorContextKeys.editorTextFocus), contextMenuOpts: { group: 'debug',


Question:
When I press Ctrl+Shift+P to open the command panel and type "", it shows "No matching commands". So I can't execute this command by Ctrl+Shift+P. I can only bind a shortcut key to this command and then execute it via the shortcut key. I think this is a bug that the command panel search is incomplete.
Please edit this issue title to become:
indicates it may already be there and you just need to know what the command text is.
OK, but according to my observation, there are other commands that cannot be found in the panel. For example, "".
The issue I raised is different from him. His issue is that the shortcut key does not work after binding. My issue is that I can't find the command in the command panel. In fact, some other commands cannot be found, indicating that the search of the command panel is incomplete.
Some commands never appear in the Command Palette because they define their clause as
I open the page where I set the keyboard shortcut and see that their when clause is - not false.
Sorry, I wasn't clear. This is what I am referring to.
I read your link and I probably understand. Please set the when clause of "" to "inDebugMode" instead of false. This is more in line with our needs.
Looks like that command is missing from here: is also missing.
/confirm
I will submit a PR
Thanks!

} } <del> class SelectionToWatchExpressionsAction extends EditorAction { </del> <ins> export class SelectionToWatchExpressionsAction extends EditorAction { public static readonly ID = 'editor.debug.action.selectionToWatch'; public static readonly LABEL = nls.localize('addToWatch', "Add to Watch"); </ins> constructor() { super({ <del> id: 'editor.debug.action.selectionToWatch', label: nls.localize('addToWatch', "Add to Watch"), alias: 'Add to Watch', </del> <ins> id: SelectionToWatchExpressionsAction.ID, label: SelectionToWatchExpressionsAction.LABEL, alias: 'Debug: Add to Watch', </ins> precondition: ContextKeyExpr.and(EditorContextKeys.hasNonEmptySelection, CONTEXT_IN_DEBUG_MODE, EditorContextKeys.editorTextFocus), contextMenuOpts: { group: 'debug',


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: 1.66 OS Version: Windows 11 Steps to Reproduce: diff view to revert the output changes :bug: after reverting the diff view still says there are deletions/additions output changes using the diff view :bug: stage the file and reopen the diff view, all the changes I reverted are back

} else { this._outputEmptyElement!.style.display = 'none'; } <ins> this._decorate(); </ins> })); this._outputLeftContainer = DOM.append(this._outputViewContainer!, DOM.$('.output-view-container-left'));


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: 1.66 OS Version: Windows 11 Steps to Reproduce: diff view to revert the output changes :bug: after reverting the diff view still says there are deletions/additions output changes using the diff view :bug: stage the file and reopen the diff view, all the changes I reverted are back

if (outputModified && !outputMetadataChangeOnly) { const originalOutputRenderListener = this.notebookEditor.onDidDynamicOutputRendered(e => { <del> if (e.cell.uri.toString() === this.cell.original.uri.toString()) { </del> <ins> if (e.cell.uri.toString() === this.cell.original.uri.toString() && this.cell.checkIfOutputsModified()) { </ins> this.notebookEditor.deltaCellOutputContainerClassNames(DiffSide.Original, this.cell.original.id, ['nb-cellDeleted'], []); originalOutputRenderListener.dispose(); } }); const modifiedOutputRenderListener = this.notebookEditor.onDidDynamicOutputRendered(e => { <del> if (e.cell.uri.toString() === this.cell.modified.uri.toString()) { </del> <ins> if (e.cell.uri.toString() === this.cell.modified.uri.toString() && this.cell.checkIfOutputsModified()) { </ins> this.notebookEditor.deltaCellOutputContainerClassNames(DiffSide.Modified, this.cell.modified.id, ['nb-cellAdded'], []); modifiedOutputRenderListener.dispose(); }


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: 1.66 OS Version: Windows 11 Steps to Reproduce: diff view to revert the output changes :bug: after reverting the diff view still says there are deletions/additions output changes using the diff view :bug: stage the file and reopen the diff view, all the changes I reverted are back

if (this.cell.checkIfOutputsModified()) { this.notebookEditor.deltaCellOutputContainerClassNames(DiffSide.Original, this.cell.original.id, ['nb-cellDeleted'], []); this.notebookEditor.deltaCellOutputContainerClassNames(DiffSide.Modified, this.cell.modified.id, ['nb-cellAdded'], []); <ins> } else { this.notebookEditor.deltaCellOutputContainerClassNames(DiffSide.Original, this.cell.original.id, [], ['nb-cellDeleted']); this.notebookEditor.deltaCellOutputContainerClassNames(DiffSide.Modified, this.cell.modified.id, [], ['nb-cellAdded']); </ins> } }


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: 1.66 OS Version: Windows 11 Steps to Reproduce: diff view to revert the output changes :bug: after reverting the diff view still says there are deletions/additions output changes using the diff view :bug: stage the file and reopen the diff view, all the changes I reverted are back

import { ContextKeyExpr, ContextKeyExpression } from 'vs/platform/contextkey/common/contextkey'; import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; import { ActiveEditorContext } from 'vs/workbench/common/contextkeys'; <del> import { DiffElementViewModelBase } from 'vs/workbench/contrib/notebook/browser/diff/diffElementViewModel'; </del> <ins> import { DiffElementViewModelBase, SideBySideDiffElementViewModel } from 'vs/workbench/contrib/notebook/browser/diff/diffElementViewModel'; </ins> import { INotebookTextDiffEditor, NOTEBOOK_DIFF_CELL_INPUT, NOTEBOOK_DIFF_CELL_PROPERTY, NOTEBOOK_DIFF_CELL_PROPERTY_EXPANDED } from 'vs/workbench/contrib/notebook/browser/diff/notebookDiffEditorBrowser'; import { NotebookTextDiffEditor } from 'vs/workbench/contrib/notebook/browser/diff/notebookDiffEditor'; import { NotebookDiffEditorInput } from 'vs/workbench/contrib/notebook/common/notebookDiffEditorInput';


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: 1.66 OS Version: Windows 11 Steps to Reproduce: diff view to revert the output changes :bug: after reverting the diff view still says there are deletions/additions output changes using the diff view :bug: stage the file and reopen the diff view, all the changes I reverted are back

import { DEFAULT_EDITOR_ASSOCIATION } from 'vs/workbench/common/editor'; import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; <del> import { NOTEBOOK_DIFF_EDITOR_ID } from 'vs/workbench/contrib/notebook/common/notebookCommon'; </del> <ins> import { CellEditType, NOTEBOOK_DIFF_EDITOR_ID } from 'vs/workbench/contrib/notebook/common/notebookCommon'; </ins> // ActiveEditorContext.isEqualTo(SearchEditorConstants.SearchEditorID)


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: 1.66 OS Version: Windows 11 Steps to Reproduce: diff view to revert the output changes :bug: after reverting the diff view still says there are deletions/additions output changes using the diff view :bug: stage the file and reopen the diff view, all the changes I reverted are back

return; } <ins> if (!(context.cell instanceof SideBySideDiffElementViewModel)) { return; } </ins> const original = context.cell.original; const modified = context.cell.modified; <del> if (!original || !modified) { </del> <ins> const modifiedCellIndex = context.cell.mainDocumentTextModel.cells.indexOf(modified.textModel); if (modifiedCellIndex === -1) { </ins> return; } <del> modified.textModel.spliceNotebookCellOutputs({ start: 0, deleteCount: modified.outputs.length, newOutputs: original.outputs }); </del> <ins> context.cell.mainDocumentTextModel.applyEdits([{ editType: CellEditType.Output, index: modifiedCellIndex, outputs: original.outputs }], true, undefined, () => undefined, undefined, true); </ins> } });


Question: Ref: I would expect the comment editor to behave just like a regular editor window, but in my case it is not. I don't hear screen reader feedback as I move through words and lines with the keyboard. Also, when I press a routing cursor key on my braille display, it does not move the cursor to the desired character. Tested with NVDA and JAWS. Invoke the action to leave a comment in the current line Write some text Use ctrl+left and ctrl+right to move through words Use up and down arrow keys to move through lines If you have a braille display with routing keys, press a routing cursor key to move to a specific character in the text

@IContextKeyService contextKeyService: IContextKeyService, @IConfigurationService private readonly configurationService: IConfigurationService ) { <del> super(editor, { keepEditorSelection: true }); </del> <ins> super(editor, { keepEditorSelection: true, isAccessible: true }); </ins> this._contextKeyService = contextKeyService.createScoped(this.domNode); this._scopedInstantiationService = instantiationService.createChild(new ServiceCollection(


Question: Ref: I would expect the comment editor to behave just like a regular editor window, but in my case it is not. I don't hear screen reader feedback as I move through words and lines with the keyboard. Also, when I press a routing cursor key on my braille display, it does not move the cursor to the desired character. Tested with NVDA and JAWS. Invoke the action to leave a comment in the current line Write some text Use ctrl+left and ctrl+right to move through words Use up and down arrow keys to move through lines If you have a braille display with routing keys, press a routing cursor key to move to a specific character in the text

enabled: false }, autoClosingBrackets: configurationService.getValue('editor.autoClosingBrackets'), <del> quickSuggestions: false </del> <ins> quickSuggestions: false, accessibilitySupport: configurationService.getValue<'auto' | 'off' | 'on'>('editor.accessibilitySupport'), </ins> }; } }