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.67.2 OS Version: Windows 10 TL/DR: When saving untitled documents that have name with extension, the proposed file name is not the same and can be completely different: -(I do not have a file with that name ANYWHERE on my PC. I have somewhere though) -Steps to Reproduce: Issue 1: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is despite the original Untitled file name already ending with which is a valid extension for YAML files Issue 2: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is , which is unexpected and very surprising. I do not have a file with that name anywhere on my PC. I have somewhere though. Note that the VSCode- extension is here despite VSCode detecting the file format as YAML based on contents. I expect that when saving the file VSCode proposes my given filename and extension to the user. I expect that when saving the file VSCode does not propose completely unrelated file names like .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.67.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Here is how to open an untitled file with associated file path: As for being able to suggest an extension, here is the related issue:
There are certain cases where the proposed solution might not work. The solution requires an absolute file path, but it's not always available. For example, with VSCode Web the workspace might not contain any directories.
I've tested your suggestion and it does not seem to work. The following code still proposes the file name with double extension: does not work either. This bug really breaks the CustomEditor extensions. The saved file is no longer associated with the custom editor due to the mangled name/extension. More so, the Custom editor immediately closes upon saving the file. So the flow becomes: /New File.../ Pipeline on building a pipeline in the custom editor. -VScode prompts for file name suggesting . The user clicks OK immediately closes the custom editor and reopens the file using the text editor (since the file name no longer matches the extension)
Moving to custom editors team for this case.
I think part of this issue is triggered by language detection. I have a hypothesis that the extra is /triggered by the YAML language detector. When the file contains binary data the issue does not seem to be triggered. (I've tested on the modified PawDraw extension modified to propose the file name)
I've just verified the hypothesis. I've modified the CatScratch editor to use the extension and "New Cat Scratch Document" command based on PawDraw. The issue started betting triggered (proposed file name). So the issue is triggered when the document contains valid YAML data (with includes empty file), but does not trigger when the document contains invalid YAML (e.g. binary data).
This also might be related to the "Duplicate editor tab" bug I've previously opened: I've recorded the video that shows both bugs: https://user- See how with first click on "Scratch" another tab opens (with text editor). When saving the custom editor tab, the tab closes (due to the bug we're currently discussing: ).
Repro branch:
me because Ark-kun mentioned language detection... and I own the ML language detection but this has nothing to do with that from what I can tell... it also is easily reproducible without custom editors as the original issue describes. I this to an barebones extension: With the behavior I get when I save the file is: ! Now if I change it to I get: ! I have no idea what is suppose to be. Trying a different file type (which is a language we ship a grammar for) I notice that this does in fact work as expected: ! So with this said, my suspicion is that something is up with YAML... I noticed I had the Python extension installed so I disabled it and well well well: ! So one that needs to go to the Python extension: "don't clobber the YAML file association". Looks like there are several instances of that in the extension: As for why becomes I'm not totally sure... but a discovery I made was with this list: in the built-in YAML extension (which just provides syntax highlighting). is at the top of the list. If I move to the top of this list, suddenly, this works: ! So two is "all possible extensions should be taken into consideration". I think you own this? What do you think?
nice analysis The issue here is that our logic for figuring out a file name for untitled files is pretty weak: We basically just append the first extension for the language, but we can be smarter: preserve extension when it matches (same for languages that only have file names) actually replace the extension when it does not match so that we do not have 2 extensions piling up I think this fix addresses both issues but would be good to verify then. PR:
so then after this change, what the Python extension is doing is correct to associate YAML with a new file extension?
Yes I do not think that is an issue.
<!-- 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!

suggestFilename(languageId: string, untitledName: string) { const languageName = this.languageService.getLanguageName(languageId); if (!languageName) { <del> return untitledName; </del> <ins> return untitledName; // unknown language, so we cannot suggest a better name </ins> } <del> const extension = this.languageService.getExtensions(languageId)[0]; if (extension) { if (!untitledName.endsWith(extension)) { return untitledName + extension; </del> <ins> const untitledExtension = pathExtname(untitledName); const extensions = this.languageService.getExtensions(languageId); if (extensions.includes(untitledExtension)) { return untitledName; // preserve extension if it is compatible with the mode } const primaryExtension = firstOrDefault(extensions); if (primaryExtension) { if (untitledExtension) { return `${untitledName.substring(0, untitledName.indexOf(untitledExtension))}${primaryExtension}`; </ins> } <ins> return `${untitledName}${primaryExtension}`; } const filenames = this.languageService.getFilenames(languageId); if (filenames.includes(untitledName)) { return untitledName; // preserve name if it is compatible with the mode </ins> } <del> const filename = this.languageService.getFilenames(languageId)[0]; return filename || untitledName; </del> <ins> return firstOrDefault(filenames) ?? untitledName; </ins> } //#endregion


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.67.2 OS Version: Windows 10 TL/DR: When saving untitled documents that have name with extension, the proposed file name is not the same and can be completely different: -(I do not have a file with that name ANYWHERE on my PC. I have somewhere though) -Steps to Reproduce: Issue 1: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is despite the original Untitled file name already ending with which is a valid extension for YAML files Issue 2: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is , which is unexpected and very surprising. I do not have a file with that name anywhere on my PC. I have somewhere though. Note that the VSCode- extension is here despite VSCode detecting the file format as YAML based on contents. I expect that when saving the file VSCode proposes my given filename and extension to the user. I expect that when saving the file VSCode does not propose completely unrelated file names like .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.67.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Here is how to open an untitled file with associated file path: As for being able to suggest an extension, here is the related issue:
There are certain cases where the proposed solution might not work. The solution requires an absolute file path, but it's not always available. For example, with VSCode Web the workspace might not contain any directories.
I've tested your suggestion and it does not seem to work. The following code still proposes the file name with double extension: does not work either. This bug really breaks the CustomEditor extensions. The saved file is no longer associated with the custom editor due to the mangled name/extension. More so, the Custom editor immediately closes upon saving the file. So the flow becomes: /New File.../ Pipeline on building a pipeline in the custom editor. -VScode prompts for file name suggesting . The user clicks OK immediately closes the custom editor and reopens the file using the text editor (since the file name no longer matches the extension)
Moving to custom editors team for this case.
I think part of this issue is triggered by language detection. I have a hypothesis that the extra is /triggered by the YAML language detector. When the file contains binary data the issue does not seem to be triggered. (I've tested on the modified PawDraw extension modified to propose the file name)
I've just verified the hypothesis. I've modified the CatScratch editor to use the extension and "New Cat Scratch Document" command based on PawDraw. The issue started betting triggered (proposed file name). So the issue is triggered when the document contains valid YAML data (with includes empty file), but does not trigger when the document contains invalid YAML (e.g. binary data).
This also might be related to the "Duplicate editor tab" bug I've previously opened: I've recorded the video that shows both bugs: https://user- See how with first click on "Scratch" another tab opens (with text editor). When saving the custom editor tab, the tab closes (due to the bug we're currently discussing: ).
Repro branch:
me because Ark-kun mentioned language detection... and I own the ML language detection but this has nothing to do with that from what I can tell... it also is easily reproducible without custom editors as the original issue describes. I this to an barebones extension: With the behavior I get when I save the file is: ! Now if I change it to I get: ! I have no idea what is suppose to be. Trying a different file type (which is a language we ship a grammar for) I notice that this does in fact work as expected: ! So with this said, my suspicion is that something is up with YAML... I noticed I had the Python extension installed so I disabled it and well well well: ! So one that needs to go to the Python extension: "don't clobber the YAML file association". Looks like there are several instances of that in the extension: As for why becomes I'm not totally sure... but a discovery I made was with this list: in the built-in YAML extension (which just provides syntax highlighting). is at the top of the list. If I move to the top of this list, suddenly, this works: ! So two is "all possible extensions should be taken into consideration". I think you own this? What do you think?
nice analysis The issue here is that our logic for figuring out a file name for untitled files is pretty weak: We basically just append the first extension for the language, but we can be smarter: preserve extension when it matches (same for languages that only have file names) actually replace the extension when it does not match so that we do not have 2 extensions piling up I think this fix addresses both issues but would be good to verify then. PR:
so then after this change, what the Python extension is doing is correct to associate YAML with a new file extension?
Yes I do not think that is an issue.
<!-- 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!

registration.dispose(); }); <ins> test('Filename Suggestion - Preserve extension if it matchers', () => { const registration = accessor.languageService.registerLanguage({ id: 'plumbus2', extensions: ['.shleem', '.gazorpazorp'], }); const suggested = accessor.textFileService.suggestFilename('plumbus2', 'Untitled-1.gazorpazorp'); assert.strictEqual(suggested, 'Untitled-1.gazorpazorp'); registration.dispose(); }); test('Filename Suggestion - Rewrite extension according to language', () => { const registration = accessor.languageService.registerLanguage({ id: 'plumbus2', extensions: ['.shleem', '.gazorpazorp'], }); const suggested = accessor.textFileService.suggestFilename('plumbus2', 'Untitled-1.foobar'); assert.strictEqual(suggested, 'Untitled-1.shleem'); registration.dispose(); }); </ins> test('Filename Suggestion - Suggest filename if there are no extensions', () => { const registration = accessor.languageService.registerLanguage({ id: 'plumbus2',


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.67.2 OS Version: Windows 10 TL/DR: When saving untitled documents that have name with extension, the proposed file name is not the same and can be completely different: -(I do not have a file with that name ANYWHERE on my PC. I have somewhere though) -Steps to Reproduce: Issue 1: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is despite the original Untitled file name already ending with which is a valid extension for YAML files Issue 2: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is , which is unexpected and very surprising. I do not have a file with that name anywhere on my PC. I have somewhere though. Note that the VSCode- extension is here despite VSCode detecting the file format as YAML based on contents. I expect that when saving the file VSCode proposes my given filename and extension to the user. I expect that when saving the file VSCode does not propose completely unrelated file names like .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.67.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Here is how to open an untitled file with associated file path: As for being able to suggest an extension, here is the related issue:
There are certain cases where the proposed solution might not work. The solution requires an absolute file path, but it's not always available. For example, with VSCode Web the workspace might not contain any directories.
I've tested your suggestion and it does not seem to work. The following code still proposes the file name with double extension: does not work either. This bug really breaks the CustomEditor extensions. The saved file is no longer associated with the custom editor due to the mangled name/extension. More so, the Custom editor immediately closes upon saving the file. So the flow becomes: /New File.../ Pipeline on building a pipeline in the custom editor. -VScode prompts for file name suggesting . The user clicks OK immediately closes the custom editor and reopens the file using the text editor (since the file name no longer matches the extension)
Moving to custom editors team for this case.
I think part of this issue is triggered by language detection. I have a hypothesis that the extra is /triggered by the YAML language detector. When the file contains binary data the issue does not seem to be triggered. (I've tested on the modified PawDraw extension modified to propose the file name)
I've just verified the hypothesis. I've modified the CatScratch editor to use the extension and "New Cat Scratch Document" command based on PawDraw. The issue started betting triggered (proposed file name). So the issue is triggered when the document contains valid YAML data (with includes empty file), but does not trigger when the document contains invalid YAML (e.g. binary data).
This also might be related to the "Duplicate editor tab" bug I've previously opened: I've recorded the video that shows both bugs: https://user- See how with first click on "Scratch" another tab opens (with text editor). When saving the custom editor tab, the tab closes (due to the bug we're currently discussing: ).
Repro branch:
me because Ark-kun mentioned language detection... and I own the ML language detection but this has nothing to do with that from what I can tell... it also is easily reproducible without custom editors as the original issue describes. I this to an barebones extension: With the behavior I get when I save the file is: ! Now if I change it to I get: ! I have no idea what is suppose to be. Trying a different file type (which is a language we ship a grammar for) I notice that this does in fact work as expected: ! So with this said, my suspicion is that something is up with YAML... I noticed I had the Python extension installed so I disabled it and well well well: ! So one that needs to go to the Python extension: "don't clobber the YAML file association". Looks like there are several instances of that in the extension: As for why becomes I'm not totally sure... but a discovery I made was with this list: in the built-in YAML extension (which just provides syntax highlighting). is at the top of the list. If I move to the top of this list, suddenly, this works: ! So two is "all possible extensions should be taken into consideration". I think you own this? What do you think?
nice analysis The issue here is that our logic for figuring out a file name for untitled files is pretty weak: We basically just append the first extension for the language, but we can be smarter: preserve extension when it matches (same for languages that only have file names) actually replace the extension when it does not match so that we do not have 2 extensions piling up I think this fix addresses both issues but would be good to verify then. PR:
so then after this change, what the Python extension is doing is correct to associate YAML with a new file extension?
Yes I do not think that is an issue.
<!-- 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!

assert.strictEqual(suggested, 'plumbus'); registration.dispose(); }); <ins> test('Filename Suggestion - Preserve filename if it matches', () => { const registration = accessor.languageService.registerLanguage({ id: 'plumbus2', filenames: ['plumbus', 'shleem', 'gazorpazorp'] }); const suggested = accessor.textFileService.suggestFilename('plumbus2', 'gazorpazorp'); assert.strictEqual(suggested, 'gazorpazorp'); registration.dispose(); }); test('Filename Suggestion - Rewrites filename according to language', () => { const registration = accessor.languageService.registerLanguage({ id: 'plumbus2', filenames: ['plumbus', 'shleem', 'gazorpazorp'] }); const suggested = accessor.textFileService.suggestFilename('plumbus2', 'foobar'); assert.strictEqual(suggested, 'plumbus'); registration.dispose(); }); </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. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice. Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!
With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?

} this._currentCommand.commandFinishedMarker = this._terminal.registerMarker(0); <del> const command = this._currentCommand.command; </del> <ins> let command = this._currentCommand.command; </ins> this._logService.debug('CommandDetectionCapability#handleCommandFinished', this._terminal.buffer.active.cursorX, this._currentCommand.commandFinishedMarker?.line, this._currentCommand.command, this._currentCommand); this._exitCode = exitCode;


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. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice. Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!
With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?

return; } <ins> // When the command finishes and executed never fires the placeholder selector should be used. if (this._exitCode === undefined && command === undefined) { command = ''; } </ins> if ((command !== undefined && !command.startsWith('')) || this._handleCommandStartOptions?.ignoreCommandLine) { const buffer = this._terminal.buffer.active; const timestamp = Date.now();


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. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice. Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!
With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?

} # Debug trapping/preexec inspired by starship (ISC) <del> __vsc_dbg_trap="$(trap -p DEBUG | cut -d' ' -f3 | tr -d ')" if [[ -z "$__vsc_dbg_trap" ]]; then </del> <ins> if [[ -n "${bash_preexec_imported:-}" ]]; then </ins> __vsc_preexec_only() { __vsc_status="$?" __vsc_preexec } <del> trap '__vsc_preexec_only "$_"' DEBUG elif [[ "$__vsc_dbg_trap" != '__vsc_preexec "$_"' && "$__vsc_dbg_trap" != '__vsc_preexec_all "$_"' ]]; then __vsc_preexec_all() { __vsc_status="$?" builtin eval ${__vsc_dbg_trap} __vsc_preexec } trap '__vsc_preexec_all "$_"' DEBUG </del> <ins> precmd_functions+=(__vsc_prompt_cmd) preexec_functions+=(__vsc_preexec_only) else __vsc_dbg_trap="$(trap -p DEBUG | cut -d' ' -f3 | tr -d ')" if [[ -z "$__vsc_dbg_trap" ]]; then __vsc_preexec_only() { __vsc_status="$?" __vsc_preexec } trap '__vsc_preexec_only "$_"' DEBUG elif [[ "$__vsc_dbg_trap" != '__vsc_preexec "$_"' && "$__vsc_dbg_trap" != '__vsc_preexec_all "$_"' ]]; then __vsc_preexec_all() { __vsc_status="$?" builtin eval ${__vsc_dbg_trap} __vsc_preexec } trap '__vsc_preexec_all "$_"' DEBUG fi </ins> fi __vsc_update_prompt


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. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice. Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!
With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?

__vsc_original_prompt_command=${PROMPT_COMMAND[@]} fi <del> if [[ -n "$__vsc_original_prompt_command" && "$__vsc_original_prompt_command" != "__vsc_prompt_cmd" ]]; then PROMPT_COMMAND=__vsc_prompt_cmd_original else PROMPT_COMMAND=__vsc_prompt_cmd </del> <ins> if [[ -z "${bash_preexec_imported:-}" ]]; then if [[ -n "$__vsc_original_prompt_command" && "$__vsc_original_prompt_command" != "__vsc_prompt_cmd" ]]; then PROMPT_COMMAND=__vsc_prompt_cmd_original else PROMPT_COMMAND=__vsc_prompt_cmd fi </ins> fi


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. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice. Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!
With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?

} __vsc_preexec() { <del> if [ "$__vsc_in_command_execution" = "0" ]; then __vsc_initialized=1 __vsc_in_command_execution="1" if [[ ! "$BASH_COMMAND" =~ ^__vsc_prompt* ]]; then __vsc_current_command=$BASH_COMMAND else __vsc_current_command="" fi __vsc_command_output_start </del> <ins> __vsc_initialized=1 if [[ ! "$BASH_COMMAND" =~ ^__vsc_prompt* ]]; then __vsc_current_command=$BASH_COMMAND else __vsc_current_command="" </ins> fi <ins> __vsc_command_output_start </ins> } # Debug trapping/preexec inspired by starship (ISC) if [[ -n "${bash_preexec_imported:-}" ]]; then __vsc_preexec_only() { <del> __vsc_status="$?" __vsc_preexec </del> <ins> if [ "$__vsc_in_command_execution" = "0" ]; then __vsc_in_command_execution="1" __vsc_preexec fi </ins> } precmd_functions+=(__vsc_prompt_cmd) preexec_functions+=(__vsc_preexec_only)


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. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice. Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!
With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?

__vsc_dbg_trap="$(trap -p DEBUG | cut -d' ' -f3 | tr -d ')" if [[ -z "$__vsc_dbg_trap" ]]; then __vsc_preexec_only() { <del> __vsc_status="$?" __vsc_preexec </del> <ins> if [ "$__vsc_in_command_execution" = "0" ]; then __vsc_in_command_execution="1" __vsc_preexec fi </ins> } trap '__vsc_preexec_only "$_"' DEBUG elif [[ "$__vsc_dbg_trap" != '__vsc_preexec "$_"' && "$__vsc_dbg_trap" != '__vsc_preexec_all "$_"' ]]; then __vsc_preexec_all() { <del> __vsc_status="$?" builtin eval ${__vsc_dbg_trap} __vsc_preexec </del> <ins> if [ "$__vsc_in_command_execution" = "0" ]; then __vsc_in_command_execution="1" builtin eval ${__vsc_dbg_trap} __vsc_preexec fi </ins> } trap '__vsc_preexec_all "$_"' DEBUG fi


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. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice. Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!
With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?

__vsc_update_prompt __vsc_prompt_cmd_original() { <ins> __vsc_status="$?" </ins> if [[ ${IFS+set} ]]; then __vsc_original_ifs="$IFS" fi


Question:
I am the maintainer of VS Code basic latex language support. The language defines / as a bracket pair. This leads to wrongly highlight <img width="415" alt="Capture d’écran 2022-05-26 à 08 07 09" src="https://user-"I believe this is related to fixed it in by surrounding brackets using letters only with . However, in LaTeX every command starts with and the fix does not apply. This issue occurs on Version: 1.67.2 and also on Version: 1.68.0-insider (Universal) Commit: Date: 2022-05-25T05:16:10.689Z Electron: 17.4.4 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0 This problem was originally reported at
should be extended to check if the bracket starts/ends with a word. Only at those borders, should be . Should be easy to implement. I'm open for a PR here ;)
hey I am a beginner in open source contributions . Could you please guide me how too start contributing
I'd start here:
Hi I'm just starting out with open source contributions and just finished reading the how to guide you linked in this thread. I'm having some trouble understanding exactly what the issue is, could you please explain it a bit more? Is rangledot supposed to be highlighted as a whole?
This issue is actually already handled by PR , which will be merged for the July 2022 release.
Verification steps: Install the LaTeX extension Verify that and is matched, but not with in
I would personally highly go against this fix As it would disallow word based brackets inside word strings with no alternative (other than to reinvent the bracket highlighter again) I have no example of any language being affected But I would question the arbitration decesion to limit such function Instead, I think LaTeX should fix their bug (which was present before coloured brackets) by just disallowing/allowing certain word based bracket scopes via the and sections in !
Let's discuss this in a separate issue once this actually is a problem!

} function prepareBracketForRegExp(str: string): string { <del> const escaped = escapeRegExpCharacters(str); // This bracket pair uses letters like e.g. "begin" - "end" (see https://github.com/microsoft/vscode/issues/132162) const needsWordBoundaries = (/^[w ]+$/.test(str)); return (needsWordBoundaries ? `b${escaped}b` : escaped); </del> <ins> let escaped = escapeRegExpCharacters(str); // These bracket pair delimiters start or end with letters // see https://github.com/microsoft/vscode/issues/132162 https://github.com/microsoft/vscode/issues/150440 if (/^[w ]+/.test(str)) { escaped = `b${escaped}`; } if (/[w ]+$/.test(str)) { escaped = `${escaped}b`; } return escaped; </ins> } export class LanguageAgnosticBracketTokens {


Question:
Testing Version: 1.68.0-insider (user setup) Commit: Date: 2022-05-31T05:17:04.479Z Run the command and select Would be nice to get a message in the log
Looks like the the message is not shown as it is of type and is less than than. Would be good to always show it, regardless of the current and the new level. Same problem with the initial message when the output is started.

return; } <del> this.outputChannelLogger.setLogLevel(choice.logLevel); </del> <ins> this.outputChannelLogger.currentLogLevel = choice.logLevel; </ins> } @command('git.refresh', { repository: true })


