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

<ins> # --------------------------------------------------------------------------------------------- #   Copyright (c) Microsoft Corporation. All rights reserved. #   Licensed under the MIT License. See License.txt in the project root for license information. # --------------------------------------------------------------------------------------------- # # Visual Studio Code terminal integration for fish # # Manual installation: # #   (1) Add the following to the end of `$__fish_config_dir/config.fish`: # #         string match -q "$TERM_PROGRAM" "vscode" #         and . (code --locate-shell-integration-path fish) # #   (2) Restart fish. # Don't run in scripts, other terminals, or more than once per session. status is-interactive and string match --quiet "$TERM_PROGRAM" "vscode" and ! set --query VSCODE_SHELL_INTEGRATION or exit set --global VSCODE_SHELL_INTEGRATION 1 # Apply any explicit path prefix (see #99878) if status --is-login; and set -q VSCODE_PATH_PREFIX fish_add_path -p $VSCODE_PATH_PREFIX end set -e VSCODE_PATH_PREFIX # Apply EnvironmentVariableCollections if needed if test -n "$VSCODE_ENV_REPLACE" set ITEMS (string split : $VSCODE_ENV_REPLACE) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" (echo -e "$split[2]") end set -e VSCODE_ENV_REPLACE end if test -n "$VSCODE_ENV_PREPEND" set ITEMS (string split : $VSCODE_ENV_PREPEND) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" (echo -e "$split[2]")"$$split[1]" # avoid -p as it adds a space end set -e VSCODE_ENV_PREPEND end if test -n "$VSCODE_ENV_APPEND" set ITEMS (string split : $VSCODE_ENV_APPEND) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" "$$split[1]"(echo -e "$split[2]") # avoid -a as it adds a space end set -e VSCODE_ENV_APPEND end # Handle the shell integration nonce if set -q VSCODE_NONCE set -l __vsc_nonce $VSCODE_NONCE set -e VSCODE_NONCE end # Helper function function __vsc_esc -d "Emit escape sequences for VS Code shell integration" builtin printf "e]633;%sa" (string join ";" $argv) end # Sent right before executing an interactive command. # Marks the beginning of command output. function __vsc_cmd_executed --on-event fish_preexec __vsc_esc C __vsc_esc E (__vsc_escape_value "$argv") $__vsc_nonce # Creates a marker to indicate a command was run. set --global _vsc_has_cmd end # Escape a value for use in the 'P' ("Property") or 'E' ("Command Line") sequences. # Backslashes are doubled and non-alphanumeric characters are hex encoded. function __vsc_escape_value # Escape backslashes and semi-colons echo $argv  | string replace --all '' ''  | string replace --all ';' 'x3b'  ; end # Sent right after an interactive command has finished executing. # Marks the end of command output. function __vsc_cmd_finished --on-event fish_postexec __vsc_esc D $status end # Sent when a command line is cleared or reset, but no command was run. # Marks the cleared line with neither success nor failure. function __vsc_cmd_clear --on-event fish_cancel __vsc_esc D end # Sent whenever a new fish prompt is about to be displayed. # Updates the current working directory. function __vsc_update_cwd --on-event fish_prompt __vsc_esc P Cwd=(__vsc_escape_value "$PWD") # If a command marker exists, remove it. # Otherwise, the commandline is empty and no command was run. if set --query _vsc_has_cmd set --erase _vsc_has_cmd else __vsc_cmd_clear end end # Sent at the start of the prompt. # Marks the beginning of the prompt (and, implicitly, a new line). function __vsc_fish_prompt_start __vsc_esc A end # Sent at the end of the prompt. # Marks the beginning of the user's command input. function __vsc_fish_cmd_start __vsc_esc B end function __vsc_fish_has_mode_prompt -d "Returns true if fish_mode_prompt is defined and not empty" functions fish_mode_prompt | string match -rvq '^ *(#|function |end$|$)' end # Preserve the user's existing prompt, to wrap in our escape sequences. functions --copy fish_prompt __vsc_fish_prompt # Preserve and wrap fish_mode_prompt (which appears to the left of the regular # prompt), but only if it's not defined as an empty function (which is the # officially documented way to disable that feature). if __vsc_fish_has_mode_prompt functions --copy fish_mode_prompt __vsc_fish_mode_prompt function fish_mode_prompt __vsc_fish_prompt_start __vsc_fish_mode_prompt end function fish_prompt __vsc_fish_prompt __vsc_fish_cmd_start end else # No fish_mode_prompt, so put everything in fish_prompt. function fish_prompt __vsc_fish_prompt_start __vsc_fish_prompt __vsc_fish_cmd_start end end </ins>


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