Question:
Testing Version: 1.68.0-insider (user setup) Commit: Date: 2022-05-31T05:17:04.479Z Run the command and select Would be nice to get a message in the log
Looks like the the message is not shown as it is of type and is less than than. Would be good to always show it, regardless of the current and the new level. Same problem with the initial message when the output is started.

private _onDidChangeLogLevel = new EventEmitter<LogLevel>(); readonly onDidChangeLogLevel: Event<LogLevel> = this._onDidChangeLogLevel.event; <del> private _currentLogLevel: LogLevel; </del> <ins> private _currentLogLevel!: LogLevel; </ins> get currentLogLevel(): LogLevel { return this._currentLogLevel; } <ins> set currentLogLevel(value: LogLevel) { if (this._currentLogLevel === value) { return; } this._currentLogLevel = value; this._onDidChangeLogLevel.fire(value); this.log(localize('gitLogLevel', "Log level: {0}", LogLevel[value])); } </ins> <del> private _defaultLogLevel: LogLevel; </del> <ins> private _defaultLogLevel!: LogLevel; </ins> get defaultLogLevel(): LogLevel { return this._defaultLogLevel; }


Question:
Testing Version: 1.68.0-insider (user setup) Commit: Date: 2022-05-31T05:17:04.479Z Run the command and select Would be nice to get a message in the log
Looks like the the message is not shown as it is of type and is less than than. Would be good to always show it, regardless of the current and the new level. Same problem with the initial message when the output is started.