<del> # --------------------------------------------------------------------------------------------- #   Copyright (c) Microsoft Corporation. All rights reserved. #   Licensed under the MIT License. See License.txt in the project root for license information. # --------------------------------------------------------------------------------------------- # # Visual Studio Code terminal integration for fish # # Manual installation: # #   (1) Add the following to the end of `$__fish_config_dir/config.fish`: # #         string match -q "$TERM_PROGRAM" "vscode" #         and . (code --locate-shell-integration-path fish) # #   (2) Restart fish. # Don't run in scripts, other terminals, or more than once per session. status is-interactive and string match --quiet "$TERM_PROGRAM" "vscode" and ! set --query VSCODE_SHELL_INTEGRATION or exit set --global VSCODE_SHELL_INTEGRATION 1 # Apply any explicit path prefix (see #99878) if status --is-login; and set -q VSCODE_PATH_PREFIX fish_add_path -p $VSCODE_PATH_PREFIX end set -e VSCODE_PATH_PREFIX # Apply EnvironmentVariableCollections if needed if test -n "$VSCODE_ENV_REPLACE" set ITEMS (string split : $VSCODE_ENV_REPLACE) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" (echo -e "$split[2]") end set -e VSCODE_ENV_REPLACE end if test -n "$VSCODE_ENV_PREPEND" set ITEMS (string split : $VSCODE_ENV_PREPEND) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" (echo -e "$split[2]")"$$split[1]" # avoid -p as it adds a space end set -e VSCODE_ENV_PREPEND end if test -n "$VSCODE_ENV_APPEND" set ITEMS (string split : $VSCODE_ENV_APPEND) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" "$$split[1]"(echo -e "$split[2]") # avoid -a as it adds a space end set -e VSCODE_ENV_APPEND end # Handle the shell integration nonce if set -q VSCODE_NONCE set -l __vsc_nonce $VSCODE_NONCE set -e VSCODE_NONCE end # Helper function function __vsc_esc -d "Emit escape sequences for VS Code shell integration" builtin printf "e]633;%sa" (string join ";" $argv) end # Sent right before executing an interactive command. # Marks the beginning of command output. function __vsc_cmd_executed --on-event fish_preexec __vsc_esc C __vsc_esc E (__vsc_escape_value "$argv") $__vsc_nonce # Creates a marker to indicate a command was run. set --global _vsc_has_cmd end # Escape a value for use in the 'P' ("Property") or 'E' ("Command Line") sequences. # Backslashes are doubled and non-alphanumeric characters are hex encoded. function __vsc_escape_value # Escape backslashes and semi-colons echo $argv  | string replace --all '' ''  | string replace --all ';' 'x3b'  ; end # Sent right after an interactive command has finished executing. # Marks the end of command output. function __vsc_cmd_finished --on-event fish_postexec __vsc_esc D $status end # Sent when a command line is cleared or reset, but no command was run. # Marks the cleared line with neither success nor failure. function __vsc_cmd_clear --on-event fish_cancel __vsc_esc D end # Sent whenever a new fish prompt is about to be displayed. # Updates the current working directory. function __vsc_update_cwd --on-event fish_prompt __vsc_esc P Cwd=(__vsc_escape_value "$PWD") # If a command marker exists, remove it. # Otherwise, the commandline is empty and no command was run. if set --query _vsc_has_cmd set --erase _vsc_has_cmd else __vsc_cmd_clear end end # Sent at the start of the prompt. # Marks the beginning of the prompt (and, implicitly, a new line). function __vsc_fish_prompt_start __vsc_esc A end # Sent at the end of the prompt. # Marks the beginning of the user's command input. function __vsc_fish_cmd_start __vsc_esc B end function __vsc_fish_has_mode_prompt -d "Returns true if fish_mode_prompt is defined and not empty" functions fish_mode_prompt | string match -rvq '^ *(#|function |end$|$)' end # Preserve the user's existing prompt, to wrap in our escape sequences. functions --copy fish_prompt __vsc_fish_prompt # Preserve and wrap fish_mode_prompt (which appears to the left of the regular # prompt), but only if it's not defined as an empty function (which is the # officially documented way to disable that feature). if __vsc_fish_has_mode_prompt functions --copy fish_mode_prompt __vsc_fish_mode_prompt function fish_mode_prompt __vsc_fish_prompt_start __vsc_fish_mode_prompt end function fish_prompt __vsc_fish_prompt __vsc_fish_cmd_start end else # No fish_mode_prompt, so put everything in fish_prompt. function fish_prompt __vsc_fish_prompt_start __vsc_fish_prompt __vsc_fish_cmd_start end end </del>


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

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


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

__vsc_esc D end <ins> # Preserve the user's existing prompt, to wrap in our escape sequences. function __preserve_fish_prompt --on-event fish_prompt if functions --query fish_prompt if functions --query __vsc_fish_prompt # Erase the fallback so it can be set to the user's prompt functions --erase __vsc_fish_prompt end functions --copy fish_prompt __vsc_fish_prompt functions --erase __preserve_fish_prompt # Now __vsc_fish_prompt is guaranteed to be defined __init_vscode_shell_integration else if functions --query __vsc_fish_prompt # There is no fish_prompt set, so stick with the default functions --erase __preserve_fish_prompt # Now __vsc_fish_prompt is guaranteed to be defined __init_vscode_shell_integration else function __vsc_fish_prompt echo -n (whoami)@(prompt_hostname) (prompt_pwd) '~> ' end end end end __preserve_fish_prompt </ins> # Sent whenever a new fish prompt is about to be displayed. # Updates the current working directory. function __vsc_update_cwd --on-event fish_prompt


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

functions fish_mode_prompt | string match -rvq '^ *(#|function |end$|$)' end <del> # Preserve the user's existing prompt, to wrap in our escape sequences. functions --copy fish_prompt __vsc_fish_prompt </del> # Preserve and wrap fish_mode_prompt (which appears to the left of the regular # prompt), but only if it's not defined as an empty function (which is the # officially documented way to disable that feature). <del> if __vsc_fish_has_mode_prompt functions --copy fish_mode_prompt __vsc_fish_mode_prompt function fish_mode_prompt __vsc_fish_prompt_start __vsc_fish_mode_prompt end function fish_prompt __vsc_fish_prompt __vsc_fish_cmd_start end else # No fish_mode_prompt, so put everything in fish_prompt. function fish_prompt __vsc_fish_prompt_start __vsc_fish_prompt __vsc_fish_cmd_start </del> <ins> function __init_vscode_shell_integration if __vsc_fish_has_mode_prompt functions --copy fish_mode_prompt __vsc_fish_mode_prompt function fish_mode_prompt __vsc_fish_prompt_start __vsc_fish_mode_prompt end function fish_prompt __vsc_fish_prompt __vsc_fish_cmd_start end else # No fish_mode_prompt, so put everything in fish_prompt. function fish_prompt __vsc_fish_prompt_start __vsc_fish_prompt __vsc_fish_cmd_start end </ins> end end


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Hi! I want to solve this issue as a good-first-issue. Please help me if you can :) In Github there was a problem that README and issues don't work for RTL languages. () Then on November 16, 2021, Github announced that we fixed this problem: () But vscode does not support it yet. For example we see ) in github like this: ! But in vscode, we see the markdown preview like this: ! Feature or improvement request: Providing support for correctly previewing RTL languages texts.
Hi! Can you help me to solve this issue? (as a good-first-issue) I opened a pull request here:
/verified