commands.registerCommand('git.showOutput', () => this.showOutputChannel()); this._disposables.push(this._outputChannel); <del> // Initialize log level </del> <ins> this._disposables.push(workspace.onDidChangeConfiguration(e => { if (e.affectsConfiguration('git.logLevel')) { this.onLogLevelChange(); } })); this.onLogLevelChange(); } private onLogLevelChange(): void { </ins> const config = workspace.getConfiguration('git'); const logLevel: keyof typeof LogLevel = config.get('logLevel', 'Info'); <del> this._currentLogLevel = this._defaultLogLevel = LogLevel[logLevel] ?? LogLevel.Info; this.logInfo(localize('gitLogLevel', "Log level: {0}", LogLevel[this._currentLogLevel])); </del> <ins> this.currentLogLevel = this._defaultLogLevel = LogLevel[logLevel] ?? LogLevel.Info; </ins> } <del> private log(message: string, logLevel: LogLevel): void { if (logLevel < this._currentLogLevel) { </del> <ins> log(message: string, logLevel?: LogLevel): void { if (logLevel && logLevel < this._currentLogLevel) { </ins> return; } <del> this._outputChannel.appendLine(`[${new Date().toISOString()}] [${LogLevel[logLevel].toLowerCase()}] ${message}`); </del> <ins> this._outputChannel.appendLine(`[${new Date().toISOString()}]${logLevel ? ` [${LogLevel[logLevel].toLowerCase()}]` : ''} ${message}`); </ins> } logCritical(message: string): void {


Question:
Testing Version: 1.68.0-insider (user setup) Commit: Date: 2022-05-31T05:17:04.479Z Run the command and select Would be nice to get a message in the log
Looks like the the message is not shown as it is of type and is less than than. Would be good to always show it, regardless of the current and the new level. Same problem with the initial message when the output is started.

this.log(message, LogLevel.Warning); } <del> logGitCommand(command: string): void { this._outputChannel.appendLine(`[${new Date().toISOString()}] ${command}`); } setLogLevel(logLevel: LogLevel): void { if (this._currentLogLevel === logLevel) { return; } this._currentLogLevel = logLevel; this._onDidChangeLogLevel.fire(logLevel); this.logInfo(localize('changed', "Log level changed to: {0}", LogLevel[logLevel])); } </del> showOutputChannel(): void { this._outputChannel.show(); }


Question:
Testing Version: 1.68.0-insider (user setup) Commit: Date: 2022-05-31T05:17:04.479Z Run the command and select Would be nice to get a message in the log
Looks like the the message is not shown as it is of type and is less than than. Would be good to always show it, regardless of the current and the new level. Same problem with the initial message when the output is started.

lines.pop(); } <del> outputChannelLogger.logGitCommand(lines.join('n')); </del> <ins> outputChannelLogger.log(lines.join('n')); </ins> }; git.onOutput.addListener('log', onOutput); disposables.push(toDisposable(() => git.onOutput.removeListener('log', onOutput)));