resourceProvider: WebviewResourceProvider, ): Promise<MarkdownContentProviderOutput> { const rendered = await this.engine.render(markdownDocument, resourceProvider); <del> const html = `<div class="markdown-body">${rendered.html}<div class="code-line" data-line="${markdownDocument.lineCount}"></div></div>`; </del> <ins> const html = `<div class="markdown-body" dir="auto">${rendered.html}<div class="code-line" data-line="${markdownDocument.lineCount}"></div></div>`; </ins> return { html, containingImages: rendered.containingImages


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Hi! I want to solve this issue as a good-first-issue. Please help me if you can :) In Github there was a problem that README and issues don't work for RTL languages. () Then on November 16, 2021, Github announced that we fixed this problem: () But vscode does not support it yet. For example we see ) in github like this: ! But in vscode, we see the markdown preview like this: ! Feature or improvement request: Providing support for correctly previewing RTL languages texts.
Hi! Can you help me to solve this issue? (as a good-first-issue) I opened a pull request here:
/verified

if (token.map && token.type !== 'inline') { token.attrSet('data-line', String(token.map[0])); token.attrJoin('class', 'code-line'); <ins> token.attrJoin('dir', 'auto'); </ins> } } });


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Hi! I want to solve this issue as a good-first-issue. Please help me if you can :) In Github there was a problem that README and issues don't work for RTL languages. () Then on November 16, 2021, Github announced that we fixed this problem: () But vscode does not support it yet. For example we see ) in github like this: ! But in vscode, we see the markdown preview like this: ! Feature or improvement request: Providing support for correctly previewing RTL languages texts.
Hi! Can you help me to solve this issue? (as a good-first-issue) I opened a pull request here:
/verified

return engine.parse(text.replace(UNICODE_NEWLINE_REGEX, ''), {}); } public resetSlugCount(): void { this._slugCount = new Map<string, number>(); }


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/No <!-- 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: stable and from sources Steps to Reproduce: server vscode in safari simple browser :bug: Observe icons don't load (icons load if disable Cross Origin Restrictions in develop menu is checked)
How are you running the server? I see the icons loading in but not on localhost using : ! This seems expected since Safari seems more strict about loading content from localhost in this case
Try codespaces, it repros there too. (For running the server I use ) It works on serverless (i.e. and ) because they are served in a different way I think
I'd also like to see it fixed. It's still reproducible on latest Safari version. <img width="290" alt="image" src="https://user-"
This definitely seems like a webkit bug but I can't put together a minimal repo. The issue is the the codicon font face doesn't go through the service worker during loading despite it's parent css file being loaded by it: ! I also tried debugging the production code in codespaces but Safari's dev tools are pretty much unusable with our minified service worker Instead, I'm going to push a change that inlines the font in the css file to hopefully work around this issue
Looks to be working in latest insiders !
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