Question:
Testing Things I would change: make it clear in the picker that selecting a language from the lower list will install it have a button in the picker that installs and syncs it. don't reveal the extension viewlet don't show that dialog <img width="444" alt="capture" src="https://user-"
is there a way to not show this dialog when installing an extension using the Extension management service? Here's the specific line:
How would you make this clearer? I figured since we had a section called that will always be there on Desktop it's implied that must not be installed. What will the default behavior be then when you accept a quick pick item? That it will install but not sync? That's not what the default is for the button in the extension pane so that seems a bit odd to me. This was to give a progress indication. We do the same thing for the Theme picker. I would like to hide this dialog. I didn't see it locally because Settings Sync isn't available in but I asked Sandeep above.
Yes, you can pass machine scoped flag to avoid this. Passing for this flag will not sync the extension and will sync it.
I thought the main reason for the dialog was to inform the user that something is installed. I can easily live with only the picker Since the dialog offered the option, I thought it is important. I can live with the default without a choice. I found it disturbing. I could live without progress or some window progress.

import { IExtensionsViewPaneContainer, VIEWLET_ID as EXTENSIONS_VIEWLET_ID } from 'vs/workbench/contrib/extensions/common/extensions'; import { ViewContainerLocation } from 'vs/workbench/common/views'; import { IExtensionManagementService } from 'vs/platform/extensionManagement/common/extensionManagement'; <ins> import { IProgressService, ProgressLocation } from 'vs/platform/progress/common/progress'; import { localize } from 'vs/nls'; </ins> export class NativeLocaleService implements ILocaleService { _serviceBrand: undefined;


Question:
Testing Things I would change: make it clear in the picker that selecting a language from the lower list will install it have a button in the picker that installs and syncs it. don't reveal the extension viewlet don't show that dialog <img width="444" alt="capture" src="https://user-"
is there a way to not show this dialog when installing an extension using the Extension management service? Here's the specific line:
How would you make this clearer? I figured since we had a section called that will always be there on Desktop it's implied that must not be installed. What will the default behavior be then when you accept a quick pick item? That it will install but not sync? That's not what the default is for the button in the extension pane so that seems a bit odd to me. This was to give a progress indication. We do the same thing for the Theme picker. I would like to hide this dialog. I didn't see it locally because Settings Sync isn't available in but I asked Sandeep above.
Yes, you can pass machine scoped flag to avoid this. Passing for this flag will not sync the extension and will sync it.
I thought the main reason for the dialog was to inform the user that something is installed. I can easily live with only the picker Since the dialog offered the option, I thought it is important. I can live with the default without a choice. I found it disturbing. I could live without progress or some window progress.

@ILanguagePackService private readonly languagePackService: ILanguagePackService, @IPaneCompositePartService private readonly paneCompositePartService: IPaneCompositePartService, @IExtensionManagementService private readonly extensionManagementService: IExtensionManagementService, <ins> @IProgressService private readonly progressService: IProgressService </ins> ) { } private async writeLocaleValue(locale: string | undefined): Promise<void> {


Question:
Testing Things I would change: make it clear in the picker that selecting a language from the lower list will install it have a button in the picker that installs and syncs it. don't reveal the extension viewlet don't show that dialog <img width="444" alt="capture" src="https://user-"
is there a way to not show this dialog when installing an extension using the Extension management service? Here's the specific line:
How would you make this clearer? I figured since we had a section called that will always be there on Desktop it's implied that must not be installed. What will the default behavior be then when you accept a quick pick item? That it will install but not sync? That's not what the default is for the button in the extension pane so that seems a bit odd to me. This was to give a progress indication. We do the same thing for the Theme picker. I would like to hide this dialog. I didn't see it locally because Settings Sync isn't available in but I asked Sandeep above.
Yes, you can pass machine scoped flag to avoid this. Passing for this flag will not sync the extension and will sync it.
I thought the main reason for the dialog was to inform the user that something is installed. I can easily live with only the picker Since the dialog offered the option, I thought it is important. I can live with the default without a choice. I found it disturbing. I could live without progress or some window progress.

// Only Desktop has the concept of installing language packs so we only do this for Desktop // and only if the language pack is not installed if (!installedLanguages.some(installedLanguage => installedLanguage.id === languagePackItem.id)) { <del> // Show the view so the user can see the language pack to be installed let viewlet = await this.paneCompositePartService.openPaneComposite(EXTENSIONS_VIEWLET_ID, ViewContainerLocation.Sidebar); (viewlet?.getViewPaneContainer() as IExtensionsViewPaneContainer).search(`@id:${languagePackItem.extensionId}`); </del> // Only actually install a language pack from Microsoft if (languagePackItem.galleryExtension?.publisher.toLowerCase() !== 'ms-ceintl') { <ins> // Show the view so the user can see the language pack that they should install // as of now, there are no 3rd party language packs available on the Marketplace. let viewlet = await this.paneCompositePartService.openPaneComposite(EXTENSIONS_VIEWLET_ID, ViewContainerLocation.Sidebar); (viewlet?.getViewPaneContainer() as IExtensionsViewPaneContainer).search(`@id:${languagePackItem.extensionId}`); </ins> return false; } <del> await this.extensionManagementService.installFromGallery(languagePackItem.galleryExtension); </del> <ins> await this.progressService.withProgress( { location: ProgressLocation.Notification, title: localize('installing', "Installing {0} language support...", languagePackItem.label), }, progress => this.extensionManagementService.installFromGallery(languagePackItem.galleryExtension!, { // Setting this to false is how you get the extension to be synced with Settings Sync (if enabled). isMachineScoped: false, }) ); </ins> } await this.writeLocaleValue(locale);


Question:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

import { CancellationToken } from 'vs/base/common/cancellation'; import { KeyCode } from 'vs/base/common/keyCodes'; import { Disposable, DisposableStore, toDisposable } from 'vs/base/common/lifecycle'; <del> import { Constants } from 'vs/base/common/uint'; </del> import { ContentWidgetPositionPreference, IActiveCodeEditor, ICodeEditor, IContentWidget, IContentWidgetPosition, IEditorMouseEvent, MouseTargetType } from 'vs/editor/browser/editorBrowser'; import { ConfigurationChangedEvent, EditorOption } from 'vs/editor/common/config/editorOptions'; import { Position } from 'vs/editor/common/core/position';


Question:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

} private _renderMessages(anchor: HoverAnchor, messages: IHoverPart[]): void { <del> // update column from which to show let renderColumn = Constants.MAX_SAFE_SMALL_INTEGER; let highlightRange: Range = messages[0].range; let forceShowAtRange: Range | null = null; for (const msg of messages) { renderColumn = Math.min(renderColumn, msg.range.startColumn); highlightRange = Range.plusRange(highlightRange, msg.range); if (msg.forceShowAtRange) { forceShowAtRange = msg.range; } } </del> <ins> const { showAtPosition, showAtRange, highlightRange } = ContentHoverController.computeHoverRanges(anchor.range, messages); </ins> const disposables = new DisposableStore(); const statusBar = disposables.add(new EditorHoverStatusBar(this._keybindingService));


Question:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

this._widget.showAt(fragment, new ContentHoverVisibleData( colorPicker, <del> forceShowAtRange ? forceShowAtRange.getStartPosition() : new Position(anchor.range.startLineNumber, renderColumn), forceShowAtRange ? forceShowAtRange : highlightRange, </del> <ins> showAtPosition, showAtRange, </ins> this._editor.getOption(EditorOption.hover).above, this._computer.shouldFocus, disposables


Question:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

description: 'content-hover-highlight', className: 'hoverHighlight' }); <ins> public static computeHoverRanges(anchorRange: Range, messages: IHoverPart[]) { // The anchor range is always on a single line const anchorLineNumber = anchorRange.startLineNumber; let renderStartColumn = anchorRange.startColumn; let renderEndColumn = anchorRange.endColumn; let highlightRange: Range = messages[0].range; let forceShowAtRange: Range | null = null; for (const msg of messages) { highlightRange = Range.plusRange(highlightRange, msg.range); if (msg.range.startLineNumber === anchorLineNumber && msg.range.endLineNumber === anchorLineNumber) { // this message has a range that is completely sitting on the line of the anchor renderStartColumn = Math.min(renderStartColumn, msg.range.startColumn); renderEndColumn = Math.max(renderEndColumn, msg.range.endColumn); } if (msg.forceShowAtRange) { forceShowAtRange = msg.range; } } return { showAtPosition: forceShowAtRange ? forceShowAtRange.getStartPosition() : new Position(anchorRange.startLineNumber, renderStartColumn), showAtRange: forceShowAtRange ? forceShowAtRange : new Range(anchorLineNumber, renderStartColumn, anchorLineNumber, renderEndColumn), highlightRange }; } </ins> } class ContentHoverVisibleData {


Question:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import { ContentHoverController } from 'vs/editor/contrib/hover/browser/contentHover'; import { Range } from 'vs/editor/common/core/range'; import { Position } from 'vs/editor/common/core/position'; import { IHoverPart } from 'vs/editor/contrib/hover/browser/hoverTypes'; suite('Content Hover', () => { test('issue #151235: Gitlens hover shows up in the wrong place', () => { const actual = ContentHoverController.computeHoverRanges( new Range(5, 5, 5, 5), [<IHoverPart>{ range: new Range(4, 1, 5, 6) }] ); assert.deepStrictEqual( actual, { showAtPosition: new Position(5, 5), showAtRange: new Range(5, 5, 5, 5), highlightRange: new Range(4, 1, 5, 6) } ); }); }); </ins>


Question:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

this._hover.contentsDomNode.style.paddingBottom = ''; this._updateFont(); <del> this._editor.layoutContentWidget(this); </del> this.onContentsChanged(); // Simply force a synchronous render on the editor


Question:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

// See https://github.com/microsoft/vscode/issues/140339 // TODO: Doing a second layout of the hover after force rendering the editor <del> this._editor.layoutContentWidget(this); </del> this.onContentsChanged(); if (visibleData.stoleFocus) {


Question:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

} public onContentsChanged(): void { <ins> this._editor.layoutContentWidget(this); </ins> this._hover.onContentsChanged(); const scrollDimensions = this._hover.scrollbar.getScrollDimensions();


Question:
While verifying I noticed that if I click on the warning I'm not taken to the size limit setting which I would've expected to be taken to. ! Version: 1.68.0-insider (Universal) Commit: Date: 2022-06-02T05:16:30.515Z Electron: 17.4.6 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0 Jupyter Extension version (available under the Extensions sidebar): v2022.5. Python Extension version (available under the Extensions sidebar): v2022.7.
This link is specified in core code.
The issue doesn't seem to be fixed in the latest insiders. Reopening
The issue is now fixed for me in the latest Insiders, at least on Windows 11.

first.textContent = 'Output exceeds the '; const second = document.createElement('a'); second.textContent = 'size limit'; <del> second.href = `command:workbench.action.openSettings?["notebook.output.textLineLimit"]`; </del> <ins> second.href = `command:workbench.action.openSettings?%5B%22notebook.output.textLineLimit%22%5D`; </ins> const third = document.createElement('span'); third.textContent = '. Open the full output data'; const forth = document.createElement('a');


Question: Open the color theme picker and select the first option () Observe that it takes around 5 seconds for the results to show. This used to be much snappier

try { const installedExtensions = await this._installedExtensions; <del> const options = { text: `${this.marketplaceQuery} ${value}`, pageSize: 40 }; </del> <ins> const options = { text: `${this.marketplaceQuery} ${value}`, pageSize: 20 }; </ins> const pager = await this.extensionGalleryService.query(options, token); <del> for (let i = 0; i < pager.total && i < 1; i++) { </del> <ins> for (let i = 0; i < pager.total && i < 1; i++) { // loading multiple pages is turned of for now to avoid flickering </ins> if (token.isCancellationRequested) { break; } const nThemes = this._marketplaceThemes.length; <ins> const gallery = i === 0 ? pager.firstPage : await pager.getPage(i, token); </ins> <del> const gallery = await pager.getPage(i, token); </del> <ins> const promises: Promise<IWorkbenchTheme[]>[] = []; const promisesGalleries = []; </ins> for (let i = 0; i < gallery.length; i++) { if (token.isCancellationRequested) { break;


Question: Open the color theme picker and select the first option () Observe that it takes around 5 seconds for the results to show. This used to be much snappier

const ext = gallery[i]; if (!installedExtensions.has(ext.identifier.id) && !this._marketplaceExtensions.has(ext.identifier.id)) { this._marketplaceExtensions.add(ext.identifier.id); <del> const themes = await this.getMarketplaceColorThemes(ext.publisher, ext.name, ext.version); for (const theme of themes) { this._marketplaceThemes.push({ id: theme.id, theme: theme, label: theme.label, description: `${ext.displayName} · ${ext.publisherDisplayName}`, galleryExtension: ext, buttons: [configureButton] }); } </del> <ins> promises.push(this.getMarketplaceColorThemes(ext.publisher, ext.name, ext.version)); promisesGalleries.push(ext); } } const allThemes = await Promise.all(promises); for (let i = 0; i < allThemes.length; i++) { const ext = promisesGalleries[i]; for (const theme of allThemes[i]) { this._marketplaceThemes.push({ id: theme.id, theme: theme, label: theme.label, description: `${ext.displayName} · ${ext.publisherDisplayName}`, galleryExtension: ext, buttons: [configureButton] }); </ins> } } if (nThemes !== this._marketplaceThemes.length) { this._marketplaceThemes.sort((t1, t2) => t1.label.localeCompare(t2.label)); this._onDidChange.fire();


Question:
!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal

this.clearDecorations(); } <ins> private _clearPlaceholder(): void { this._placeholderDecoration?.dispose(); this._placeholderDecoration = undefined; } </ins> public clearDecorations(): void { <del> if (this._placeholderDecoration) { this._placeholderDecoration.marker.dispose(); this._placeholderDecoration.dispose(); this._placeholderDecoration = undefined; } </del> <ins> this._placeholderDecoration?.marker.dispose(); this._clearPlaceholder(); </ins> for (const value of this._decorations.values()) { value.decoration.dispose(); dispose(value.disposables);


Question:
!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal

} })); // Current command invalidated <del> this._commandDetectionListeners.push(capability.onCurrentCommandInvalidated(() => { this._placeholderDecoration?.dispose(); this._placeholderDecoration = undefined; })); </del> <ins> this._commandDetectionListeners.push(capability.onCurrentCommandInvalidated(() => this._clearPlaceholder())); </ins> } activate(terminal: Terminal): void {


Question:
!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal

throw new Error(`cannot add a decoration for a command ${JSON.stringify(command)} with no marker`); } <del> this._placeholderDecoration?.dispose(); </del> <ins> this._clearPlaceholder(); </ins> let color = command.exitCode === undefined ? defaultColor : command.exitCode ? errorColor : successColor; if (color && typeof color !== 'string') { color = color.toString();


Question:
!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal

} if (beforeCommandExecution && !this._placeholderDecoration) { this._placeholderDecoration = decoration; <del> this._placeholderDecoration.onDispose(() => this._placeholderDecoration = undefined); </del> } else if (!this._decorations.get(decoration.marker.id)) { decoration.onDispose(() => this._decorations.delete(decoration.marker.id)); this._decorations.set(decoration.marker.id,


Question:
!
This happens because command executed happens but not command finished
And that's because of this:
nice, the fix works https://user-

builtin printf "033]633;D;%s007" "$__vsc_status" __vsc_last_history_id=$__vsc_history_id fi <ins> else builtin printf "033]633;D007" </ins> fi __vsc_update_cwd }


Question:
If a password is not decrypted properly, then it should be removed from the secret storage because it's essentially dead. Originally posted by in
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Verification steps: grab and install in VS Code Insiders Run command Follow the notifications ping me if you have any questions or issues.

if (value.extensionId === extensionId) { return value.content; } <del> } catch (e) { this.logService.error(e); throw new Error('Cannot get password'); </del> <ins> } catch (parseError) { this.logService.error(parseError); // If we can't parse the decrypted value, then it's not a valid secret so we should try to delete it try { await this.credentialsService.deletePassword(fullKey, key); } catch (e) { this.logService.error(e); } throw new Error('Unable to parse decrypted password'); </ins> } }