*--------------------------------------------------------------------------------------------*/ // @ts-check const path = require('path'); <del> const fs = require('fs'); </del> const esbuild = require('esbuild'); const args = process.argv.slice(2);


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/No <!-- 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: stable and from sources Steps to Reproduce: server vscode in safari simple browser :bug: Observe icons don't load (icons load if disable Cross Origin Restrictions in develop menu is checked)
How are you running the server? I see the icons loading in but not on localhost using : ! This seems expected since Safari seems more strict about loading content from localhost in this case
Try codespaces, it repros there too. (For running the server I use ) It works on serverless (i.e. and ) because they are served in a different way I think
I'd also like to see it fixed. It's still reproducible on latest Safari version. <img width="290" alt="image" src="https://user-"
This definitely seems like a webkit bug but I can't put together a minimal repo. The issue is the the codicon font face doesn't go through the service worker during loading despite it's parent css file being loaded by it: ! I also tried debugging the production code in codespaces but Safari's dev tools are pretty much unusable with our minified service worker Instead, I'm going to push a change that inlines the font in the css file to hopefully work around this issue
Looks to be working in latest insiders !
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

const outDir = path.join(outputRoot, 'media'); async function build() { <del> fs.copyFileSync( path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.css'), path.join(outDir, 'codicon.css')); fs.copyFileSync( path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.ttf'), path.join(outDir, 'codicon.ttf')); </del> await esbuild.build({ <del> entryPoints: [ path.join(srcDir, 'index.ts') ], </del> <ins> entryPoints: { 'index': path.join(srcDir, 'index.ts'), 'codicon': path.join(__dirname, 'node_modules', 'vscode-codicons', 'dist', 'codicon.css'), }, loader: { '.ttf': 'dataurl', }, </ins> bundle: true, minify: true, sourcemap: false,


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/No <!-- 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: stable and from sources Steps to Reproduce: server vscode in safari simple browser :bug: Observe icons don't load (icons load if disable Cross Origin Restrictions in develop menu is checked)
How are you running the server? I see the icons loading in but not on localhost using : ! This seems expected since Safari seems more strict about loading content from localhost in this case
Try codespaces, it repros there too. (For running the server I use ) It works on serverless (i.e. and ) because they are served in a different way I think
I'd also like to see it fixed. It's still reproducible on latest Safari version. <img width="290" alt="image" src="https://user-"
This definitely seems like a webkit bug but I can't put together a minimal repo. The issue is the the codicon font face doesn't go through the service worker during loading despite it's parent css file being loaded by it: ! I also tried debugging the production code in codespaces but Safari's dev tools are pretty much unusable with our minified service worker Instead, I'm going to push a change that inlines the font in the css file to hopefully work around this issue
Looks to be working in latest insiders !
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

<meta http-equiv="Content-Security-Policy" content=" default-src 'none'; <del> font-src ${this._webviewPanel.webview.cspSource}; </del> <ins> font-src data:; </ins> style-src ${this._webviewPanel.webview.cspSource}; script-src 'nonce-${nonce}'; frame-src *;


Question: Issue Type: <bBug</bthe Extensions tab enough text in the search box to cause scrolling back to the beginning of the search box Actual: The typed text overflows the right edge of the search box Expected: the typed text doesn't overflow the edge of the search box <img width="210" alt="Screenshot 2022-01-09 at 18 00 24" src="https://user-"VS Code version: Code 1.63.2 (, 2021-12-15T09:38:17.605Z) OS version: Darwin arm64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --

disposables.push(server.onServerStart(path => { <del> defaultStatus.text = '$(flame) Runnning'; </del> <ins> defaultStatus.text = '$(flame) Running'; </ins> defaultStatus.command = 'o.pickProjectAndStart'; defaultStatus.color = ''; render();


Question:
The 'Last updated' and 'released on' dates on the extension page use the American format. This is confusing to many people. ! I tried to Spanish and German, but the problem remains: ! ! Consider using a unambiguous date format such as yyyy-mm-dd (ISO 8601)
I am not locating the datetime as a resource for localization, I'm assuming it is concatenated in runtime so not a loc issue. Please help if I'm mistaken.
I think using the unambiguous date format is a good way forward. However, we could do something where en-US is displayed one way everything else is displayed the other way... but I don't think that is 100% accurate.
is this issue closed? or still needs help?
Its still open and there is a PR which has to be reviewed.
Hello, is this issue still open? I am new to contributing to GitHub projects and this seems like a good first issue for me. Is there a way to claim this issue? If I am able to work on this, do you have any advice for me in contributing for the first time?
Thanks for your interest. This is already being worked on. Please look for another good first and help wanted issues. Thanks/

const newRenderMode = e.altKey && e.ctrlKey ? altMode : defaultMode; if (newRenderMode !== this._activeRenderMode) { this._activeRenderMode = newRenderMode; <del> const ranges = this._getHintsRanges(); const copies = this._copyInlayHintsWithCurrentAnchor(this._editor.getModel()); this._updateHintsDecorators(ranges, copies); </del> <ins> const model = this._editor.getModel(); const copies = this._copyInlayHintsWithCurrentAnchor(model); this._updateHintsDecorators([model.getFullModelRange()], copies); </ins> scheduler.schedule(0); } }));


Question:
The 'Last updated' and 'released on' dates on the extension page use the American format. This is confusing to many people. ! I tried to Spanish and German, but the problem remains: ! ! Consider using a unambiguous date format such as yyyy-mm-dd (ISO 8601)
I am not locating the datetime as a resource for localization, I'm assuming it is concatenated in runtime so not a loc issue. Please help if I'm mistaken.
I think using the unambiguous date format is a good way forward. However, we could do something where en-US is displayed one way everything else is displayed the other way... but I don't think that is 100% accurate.
is this issue closed? or still needs help?
Its still open and there is a PR which has to be reviewed.
Hello, is this issue still open? I am new to contributing to GitHub projects and this seems like a good first issue for me. Is there a way to claim this issue? If I am able to work on this, do you have any advice for me in contributing for the first time?
Thanks for your interest. This is already being worked on. Please look for another good first and help wanted issues. Thanks/

} // return inlay hints but with an anchor that reflects "updates" <del> // that happens after receiving them, e.g adding new lines before a hint </del> <ins> // that happened after receiving them, e.g adding new lines before a hint </ins> private _copyInlayHintsWithCurrentAnchor(model: ITextModel): InlayHintItem[] { const items = new Map<InlayHintItem, InlayHintItem>(); for (const [id, obj] of this._decorationsMetadata) {


Question:
The 'Last updated' and 'released on' dates on the extension page use the American format. This is confusing to many people. ! I tried to Spanish and German, but the problem remains: ! ! Consider using a unambiguous date format such as yyyy-mm-dd (ISO 8601)
I am not locating the datetime as a resource for localization, I'm assuming it is concatenated in runtime so not a loc issue. Please help if I'm mistaken.
I think using the unambiguous date format is a good way forward. However, we could do something where en-US is displayed one way everything else is displayed the other way... but I don't think that is 100% accurate.
is this issue closed? or still needs help?
Its still open and there is a PR which has to be reviewed.
Hello, is this issue still open? I am new to contributing to GitHub projects and this seems like a good first issue for me. Is there a way to claim this issue? If I am able to work on this, do you have any advice for me in contributing for the first time?
Thanks for your interest. This is already being worked on. Please look for another good first and help wanted issues. Thanks/

const container = document.createElement('span'); container.classList.add('all-options'); parent.appendChild(container); <del> const action = new Action('all', localize('all', "Show Quick Pick Options..."), Codicon.chevronDown.classNames, true, () => { </del> <ins> const action = new Action('all', localize('all', "Show Search Modes..."), Codicon.chevronDown.classNames, true, () => { </ins> quickInputService.quickAccess.show('?'); }); const dropdown = new ActionViewItem(undefined, action, { icon: true, label: false, hoverDelegate });


Question:
The 'Last updated' and 'released on' dates on the extension page use the American format. This is confusing to many people. ! I tried to Spanish and German, but the problem remains: ! ! Consider using a unambiguous date format such as yyyy-mm-dd (ISO 8601)
I am not locating the datetime as a resource for localization, I'm assuming it is concatenated in runtime so not a loc issue. Please help if I'm mistaken.
I think using the unambiguous date format is a good way forward. However, we could do something where en-US is displayed one way everything else is displayed the other way... but I don't think that is 100% accurate.
is this issue closed? or still needs help?
Its still open and there is a PR which has to be reviewed.
Hello, is this issue still open? I am new to contributing to GitHub projects and this seems like a good first issue for me. Is there a way to claim this issue? If I am able to work on this, do you have any advice for me in contributing for the first time?
Thanks for your interest. This is already being worked on. Please look for another good first and help wanted issues. Thanks/

import 'vs/css!./media/extensionEditor'; import { localize } from 'vs/nls'; import * as arrays from 'vs/base/common/arrays'; <del> import { OS } from 'vs/base/common/platform'; </del> <ins> import { OS, locale } from 'vs/base/common/platform'; </ins> import { Event, Emitter } from 'vs/base/common/event'; import { Cache, CacheResult } from 'vs/base/common/cache'; import { Action, IAction } from 'vs/base/common/actions';


Question:
The 'Last updated' and 'released on' dates on the extension page use the American format. This is confusing to many people. ! I tried to Spanish and German, but the problem remains: ! ! Consider using a unambiguous date format such as yyyy-mm-dd (ISO 8601)
I am not locating the datetime as a resource for localization, I'm assuming it is concatenated in runtime so not a loc issue. Please help if I'm mistaken.
I think using the unambiguous date format is a good way forward. However, we could do something where en-US is displayed one way everything else is displayed the other way... but I don't think that is 100% accurate.
is this issue closed? or still needs help?
Its still open and there is a PR which has to be reviewed.
Hello, is this issue still open? I am new to contributing to GitHub projects and this seems like a good first issue for me. Is there a way to claim this issue? If I am able to work on this, do you have any advice for me in contributing for the first time?
Thanks for your interest. This is already being worked on. Please look for another good first and help wanted issues. Thanks/

append(moreInfo, $('.more-info-entry', undefined, $('div', undefined, localize('release date', "Released on")), <del> $('div', undefined, new Date(gallery.releaseDate).toLocaleString(undefined, { hourCycle: 'h23' })) </del> <ins> $('div', undefined, new Date(gallery.releaseDate).toLocaleString(locale, { hourCycle: 'h23' })) </ins> ), $('.more-info-entry', undefined, $('div', undefined, localize('last updated', "Last updated")), <del> $('div', undefined, new Date(gallery.lastUpdated).toLocaleString(undefined, { hourCycle: 'h23' })) </del> <ins> $('div', undefined, new Date(gallery.lastUpdated).toLocaleString(locale, { hourCycle: 'h23' })) </ins> ) ); }


Question:
<img width="600" src="https://user-"<img width="600" src="https://user-"<img width="600" src="https://user-"<img width="600" src="https://user-"IMO the labels should be consistent and we should use the icon + label as much as possible: !
I like your idea of showing the icon + label. But would like to show it next to the version as they are coupled. Also showing an addition line for a pre-release extension in the hover seems redundant to me. So, I just icon to the existing label and this is how it looks: ! !


Question:
Testing On macOS Ensure the setting is not modified (default to ) Create two folders and , create file in Drag it to Undo There isn't any prompt of warning
Renaming a file and undo doesn't warn either.
These are not destructive operations, correct? The original expectation was that all destructive operations would prompt, do you think that any operations at all should prompt?
The way I interpreter is it will warn is it prompts and tells you what's going to happen when you undo/redo as the undo/redo is focus based and it's likely to mis-trigger. I don't necessarily want to disable this feature (as it's convinient) but I want to be aware of what's going to change. Undo the dnd is one of them as I might miss where the file will be moved into (especially when I'm traversing in the undo stack).
Changed the config around to better stratify this:


Question: <img width="452" alt="Screen Shot 2022-01-27 at 11 21 24 am" src="https://user-"


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/No <!-- 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.64.2 OS Version: Windows 10 Steps to Reproduce: a git repo in root of a drive (network share in my case) a change of a file to Source control a see file diff version is shown as empty command line shows diffs properly when git repo is located in some subfolder git diff works in VSCode properly
VS Code Version: 1.67.2 OS Version: Windows 10 () I am also receiving this error, and I have pinpointed it in the Git Output, hopefully, it helps the path is missing the first character in the path for a specific file on the 'git show --textconv' lines 'ub-folder' vs 'sub-folder' If the command is run manually, with the correct path there are no issues Working (Non-root folder) [2022-06-01T06:49:42.910Z] git ls-tree -l HEAD -- fserverc$gitsharesub-folderMapper [229ms] [2022-06-01T06:49:42.991Z] git show --textconv HEAD:sub- [318ms] Not Working (Root folder) [2022-06-01T06:51:54.868Z] git ls-tree -l HEAD -- fservergitsharesub-folderMapper [226ms] [2022-06-01T06:51:54.897Z] git show --textconv HEAD:ub- [262ms]
The issue is in the file The following Line needs to be changed to As the current process is removing a specific length, when sometimes the variable for 'to' can contain a single slash or double slash (which the + 1 would handle the double slash) I recommend using the regex to effectively trim any leading slashes rather than a calculated length. I have a working file here I can provide further details if required as well.
thank you very much for looking into this. I have looked at this today and while adopting a regex to remove the characters from the resulting path will work, I think that there is something else happening here that I would like to understand before making a fix. Debugging the issue I have noticed that when you open a folder from the root as described in this issue, the value of the parameter contains a trailing . This is why adding +1 to it, will actually remove an unwanted character. I will investigate this further and will get a fix in this week.
Quick update on this issue. While the method can be improved, the root cause of the problem here is that returns a path that has a trailing character. This then results in the repository root being incorrect which can result in unexpected behaviour, diff editor not working being one example. This method already has code to handle mapped drives but it does not seem to handle this particular scenario. As we are in the process of shutting down for the next Stable release, I will be looking at fixing this issue sometimes next week. I will update the issue when the fix will be released in Insiders. Thanks for your patience.
I believe I have tracked down the root cause of the issue to the call: Running the following tests clearly illustrate the problem. Notice that the second call contains a trailing . This particular behavior seems to be by design based on an old issue that I have found - One option that I have considered was to remove the trailing slash from the repository root but that does not seem to be a good option as there are Windows path that are only valid if they contain a trailing slash (ex: ). I am more inclined to tweak the implementation of to always use as that seems to be able to correctly handle directory paths with the trailing . what are your thoughts? Thanks!
Hi, I'm also having this issue, even on the insiders build. I disabled all installed extensions. Expected Git Output: Actual Git Output: The drive in question is a mapped network drive. Whenever I try to view the file diff, the previous file is blank. This problem applies to all files on the network drive, even ones in subdirectories. Let me know if there's any other information I should provide.
I have file to track the problem that you have reported.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Yes
I'll mark this issue as verified as part of . Please file a new issue if the bug continues to occur on the latest Stable and/or Insiders versions of VS Code.

const repoPath = path.normalize(result.stdout.trimLeft().replace(/[rn]+$/, '')); if (isWindows) { <del> // On Git 2.25+ if you call `rev-parse --show-toplevel` on a mapped drive, instead of getting the mapped drive path back, you get the UNC path for the mapped drive. // So we will try to normalize it back to the mapped drive path, if possible </del> <ins> // On Git 2.25+ if you call `rev-parse --show-toplevel` on a mapped drive, instead of getting the mapped // drive path back, you get the UNC path for the mapped drive. So we will try to normalize it back to the // mapped drive path, if possible </ins> const repoUri = Uri.file(repoPath); const pathUri = Uri.file(repositoryPath); if (repoUri.authority.length !== 0 && pathUri.authority.length === 0) {