Only on the first run I had to open my project () install the julia extension trust the authors of the folder open a .jl file in my project
I will add that, when I run the above code the extension server fails every time except for the first time. The first time I get the ERROR below, but the Language Server seems to restart. Also it actually takes ages (maybe 2 or 3 minutes) for the LanguageServer to start. <img width="1194" alt="image" src=""
Thanks for the bisect results, can you confirm if the extension host terminates with julia extension in . Download links available at
yes. it terminates
Sorry I should have provided link to , can you try it again with this version. I am trying to confirm if Electron 22 update was the trigger.
I don't have time for this right now. Interestingly I get another error now (I am using the most recent VS Code version now 1.81.1) Not sure if this is connected though....
can you also confirm , thanks!
I can reproduce the extension host termination with VSCode 1.77.3 and julia-vscode v1.47.2.
Thanks for confirming, that eliminates the allocator changes we adopted for Electron 22 update. Refs
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Thanks for looking into this, Do you need any more info about the extension?
Might be fixed by
Once the libuve PR us merged, do I need to wait for the next minor julia release?
Thanks for sharing the fix , I will backport the fix into Electron as next step.
Steps for verification: 1) Open extension in latest stable, add the following changes 2) Debug extension, run command 3) Stop the debug session 4) Start debug extension again, run command 5) It should crash the extension host Perform steps 1-4 again in latest insiders with the fix and it should not crash.
Seems to be specific to windows, I cannot repro the crash on a Mac.
Yeah, the seems to be in the Windows kernel.
Yes बुध, 25 अक्तू॰ 2023, 11:15 pm को Sebastian Pfitzner < लिखा:


Testing a new notebook and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , :bug: The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
can you maybe check from the notebook side?
Luna paint behaves similarly with one extra step: a new image and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , (different) and the switch profile operation is blocked switch profiles again The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
Somehow today I cannot reproduce an issue with insiders: ! Please give me more detailed steps and see if you still find this.
still seeing it. Did you try making edits after switching? that's when the dirty indicator doesn't show up anymore. ! I saved as a different filename in the gif, but keeping the untitled filename still doesn't show a dirty indicator, nor does it auto-save.
This seems to me like something notebooks need to handle better: if you enter an extension host that does not have the notebook extension and you make edits, the editor should probably not allow that. I.e. the editor should maybe turn readonly once the extension is disabled or not present.
- the notebook extension is built-in so it's still available in an empty profile. The repro steps can even start with an empty profile -and make an edit to the first cell profile to default and save as 1.ipynb when prompted an edit in the notebook :bug: file is not dirty
oh nice, sounds like an issue related to EH restart then, will update the title With your working copy knowledge you might be even able to figure this out ;)
It looks like the issue in the notebook scenario is that it's calling save directly on the workingCopy in the : In the untitled case, that will delegate to saveAs, which will dispose the untitled workingcopy without opening a new editor with the resulting . The editor is left open with its underlying WorkingCopy disposed. For non-built-in custom editors though, it seems like we should just close them if we don't know if they will be supported in the new profile.


I don't see how we can expect a custom editor to support a scenario where its source extension isn't installed - is that even possible? I went over the issue with and concluded that we can defer to next release since the previous stable version also didn't handle this scenario well.
fyi I just created which is a similar issue for custom editors. Here for notebooks I suggest the following: if the EH restarts and still has the notebook extension for the opened notebooks, reconnect to the EH and allow to further make edits on the editor (I actually thought this was already implemented based on the work did) if the EH restarts and there is no more extension for the notebook editor, turn the notebook readonly and inform the user somehow Does that make sense?
The previous change just doesn't account for untitled notebooks, but I think I can fix that. That makes sense, although I'm surprised that we would require all custom editors to handle this (asked about it in the other issue)


Testing My first reaction for how to stop dictation in the editor was to click the flashing microphone. It would be cool if something happened when the flashing microphone is clicked.
I will turn this into a real with action and hover.


Type: <bFeature Request</bCC Please consider auto-activiating accessible view in terminal when user hit enter key. In most cases, screen reader users want to open accessible view after executing command in terminal. Thus, pressing Enter key can do: the current command to terminal. Accessible View immediately. Rather than having this as the default mode, we could consider adding this as a custom user setting. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-02T09:02:24.464Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
This makes sense. let us know if you have any thoughts.
I imagine this mode can boost user productivity because VSCode now sends user typing in Accessible View directly to the active terminal. If this mode is , users will experience more seamless round trip between terminal input and accessible view without having to press Alt+F2 and ESC.
To verify, enable . Run a command in the terminal. The accessible view should open.


Terminal: <img width="328" alt="image" src=""Editor: <img width="436" alt="image" src=""


Currently the list sets the role of each item to be This should only be done for the Tree, not for the list. List should use . More details Tree that actually uses the list should probably pass the role as the getRole to the list it extends from. if you are busy let me know and I can look into this.
We should also verify this nicely works with NVDA, since it is part of aria 1.1 spec.
Sure, PR would be great.
Sure. Assigning to this milestone and if I do not find time might get pushed out.
To verify , turn on NVDA suggest box -make sure that the suggestions do not have "Level 1" read ath the end explorer -make sure the items have appropriate Level read at the end


Issue Type: <bBug</bSet the variable to something like this: You should see something similar to the following: I'm assuming it's associated with . If I'm reading correctly, it checks for semicolons but not things like , , , etc. I understand this is probably an edge case. I was able to workaround by: creating a new function to wrap the others set to the new function VS Code version: Code 1.69.0 (, 2022-07-07T05:28:46.408Z) OS version: Darwin arm64 21.5.0 Restricted Mode: No <!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.69.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I can confirm this bug still exists in 1.69.1, and is probably less of an edge case than you might think , as I found this issue when the terminal wouldn't start because I had powerline installed.
O
My bash (GNU bash, version 5.1.16(1)-release (x86_64-apple-darwin21.1.0)) didn't want to work with empty functions, this reproduces the problem though:


Issue Type: <bBug</bwhen i enable shell integration, i get an error: my contains: VS Code version: Code - Insiders 1.66.0-insider (, 2022-03-28T07:49:37.594Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.60.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ better-cpp-syntax1.15.13 remote-containers0.230.0 remote-ssh0.77. remote-ssh-edit0.77. remote-wsl0.66.0 doxdocgen1.4.0 better-cpp-syntax1.15.13 cmake-tools1.10.5 cpptools1.9.7 cpptools-extension-pack1.1.0 cmake0.0.17 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
looks like you set somewhere which re-writes your . Right now if we detect possible problems with unsupported formats we bail out and disable shell integration by design. To workaround this you could point your at a function and run inside the function instead, for example
Assigning to April to see if we can improve our handling here.
no. i'm not setting . ugh. testing this is a nightmare. vscode seems to keep some persistent state on the server affecting shell startup. anyway, i'd recommend testing with my exact client/server OS combo. is set by the OS to the value above, but weirdly that's not actually what's used to echo my prompt. my prompt, as set in my file is .
It might be set in your or ? VS Code sources a shell environment on startup and that gets used as the base environment for terminals. For WSL you'd need the vscode server to shutdown fully.
no, this also happens when connecting (via ssh) to a fresh CentOS7 install.


<img width="965" alt="image" src="https://user-"
<img width="888" alt="Screen Shot 2022-03-31 at 17 04 04" src="https://user-"
It seems that works right on Manjaro X86_64 <img width="822" alt="image" src="https://user-"
Same here, with Arch and default As workaround I blanked the $PROMPT_COMMAND on my
Thanks for finding the , should make it easy to test against
the shell integration feature also breaks long line-wrapping in bash (happens on Ubuntu, too). the terminal wraps the line before reaching the right edge of the terminal window, and it wraps to the same line overwriting the existing ontents of that line. scrolling through line commands in the bash command history is completely broken.
Tentatively assigning to July as this gets hit with Arch's default


See I have had to revert our commit via
Issue could reoccur if shared process start up is delayed.
What was the problem with ? As far as I can see from the code, every client to the shared process should wait for it to be running. . If this assumption holds, change was correct. Do you have any suggestion as to until when to delay the spawn?
Yeah it would be great if the workbench could signal back some event when editors are restoring, but we currently do not have that. Who is waiting for the shared process to be ready, is it just telemetry and extensions management? We have to be careful to not introduce another deadlock area...
Hmm it ain't the services themselves who wait but the container of them. AFAIK, both the and the wait for the shared process to start.
the workbench does not really wait right, it just runs that code in parallel to the rest of the workbench loading.
The workbench will show. But every call to a shared process service will wait until the shared process has started serving the socket. For example, extensions won't show up in the viewlet until the shared process appears.
It was a guess from analysis and also from testing/verification that removing the delay fixed the dialog issue. I do not think we have a concrete reason why is it depending on the delay.
OK. So it seems we can easily delay it. Can you find a signal in the main process at which point we should spawn it?
somewhere in  possibly with some delay? Alternatively the call to opening a window () returns the opened windows and there is a  promise you could join on. That one is literally resolved when all editors have restored in VS Code.
But the shared process already starts only . Should we just put a timeout then? That would make this change exactly what did last month. I'm not saying it's wrong, just stating the fact. Edit: Actually... his change looks very weird to me now. It seems to delay the connection to the process, not the actual spawning.
yes I think what should get delayed is the creation and opening of the shared process window.
Just note that I have removed the uninstall dialog last milestone. So this might not be an issue any more.


Issue Type: <bBug</bWith at least one folder loaded in Code: to Code Preferences Settings on either "User Settings" or "Workspace Settings" Notice tab spacing is jumpy when changing active selection. It should NOT be as jumpy. I believe it's caused by the text being bolded on active selection. <iDesired</i! <iActual</i! VS Code version: Code 1.28.2 (, 2018-10-17T00:18:43.347Z) OS version: Darwin x64 18.0.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Here's the
I'm not sure about this change, I think the bold is necessary to make the selected tab noticeable. Some themes hide the underline on the selected item, and in some themes, the color difference is not really noticeable. So I would worry that this would make it impossible to tell which tab is selected. I also don't really have an issue with the slight shifting, I've never noticed it before now.
We should try to remove this shift as it's not really smooth. In our other tabs (panels, settings json) we don't use alternate font-weights for active/inactive, so I think we should keep them consistent and the same. Alternatively, if we really want to make the states look different we could adjust the opacity (just like the other tabs) as long as they pass the color contrast ratio: !
I agree that it's not smooth. It's also not consistent with the other tabs in the product. There is a hack that can remove the shifting (discussed with this ), however I think that might be overdoing it to achieve this effect. I would add the opacity change as well to help reinforce the two states.
Should I just borrow the inactive color from the panel tabs, at least for the builtin themes? Or if I should use opacity, can you tell me what color/opacity to use? Looking through some popular ones, I don't think this change would be a problem for that many other themes really... Also for folder settings, the folder name and string "Folder Settings" are currently distinguished by size and color, so we might still need 3 colors.
Actually the current panel tab colors in Monokai don't meet the contrast requirement: ! !


We only need to meet the color contrast on the themes we own, which is light/dark/hc. Here's the contrast on the inactive text: Here's the colors and opacity for the active/inactive panels: For the folder settings, you can change the opacity to (which passes) and will end up looking like this: !
Not using the panel foreground color because the background is not always the same, but I think it looks good as is after the PR.


A Visual Studio Code workspace file is currently recognised in Linux as a normal plain text file. This is because there isn't a MIME type for this file. Applications can provide additional MIME types as described here: Not having a MIME type has a couple of issues, for example the files are shown as plain text files in the GUI, which makes it hard to distinguish source code files from the workspace file. This slows down navigating to a workspace and opening it. Find the workspace in the following screenshot ! It's currently impossible to theme such a file because it's not seen as a different MIME type:
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.461 --<!-- potentialduplicatescomment --
This also means that you can't make double clicking the workspace from a file browser open it in vscode, unless you're OK with all text files opening in vscode, which is probably not what most folks want.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Hi can you verify this issue? Check out the previous comment.
I tried to verify this but am not sure how to do this myself. I've not used desktop linux extensively; I tried reinstalling Insiders from the on Lubuntu to see if it associated files with VS Code, but that didn't happen.
Verified by installing insiders from on Ubuntu and was able to see mimetype and set a custom icon ! upon uninstalling it was removed.


Repro: terminal with sticky scroll enabled command that "overflows screen" (ie, it scroll terminal beyond what's visible) it once again to again overflow screen (not sure if it needs to be run again, but that's how I repro'ed) screen (ctrl+l) once again & see sticky scroll shown even though not required (also reported with vid and logs in DM to ) Version: 1.85.0-insider Commit: Date: 2023-11-29T02:45:05.413Z Electron: 25.9.6 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin arm64 23.1.0


! !
I think this was the result of moving the progress bar below the input. Since the progress bar use to provide the padding.
let's just call it an exploration of compact mode :) /s
This is partially as designed, but it still needs improvement. The latest changes make it so we have a nice cutoff when the quick pick list is scrolling: <img width="653" alt="CleanShot 2022-12-16 at 09 23 10 src="https://user-"However it should probably still use padding at the bottom of the list, rather than the container, to ensure this doesn't happen when the entire list is visible/not scrollable.
I dont want to be the annoying guy at the party here, but an empty quick pick now looks like this: <img width="647" alt="image" src="https://user-"vs before <img width="633" alt="image" src="https://user-"
Haha, whoops. I'll have another go at this then.
verified the original issue here, but we'll continue the next issue in:


The select box in the panel header should have a white background: ! This is similar to the recent breakage with the simple editor widget background color in SCM and extensions views.
To Verify: to an obvious color. that terminal and output select boxes are using these when they are in their default locations in panel.


<!-- 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. --As mentioned in the thread by there is a need for a tool that would help developers engaged in the VSCode project identify the Trusted Types violations. This can be achieved by adding as a devDependency and an appropriate yarn script.
I have also a task-definition so that tsec errors show in the editor itself. F1 Run Task tsec <img width="1472" alt="Screenshot 2020-09-01 at 13 07 22" src="https://user-"


<!-- 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. --I'd like to have a theme setting that would allow me to change the foreground of the text in red next to the shortcuts. I've reached out to the dev tools and wasn't able to track the setting. I searched Google, SO, ChatGPT and I've tested a bunch of foregrounds and nothing works. <img width="1012" alt="Screenshot 2024-01-10 at 16 21 18" src=""
I a new color . It is derived from the


Currently, we have to add this copyright header manually to every new file: /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ An ES Lint rule that has an auto fix would be really nice. What are your thoughts ! (using )
I like. The closest that we have today is this snippet
Let's do it!


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --when you import a profile file, vscode will create a new profile but not overwrite current one or merge it to current one Actually I don't need so many profiles, the default profile is enough for me. sometimes I just want to import a keybinding settings from some one, and keep my other settings after I import it, WHAT HAPPEND!!!, all my other settings and extension are gone!!! This is unreasonable! what vscode should do is merging(or overwriting) new keybinding to my old one!! <!-- Describe the feature you'd like. --
Can I have a try on this? I'm new to contributing to this repo but want to try out stuff and get along with starting out at the same time..
Edit: Ignore this, I misread this with other issue
Just wondering is not this same as Can you please distinguish your ask from the other?
partially like But I request more flexibility: Suppose current profile is profile X (X can be default or user profile) when I import A profile, that will be: A.keybinding, A.UI, A.extensions ..... and I choose A.keybindings only to import what I expect: there are 2 options for user when importing: option 1 - merge to current profile, (so X profile's keybindings overwritten but other part of settings kept) option 2 - or create a new profile partially basing on what imported (this is what VSCode currently does )
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our . Happy Coding!
?


I would think this is not a good one to start at and recommend to look for issues labelled with or
I really want to try out.. just to experience and I think I would be able to do it. Even if it's not a good first issue I have contributed to other open source repos. Can I?
Sure, here is the starting point
Thanks a lot for this I was checking your PR with the user-profile feature implementation.. For now I'm just figuring out stuff that is already present. Just a single doubt that I had was about the merging of profiles.. would the editor be like a merge editor that opens whenever we get a merge conflict on git..? Or something else with checkboxes on which settings to get imported from each of the sides(current and imported one)? I'll try my best
For the sake of simplicity, during conflicts, I would simply override with the new one.
Also
Note to self: see for manual workaround.
You can now import and replace any existing profile (including Default profile) from new Profiles Editor UI
To verify: Create a profile A and configure with some settings and extensions Export the profile A to the disk Change some settings and extensions in the profile Import the profile A You should be able to import the profile with name A replacing the existing profile
When I export the profile, install some new extensions, then import the profile with the same name, I would expect the installed extensions to disappear from my extensions list, but that doesn't seem to be the case
It is working for me, ie., I only see the extension from the imported profile. After importing, extensions are getting replaced. Can you please share the exact steps to repro?
Using vscode 1.92.2, I can't figure out how to get to that UI. Where do I find it?
search settings for "profiles experimental"
Thank you!


<!-- 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 VS Code Version: main branch () OS Version: any Sorting of suggestions is broken if the CompletionItem uses label details. When is a string, suggestions are sorted by label with ties broken by the completion item kind. But if is a then it is not sorted correctly. Here's the bug: This doesn't work as intended on objects. when and are both objects, these two comparisons BOTH return false and things end up being sorted only by kind. if one label is a string and the other is a , then the string ends up sorted after the no matter what the 's label is. Steps to Reproduce: a that returns something like this: end up sorted d, c, b, a, z but should be a, b, c, d, z
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
fix is to use I think
Thanks This is a nice bug and good find. You did a great investigation, planning to fix this in this milestone but since you already did the lead work I'll happily review a PR from you
<!-- 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!


Open in two different tabs Make sure settings sync is OFF Change the theme in one tab Theme is not updated in other tab


New enum/select box detailed descriptions should be read by reader. Add describedby attribute handling for details provider within selectbox.
Either describedby or just
Yep, I've thought about live/alert also. By my research this does not really match the expected taxonomy for the accessibility tree, an extended description is pretty much exactly what describedby is for. That said, describedby probably will not be happy changing which will mean I will need the static set of descriptions in the Dom. Not a big deal, just another example of where nothing is straightforward. But, that's why we get paid the big bucks ... well at least you :-o ! What I really want to solve is getting rid of the multiple 'clickable' readings. I think I may have a way to avoid that which will be very important for these descriptions given the number of links.
Good point, I have no idea if pointing all of the selectbox items at the same details box will work, or if there's something we can do to order events to make it work better. Or maybe changing the 'id' of the details element for each item. I'm very curious what's causing that! Very weird.
describedby can have a list of IDs associated with it. like labeled by and most other ARIA aspects it does not like things changing underneath it, that of course is what aria-live is for but, but everything I read says use this judiciously. I think having a separate set of descriptions (modified for reader output/minimal clickable) will not be a big deal. Just as the options are static, so are the descriptions so hiding them in the select for use will not be an issue. I haven't done the definitive experiment yet but, I believe the multiple clickable issue has to do with something like this: I think the reader can find these as all clickable elements when they are descendents of a managed accessibility tree. my research has yet to determine if this is considered a bug or as designed


Issue Type: <bBug</bI do not see the error or success icons for the gutter icon on my shell integration enabled terminals; instead it is always the empty circle. The integration appears to otherwise be working (the Go to Recent Directory and Run Recent Command commands are working as expected). I presume that somehow, the integration is not picking up the result of the operation being run. For reference, I am using but otherwise don't believe I have anything special in my Bash configuration that would affect this.


VS Code version: Code 1.68.0 (Universal) (, 2022-06-08T11:44:00.250Z) OS version: Darwin x64 21.5.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (76)</summaryExtensionVersion ------ Bookmarks13.3.0 project-manager12.6.0 vscode-sqlite0.14.1 atlascode2.10.12 github-markdown-preview0.3.0 jsdoc-markdown-highlighting0.0.1 markdown-checkbox0.3.2 markdown-emoji0.2.1 markdown-footnotes0.0.7 markdown-mermaid1.14.0 markdown-preview-github-styles1.0.1 markdown-yaml-preamble0.1.0 gitignore0.7.0 vscode-markdownlint0.47.0 vscode-eslint2.2.2 xml2.5.1 gitlens12.0.7 EditorConfig0.16.4 graphviz-preview1.5.0 flow-for-vscode2.1.0 vscode-mysql0.4.1 copilot1.28.6134 remotehub0.34.0 vscode-pull-request-github0.44.0 go0.33.1 todo-tree0.0.215 triggertaskonsave0.2.17 vscode-guid1.4.20 path-autocomplete1.19.1 tablegenerator1.0.4 plantuml2.17.2 svg1.4.18 docthis0.7.1 vscode-position1.1.2 yarn-lock-syntax0.1.3 Kotlin1.7.1 vscode-language-babel0.0.36 pull-request-quantifier0.1.2 extension-manifest-editor0.1.5 csharp1.25.0 dotnet-interactive-vscode1.0. network-edge-devtools1.0.0 data-workspace-vscode0.2.0 mssql1.14.2 sql-bindings-vscode0.1.0 sql-database-projects-vscode0.16.2 vscode-postgresql0.3.0 python2022.8.0 vscode-pylance2022.6.10 jupyter2022.5.


jupyter-keymap1.0.0 jupyter-renderers1.0.8 hexeditor1.9.6 powershell2022.5.1 remote-repositories0.12.0 vscode-js-profile-flame1.0.2 vsliveshare1.0.5615 vsliveshare-pack0.4.0 resourcemonitor1.0.7 vscode-commons0.0.6 vscode-yaml1.8.0 sass-indented1.5.1 gitconfig2.0.1 mdx0.1.0 codevalet-vscode1.5.0 vcl0.1.2 msbuild-project-tools0.4.3 jest-snapshot-language-support1.1.1 intellicode-api-usage-examples0.1.1 vscodeintellicode1.2.21 vscode-icons11.12.0 quokka-vscode1.0.478 wallaby-vscode1.0.338 jinja0.0.8 ReactSnippets2.4.0 vscode-proto30.5.5 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details


Some info that would help us investigate: Set log level to debug via the command palette, then in Help Developer Tools console it will show some shell integration related logs when you run a command Do you set PROMPT_COMMAND anywhere? Do you use bash-preexec?
I'll get this going and let you know. Ah yes, besides using , I have this in my bash config: I'll try disabling that and see what happens. It would be a shame to lose it but perhaps there's a better way of implementing that so that it's compatible, if that turns out to be the issue. Not that I am aware of, no.
OK, so I disabled my PROMPT_COMMAND change and tried a few things in a new terminal that weren't working before. Now, when I use it is still an empty circle, but when I do , I get the green success lozenge!! So I'm guessing that was the main issue; though I do wonder if I should be seeing that green circle for and such too (that said, this is the non-Insiders build - I'll try Insiders in a second). I'll add the log level and see what I get.
I can confirm that the Insiders build works as advertised now, so it was my history manipulation code that was getting in the way. Thank you for helping out. I'll close this issue as it appears to be an issue on my side, not yours. Thank you for helping troubleshoot.
Let's keep this open to track the issue so we handle it better.
would you like me to gather the logging info as requested, since this is staying open?
I think we understand the problem enough to reproduce it, it's just a case we need to detect and handle better.
This is happening because we actually depend on to differentiate regular commands that succeeded or failed vs ones exited via or running an empty line. Specifically this call: I'll disable shell integration if includes as that specifically is the reason it was failing.
<!-- 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!


To verify: In set Enable the shell integration Open a terminal, it should not have shell integration enabled
/verified I see that the integration is not enabled as the lozenges are missing.


<!-- 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 comments API doesn't have the concept of resolved/unresolved threads, although most code review tools distinguish them. The current API allows us to surface this to the users, see However, this seems pretty limited. I find it difficult to identify all my unresolved comments. It's very easy to miss some of them. If the API had a boolean for unresolved comments, we could surface them in multiple ways: In the Comments panel, surface the number of unresolved comments, similar to what is done with Problems: ! In the Comments panel, highlight the unresolved comments (or put them in bold), so that it's obvious to the user what comments they still have to go through. In the Comments panel, have a way to hide/filter the resolved comments. In the Editor, consider consider using a different background color for unresolved comments. I currently use a different label for unresolved comments, but this is very subtle. In the gutter, use a different symbol for unresolved comments (e.g. or a diamond of another color). In the Editor, provide a way to go to the next unresolved comment (an alternative to ).
Let's discuss the API change. IMO, the information should be part of a . On many levels, Comments seem similar to s. A diagnostic is a comment provided by a tool such as a compiler. A comment is typically provided by a human. Diagnostics have a severity field, which indicates how important is the problem. We need an equivalent for Comments, something that tells the user if an action is expected (e.g. they need to resolve it) or not. Once the user addresses the comment, the importance is reduced. simplistic solution is to add a boolean, e.g. . to , we can go for a two-state enum instead: to be more general: . We might consider having more fields here. In a code review, multiple users interact with the comments. The current VSCode user is not necessarily the person who needs to do something. For example, the user has just updated the comment and they wait for a response.


So the third value could be used to mean "it's not my turn" or "acknowledged, I'll come back later". The benefit is that the user can use the list of "unresolved" issues as a TODO-list and publish the comments once it's empty.
Thank you very much for your proposal. and me have quickly discussed this and we believe this proposal makes good sense. We plan to start looking into it next milestone. Though no promises yet when this will land, we will know more in December when we start our investigation.
All of the proposals in have merit. In a perfect world I would choose one of options 2 or 4; however, we have users of the comments API who's comments don't have a resolved/unresolved state. Option 3 circumvents that, but then we have the issue of what to show in the UI: a GitHub PR comment isn't high or low priority. Another proposal, similar to how comment reactions work:
I see than left comments on the commit (). I like the approach of having an object for the state (instead of the proposed boolean/enum), it gives more flexibility and lets user create their own states. In my proposal, the information was attached to a thread, not to a single comment. Do we have use-cases where we want this information per comment? We might also want to control the gutter icon:
GitHub comments are resolved per-thread, so no, no cases were we want it per comment. I'll move it to the thread.
After much discussion, we have decided to proceed with the following: The main reasoning behind this is that resolved vs. unresolved comments should look the same to the user across a GitHub PR extension, an Azure Dev Ops PR extensions, and any other PR extension. There original concern around using "resolved" and "unresolved" is that maybe not all comment provider have those states (maybe they have "viewed" and "unviewed" states for example). To alleviate this, we'll see if we can avoid using "resolved"/"unresolved" language in the UI. If additional states are needed later, we can always add more to the API.
I have a basic implementation of this working, with and themable colors. Before I finish up the pull request to send it out, I was wondering what the best practice is for providing defaults for these colors?


In the mocks from we use a yellow for unresolved comments that is inspired by visuals of our internal tool. I am not sure if they match an established VS Code palette.
awesome, looking forward to reviewing it! Generally, we try to avoid introducing a new color entirely for something like this. The best practice would be to look through the existing color values where we use yellow then use the same yellow, just like is done here where uses the same color as : We'll also do a UX review of this, so the color may end up changing anyway.
I went for new colors as the comments are conceptually something different than e.g. editor warnings. Currently the comments in the editor use (default blue), so a theme, an extension, or the users themselves would not be able to style comments independently of peek views. I think it makes sense to base the default on another color like as in your example, so that themes which omit the new colors receive a reasonable default, but it seems like we would give up a lot of flexibility and also clarity if comment widget colors directly used something like internally?
Yes, basing the color on another is what I meant! I agree that we don't want to directly use another theme color.
If anyone is eager for this API to be finalized then please comment and let me know how it's working for you. Otherwise, I will plan to finalize later in 2022.
This would be very nice to have. We are using Github and especially larger PRs are hard to manage, if there are many comments (in Github as well as in VSCode)
So is there currently a way to filter resolved/unresolved comments in the sidebar? If not what can I modify currently to provide a visual distinction between resolved/unresolved?
there's a color difference on the icon, but that's currently it. This is the feature request you're looking for


<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.33.1 OS Version: Windows_NT x64 10.0. Steps to Reproduce: a new user snippet file for the project. The one I encounter the issue with is: the snippet and attempt to press TAB after writing the first variable cursor does not move to the next stop, instead a tab character is The desired behavior would be for the cursor to move to the next tab stop. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Seems to work just fine for me... Any special keybinding or setting? !
The action you took is not the problem I encounter and does indeed work the same way for me. Could you try to edit "SystemName", the first tab stop, then press TAB to go to "Required Components"? vsCode just inserts a tab character after whatever I wrote instead of going to the next tab stop.
Ok, thanks for clarifying. For some reason snippet mode stops when making that edit... Not sure why
I have encountered similar issue, however, I could add a single blank space in the snippet which "fixed" the tab navigation. Also, my example is far simpler. See
This is a regression from I will revert that change and re-open the corresponding issue (which is much more rare than these issues)
Thank you for fixing this, looking forward to the next release.


Version: 1.68.0-insider Commit: Date: 2022-06-02T05:17:01.962Z open the Settings JSON editor add some unnecessary commas no problems reported in the problems view. open the JSON Language Server log. Observe that there are no diagnostic requests. Other requests are sent and completed, so the language server is running.
Maybe unrelated: I was expecting "trailing comma" warnings in (we recently changed the schema to not accept them), but they only started showing after I flushed the schema cache (using the UI command) and reloaded the window (I can't completely rule out that a window reload alone would have helped).
I checked that with the fix the trailing commas are reported


Maybe you've already thought about this but it would be useful to be able to create a new folder in the simplified file dialog. This could be a button in the title bar or a confirmation step when a folder that doesn't exist was typed. Creating a folder and opening it, and creating a folder and saving a file in it, are common workflows so it would be useful to be able to do those in one step.
For the meantime:
Hey thanks for the mention! This was a feature I personally needed for quite some time - we all basically do those steps mentioned by on a daily basis so I decided to code an extension for it. Even though the extension already works great, I am actually working on it right now and adding a new feature which will allow it to create new folders using the Simple file dialogs - regardless of user setting, see . If anyone's interested, I think I'll manage to finish it by tomorrow.
I've been busy with work and other projects but after a long wait, I worked really hard and managed to finish my npm module for Visual Studio Code that implements the aforementioned behavior and shows a custom QuickPick that allows browsing and creating folders from the Command Palette, even nested/recursive folders. The extension that implements this package is available at repo. Not perfect (yet) but it works.
Also create new file in Open File dialog would be useful.
Saving is good. Opening hasn't been implemented -- should there be a new issue for that?


Testing settings UI for " fontsize" "Show matching extensions" blue button no it - no effect fyi !
It shouldn't show up when the filter is present, I guess


Testing an editor and write something in it. tab until you reach the terminal. Type something in the terminal. . Realize that tab is correctly not moving focus in the terminal. command "Toggle Tab Key Moves Focus" out of the terminal and keep tabbing until you get back to your editor. something in the editor. again until you reach the terminal. something in the terminal. to tab out of the terminal. It looks like tab moves focus as toggled itself off. Tab moves focus seems to be off for both terminal and editor at this point until reload.
I can also cause similar behavior if I flip the settings.
what is supposed to happen now? What I think I expect to happen (and isn't happening): If I run "Toggle tab key moves focus" while in a place where it doesn't move focus via setting, then it now globally moves focus. If I run "Toggle tab key moves focus" while in a place where it does move focus, then it now globally does not move focus. However, I'm not a "tab moves focus" user, so maybe my expectations are bogus.
Thank you for testing. Those expectations are correct, except that the toggling does not apply globally - it is per area. So, if I have in settings: terminal tab focus mode: on editor tab focus mode: off where: = status bar indicator = no status bar indicator focus the terminal focus the editor focus the terminal and toggle it off focus the editor and toggle it on focus the terminal focus the editor reload the window and focus the terminal focus the editor I see that this is not working atm because I'm not reacting to configuration changes
fyi for easier testing since the command palette can cause the terminal to no longer be focused, I'd suggest using the keybinding to toggle tab focus mode


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.85.1 OS Version: Alpine 3.19 Steps to Reproduce: More info and fix in new version :


<!-- 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.66.0 OS: MacOS Monterey 12.3, Darwin x64 21.4.0 Steps to Reproduce: new new markdown cell, name it for instance or will only show and have deleted the 1) or 1. written manually
cc -- It looks like this is being sanitized out of md strings. A markdown cell containing will be sanitized to render as . If the cell contains it will render as expected, only removing the html tags. It seems to be happening at the following:


As a result of the discussion in , we should format each command, description, and keybinding more consistently and limit redundancy.
/closedWith though still need to do the same for the chat help dialogs


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.51.1 / 1.52.0-insider OS Version: Ubuntu 20.04 / Windows 10 Steps to Reproduce: 4x spaces at the beginning of a line multiple cursors on that line enter Expected: Insert newline at each of the positions where cursor is present Actual Behavior: Inserts newline only at the first (NOT the left most) cursor position (Let me know the relevant settings values required) Addiditional info: I use tabs (width of 4 spaces) for indentation for formatting ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
I think this might be caused by one of your installed extensions. Here it is on my machine: ! To validate this, could you please : Run the command Developer: Toggle Keyboard Shortcuts Troubleshooting This will activate logging of dispatched keyboard shortcuts and will open an output panel with the corresponding log file. You can then press <kbdEnter</kbdand check what command is invoked. If you are having trouble understanding the output, please feel free to paste here and I can help decipher it for you.
Here is the renderer keyboard troubleshoot log: Also, the I have disabled all the extensions. And, now, I can reproduce this with the latest stable too and in Ubuntu.
It is also not exclusive to the multi cursors created using keybinding. I can reproduce this by placing mulitple cursors created using the too.
From the keyboard log, I can confirm that nobody is "stealing" Enter via keybindings. But there is another way that extensions can intercept that, via our command. That is the way in which intercepts Enter. Does this reproduce when disabling all extensions? Press and then choose !
Hey , In all of my previuos posts I have made sure that I have disabled all the extensions (by running the command that you have mentioned) and also, at the end of each of my posts I have explicitly stated that I had disabled the extensions. Can it have anything to do with my settings related to tabs?


May be, inspect my settings here: (which has ) and, try to reproduce the issue by applying the exact same settings (copy paste my ).
Also, , Please carefully go through each of the above posts. It seems like you are not reading all the comments. It will save me from repeating the same thing again and again. Thanks.
Thank you for your patience, with your settings, I could finally reproduce. I missed the fact that the editor is configured to use tabs and I believed you might be using vim due to the block cursor in the GIF. You can workaround by using .


Feature Request The command takes an extension argument so that extensions can open an issue reporter for that extension. I'd like to use this for the built-in JS/TS extension as well but cannot at the moment: It'd be nice if for VS Code builtin extensions, we automatically changed the field to
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!


I was trying to understand the usage of and the lifecycle of actions created while creating it. I think this originated with the terminal, so looked at the terminal code, but it seems like the problem isn't solved here either. instantiates some Actions which extend Disposable, but they are never tracked or disposed. The ActionViewItems returned from are apparently owned by whatever calls that and get disposed, but not these extra actions that we have to create. So, one solution would be for them to be owned and disposed by although that feels unexpected. But otherwise, there isn't a technically correct way for the code in to know when they should be disposed. Wondering whether I'm missing something or if you have any thoughts.
I spent some time investigating this and the issue is that we use in some places and in others. Only the latter is disposable. This would be a bit involved to rework


VSCode Version: 1.1.1 OS Version: Windows 7 x64 It would be great if holding the key + spinning the mouse wheel would increase / decrease the VS Code zoom value.
I am not sure we want to zoom the entire UI when you use the mousewhell, I would expect only the editor font to increase. Thereby moving to
yes you are correct.
Didn't this feature used to work, or am I just failing to remember correctly? I was just going to report this as a bug, but maybe it never actually worked. I jump between different computer setups fairly regularly, so maybe I am just not remembering. Anyway, I found this dupe, and didn't want to submit a new issue. Thanks for your efforts By the way, I think I would expect this feature to work the same way that and work. VSCode's UI deviates from many other UIs in that it scales well, so I think I'd expect this to scale the entire UI consistently with the keyboard commands.
If this zooms only the editor, shouldn't it be seperate from ?
I would expect and to zoom only the editor. That behaviour would be consistent with most (all?) other editors and apps. Scaling the entire interface is an accessibility feature IMO, so maybe it doesn't need to use such a commonly used shortcut by default? Beyond Ctrl+Wheel, pinch to zoom should also zoom the editor.
Can this be disabled? I'm constantly accidentally zooming my text to a tiny size when I ctrl-click and accidentally brush my fingers over the trackpad.
This is disabled by default, so you must have enabled it in the past --
Thanks - I came here to vote for this feature, and it turns out I just had to turn it on! Shouldn't this issue be closed?
:+1: Closing since this is implemented. The feature is disabled by default due to numerous issues reported by users using touchpads where we begin to unexpectedly zoom in/zoom out when e.g. using ballistic scrolling and pressing the ctrl/cmd modifier. The root problem is that we cannot differentiate events coming in from a real mouse with a wheel from those coming in from touchpads / trackpads.


<!-- 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.90.1 x64 OS Version: Ubuntu 24.04 (Updates 14 Jun 2024) I get the error on a fresh installation of Ubuntu 24.04 and VSCode 1.90.1 Everything works fine with VSCode version . Steps to Reproduce: latest version of Ubuntu 24.04. command. command.
In my case the issue occurred when doing , also on Ubuntu (20.04) and also on vscode 1.90.1 Here is a temp workaround to revert to vscode 1.89.1, if that's useful to anyone:
Hi Having same issue on remote VM Ubuntu 20.04 Install errors with Solved by using the flag


This is a continuation of to implement a proper fix in the runtime or application as necessary. Known data points: SIGTRAP when gpu tried to access resource bundle to load a label for assigning display name when computing vsync interval using the internal implementation rather than the gl extension. Also name from resource bundle is only requested for builtin-displays and not virtual ;l=449-456 Using gpu codepath from main process serves as a workaround. Debian package on the same system didn't trigger the crash codepath, very likely a different gl backend was used. Next steps: 1) Compare gl initialization trace between snap 1.89 and 1.90, using the following categories 2) Compare gl initialization trace between debian 1.90 and snap 1.90 3) Confirm if resource bundle access from gpu process is necessary moving forward.
This turned out to be a regression from https://chromium- which causes the gpu process when using the software display compositor to reach into the resource bundle. Before the CL, gpu process will not call into only the main process did.
is there something to verify here?
This is related to the candidate issue and I was just using it to track fixes. Nothing particular to verify for this particular issue, maybe confirm the checksums for both branches are same vs


Ideas to experiment with: Don't shrink a cell while it is executing -less jumpy as output is replaced change the anchor heuristic from "if the resizing cell is partially visible" to "if the cell's output will shrink out of view" Anchor to a focused cell if the focus is in the cell's editor cc
For the new heuristics we are adding (growing upwards or downwards), they should probably be interrupted the moment users start to scroll, for example, if I scroll manually to a specific position, I would expect the scroll top not to change.
I disagree - That could mean if you have a cell focused and anchored, and you scroll to get it higher in the view, it would then start getting pushed down as the previous cell grows.
If I scroll to get it lower in the view, as I want to read the cells above, and since it's still in the view and focused/anchored, the cells I was reading will then pushed upwards, right? This feels unnatural compared to how browser handles scrolling or Terminal. Terminal scenario might be closer to this, as it usually sticks to the bottom when the shell is streaming outputs, but the very moment we scroll upwards, it stops sticking to the bottom.


Select a portion of a variable name Press F2 Previously, the rename widget would open with the same substring highlighted. It's helpful to quickly rename one subword in a variable name, for example. Now, the full contents of the input in the rename widget are highlighted initially. I don't know who owns this but it looks like you touched it recently
<!-- 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!


Issue Type: <bBug</bLike what the heading says, inserting a code snippet anywhere in the code file causes an autoscroll. This is a slight inconvenience, as while inserting snippets, viewing code above it is desirable, causing us to rescroll into view. So adding an option to revert to the functionality in the stable release would be preferred VS Code version: Code - Insiders 1.46.0-insider (, 2020-05-07T16:36:39.681Z) OS version: Linux x64 5.4.38-1-MANJARO <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ cpptools0.27.1 Go0.14.1 material-icon-theme4.1.0 material-theme3.5.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Yeah - that's a regression from a recent change to keep the position stable when additional edits are inserted...
is the item that caused this regression.
fixed via
Yep, it works fine now. Thanks a lot!
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


This is somewhat the opposite of and the acknowledgement that computing additional text edits for all items upfront is too demanding. This issue is only about and the goal is a pragmatic solution, similar to the one that we have for . Idea accept an unresolved completion proceed with insertion as usual set up a content change listener resolve the items once resolved check if additional edits overlap with "concurrent" changes. when they overlap, do nothing otherwise proceed
The first version for this is now merged to master, it's a pragmatic approach that's better then not resolving but worst than (costly) upfront resolving. Items to followup on [ ] telemetry and follow up issues [ ] - TS issue for having incomplete items [ ] [ ] java for returning very few (resolved) completions, e.g doing the right thing
/cc - My understanding is that Java resolves all items upfront, e.g compute additional text edits during "provide", and that it is quite expensive and therefore Java only returns a small amount of items. Is that correct? Could Java return results faster when additional text edits are computed during resolve (and therefore only for selected items)?
Yes. I think so! is the dev who was working on Java completion. I believe he can provide more insights toward this topic. // cc
this is exactly the behavior that used to have, ie compute all the completion items first (fast), then the text edits were computed during resolveCompletion. We were asked to not do that as and changed to return a small subset of completion items (with incomplete=true), with full text edits computed upfront. The user experience is definitely not as good as with our initial implementation.
To be clear, computing any Java textedit upfront is costly when returning 100+ items (and we can return several thousands items). We'd prefer if the async insertion of textedits covered all textedits, not just the additional ones.
The requirements discussed in are still true and there are no plans to change that. There is (which might be derived from ) and . The former () is inserted at the cursor and must be inserted synchronous to accepting a completion (we cannot block typing while waiting for that). The latter () is meant for things like import-statements and we now want to relax that, e.g it can come late and we try to apply those edits despite the user having typed more.


When exactly does run, is it only when an item gets highlighted in the menu? Can't tell from the docs. I only need to generate for the completion item the user ends up applying -- doing it for other items is unnecessary work that's bogging down the extension host, and I will have to implement yielding. I assume no one would need to generate before a completion item is applied? Is there any kind of completion applied event we can hook into to work around this for the time being?
That's exactly what is about . Today, there is no guarantee that is ever called because its original design is to provide data for the suggest details widget. However, we see that (amongst other things) are computed during resolve and leads to subtle bugs (because don't always call resolve or always await it) Well, is the problem if you do not generate them upfront. select suggestion synchronously inserts the string starts for additional text edits continues to type quickly and all over the place -call eventually returns but it is unclear if the edits are still valid because the state changed many types in-between Solutions: Won't work because in JS you cannot wait for another "thread" or "process", the world always keeps turning Implement a full -solution because this is two entities "typing" concurrently in the same document. However, it will feel awkward because the user doesn't expect to be such a scenario. approach that tries to apply additional edits if possible but inserts the "main edit" (insertText) always synchronously. () "if possible" is currently defined as "no edit has occurred before the first additional edit". That works well if you use additional edits for things like imports or prefixes (which is the indented use-case) but won't work if additional text edits change the main edit, like appending a call-operators with arguments etc
I mean JS can't block but ignoring typing while awaiting is possible -- I was imagining that VSCode would keep the completions menu open and ignore any typing until is resolved and all text edits applied for the accepted item. Obviously this would be bad if resolving takes a long time, but the API has cancelation tokens already, so the UI would just need to show a spinner/cancel icon, and also cancel if the user presses ESC or navigates to a different editor, for a decent UX.


I think this would be less confusing for users too; it's the only way it would be clear when VSCode is completely done applying the completion. I think many users would be confused if imports usually get but not when they resume typing too soon. FWIW I can syncronously generate the additional text edits I need, so I'd be happy if there were an API to synchronously generate them when the completion item is accepted. I know not everyone would be able to generate them sync though.
Also I know my questions may have seemed redundant, but I hadn't seen anyone on this thread point out that it would be ideal to avoid ever computing additional text edits (or even the primary insert text) for unselected completions. Since can get called before any item is accepted (I assume, since it seems to be for showing additional details in the menu), I'd think any solution via could still result in unnecessarily generating additional edits that are ultimately discarded.
The golden rule is that "you can always type inside the editor". Ignoring typing is not a good solution and will bug users. Just think of quick suggest and auto accept characters - you don't want the editor to stop typing just because an extension is taking a little longer (+50ms). To be precise you should have written "typing at or before the offset at which additional edits are going to happen" I honestly think the majority can generate them synchronously but this happens in the extension host process or the language server process, and all of that might happen on a different machine and there is no way to synchronously transport that into the UI.
re with the current changes you should be able to have a "simple insert text", say , and compute an additional text edit, like , that goes in front of it so that you eventually have . Right? Or am I missing something?
that might actually be a good idea ;-) In practice though, we might need to revisit the way the principal TextEdit is computed (i.e rewrite a bunch of stuff from upstream JDT)
I get the desire to be able to always be able to type inside the editor and agree that's an important principle. The only reason I think this case is an exception is that: The user would probably want to wait for all edits to get applied anyway.


Seems unlikely that people would want to get the main edit without the additional edits By making the operation cancelable, you can still go back to typing immediately if you so desire. I certainly wouldn't want to block the user from typing without recourse (as you know, I feel frustrated that happens currently when using Vim extensions) On the other hand, I guess it's unlikely that the additional text edits would overlap whatever the user continues typing...
I hadn't thought about auto accept characters though, that's a good point. That's something I don't have experience with. Also considering that VSCode could pop up a warning if it has to bail on inserting additional edits, it's not a big deal if it ever happens
I remember that we have some new data points regarding the time consumption in different stages of code completion in Can you share that data and see how we can tune it with this change?
For Java language server, below is a sample of call tree when triggering completion. (time value is larger than expected because of extra overhead from JProfiler) ! Total time of completion stage mainly consists of three parts: competion candidates in JDT to CompletionItems (calc textEdits, additionalTextEdits, etc.) --- calc an incomplete list of only 50 items by default (the full list can contain thousands) --- here calculating import statements costs a lot of time server-side code snippets (not much related to this topic) I did a simple experiment on java language server, with vscode-insider built on 2020-5-15. I was using spring-petclinic, which is not a big one, but with some dependencies. Type a initial letter, e.g. "O", and observe perf of completion and resolve. Do multiple times for statistics. Calculating additionalTextEdits async in resolve stage does decrease the time cost a lot. textEdits and additionalTextEdits are calculated during completion stage. completion: ~150 ms resolve(avg of top 10 items): ~10 ms Now I simply move a bunch of textedit calculation from "completion" stage into "resolve" stage. completion: ~100 ms resolve(avg of top 10 items): ~17 ms !
I just realized that can return a thenable, but I assume that would delay the appearance of the entire menu?
Closing as we haven't seen issues with the new pragmatic approach and the plan is to stick with it.


so how do servers know that clients support lazy-loading of additional textedits? Surely this should be a client capability advertised by vscode (that needs to be specced in the LSP)
is the right person for that and you should probably create a follow up issue in the LSP land
corresponding LSP feature request created here please add more details if I miss anything.
Thanks
To verify: use TypeScript have a suggestion that will import a symbol make sure that suggestion isn't first or focused in the UI use the mouse(!) to select the suggestion make sure the import is there make sure undo, redo works as expected


Type: <bBug</bDelete a notebook file in a git repo Open it from the SCM view It's editable ;( VS Code version: Code - Insiders 1.94.0-insider (Universal) (, 2024-09-11T05:04:03.124Z) OS version: Darwin arm64 23.6.0 Modes: <!-- generated by issue reporter --
Fixed by


I've had an SSH window open in the background and noticed that it keeps going through reconnection. Looking at the logs, it looks like vscode is often triggering reconnection, even though nothing strange is going on with my network, as far as I know. Noticed this at home and also the office network. This is the log from vscode. The SSH log doesn't show anything unusual before the resolver is invoked again. Has anything changed here lately?
Sorry this issue fell through the cracks. Are you still running into this?
Yes
Do you perhaps have a log with tracing enabled? The reason in the original log appears to be timeout. That is triggered here -- So the conditions are: a message was written to the socket 20 seconds ago and the server side didn't acknowledge it (and) no data was received from the server within the past 20 seconds (and) no previous timeout event was fired within the past 20 seconds (this just avoid sending many timeout events) (and) the renderer process appears responsive (Just speculating) I think we have fixed something in the terminal land and we now no longer send any data in an idle window. Could it be that your window becomes idle and the connection is dropped by SSH? (I believe due to some terminal heartbeat mechanism there was always data being written every 5 seconds, but now that is no longer happening).
Well, now I can't repro it.
I've more logging via . Please keep an eye out. In case you hit this again, the logging will have more data.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Finally got it
It seems like the log message you touch didn't show up there. But, it does show up in an earlier reconnection in this window (before I enabled trace logging). So I'll just share the full logs This shows a window that was mostly idle with 2 reconnections, the second one had logging at the trace level enabled
Here's my interpretation: the management connection timed out at due to our own timeout logic. We wrote one message and that message didn't get acknowledged within 20s by the server. As an observation, the connection didn't receive any bytes from the server within 320s (5 minutes).


this resulted in the core invoking on the SSH extension and the SSH extension replied with a new port i.e. instead of the previous . the extension host connection immediately closed at with code , indicating that perhaps the previous tunnel at was killed as part of invoking . Precisely 20 minutes later, at , both management and extension host connections receive a event from Chromium. I can't quite explain the first timeout, why would the server not acknowledge a message within 20 seconds? But the timing of the second disconnection seems to indicate to me that after 20 min of idleness, the underlying connection is closed. Anyone could be closing it: either on the client side by Chromium or the OS, either on the server side by nodejs or the OS, either by the SSH tunnel timing out. For the second disconnection I think we might need to do something to tackle . For a long time the terminal was doing a heartbeat mechanism which resulted in data being sent over the wire (and that would not make the connection idle), but that was fixed via Right now, if you are really idle in a window, the underlying connection will be idle too and I think the OS or someone closes it as idle after 20 minutes.
My best guess is some other weird optimization where network requests don't even get delivered when an app is in the background. I've noticed this in windows that are not focused
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!


<!-- 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. --We already have this feature in Core: where you can return where . Truth be told, this already works in API today though it's not officially a part of the API today (so it could change at any moment). For example, I can do: <img width="738" alt="image" src="https://user-"with it goes from: to it goes from: to
ref
Created a TPI so moving this to April for Finalization.


Currently, the editor does not support customizing file labels in a way that would allow filenames to be prefixed with the name of the application or folder from the start of the path. This limitation affects projects structured in a monorepo setup, particularly when files are deeply nested within application-specific directories. Supporting negative indices for could solve this problem. This would enable accessing folder names starting from the beginning of the path. Implementing negative indices would cater to the needs of projects with files at various nesting levels within their structure.
Is the reasoning not the other way round or am I misunderstanding how it currently works? E.g. I'd like to access last 2 parts of the path, but the description of the settings suggests that only the single final and the starting folders can be accessed.
For the following path you will get the following values: Path: : : : : With negative indices: : : :
Here is an example of the mono repo: It has a root and multiple projects in the folder. It is common to make changes in multiple "packages" at once, and it would be convenient if we could identify files by the . Example: -
Verification steps: a custom editor label. The template should include , for which is a negative number. For example, add in , item: value: a file which matches the pattern specified in step 1. For the example specified in step 1: every file matches the pattern editor tab should have set the correct folder name for . Here an explanation on how negative indices work: For the example specified in step 1: the name of the editor in the tab should start with the top level folder the file is located in. In the vscode repo the file would have the custom name
I have followed the steps for the verification and the settings file is renamed to . The TS files are renamed correctly to . Is this expected?


On Safari/Codespace Open a notebook Open settings Switch to notebook Press enter https://user-


a JS file: to definition on Bug I see this scary notification: <img width="671" alt="Screen Shot 2022-07-26 at 2 31 10 PM" src="https://user-"In this case, the user was likely just trying to view the file Would it be possible to either: show this notification when saving? open these file as ?
This came in via from and I think is not good. This also reminds me that when debugging you may end up in a file from the installation dir. I think we should probably revert the change for now and think about a better solution unless there are objections.
I agree. Maybe pursue your earlier suggestion of opening all installation directory files in readonly mode. Perhaps combine with a scary warning if you save a new file in there.


We very likely do not need to ship all of this in the web bits: This was already once done before in , and when dependencies got renamed this was once again forgotten about.


Issue Type: <bBug</bdeveloper tools themes Everything appears to work as normal, but the console gets flooded with errors. VS Code version: Code - Insiders 1.36.0-insider (, 2019-06-14T10:36:51.530Z) OS version: Darwin x64 18.6.0 <details<summarySystem Info</summary </details<details<summaryExtensions (13)</summaryExtensionVersion ------ vscode-eslint1.9.0 gitlens9.8.2 vsc-material-theme2.9.0 remote-containers0.61.0 remote-ssh-edit-nightly2019.6. remote-ssh-explorer-nightly2019.6. remote-ssh-nightly2019.6. vscode-typescript-tslint-plugin1.1.0 debugger-for-chrome4.11.3 vscode-docker0.6.2 material-icon-theme3.8.0 polacode0.3.2 vscode-sort-json1.13.0 </details<!-- generated by issue reporter --
I can't repo this. Which developer tools and theme are you talking about specifically?
I tried repoing this again and it appears that this error is related to installing a new theme. Here are some better repo steps: developer tools themes (no errors) a theme themes (errors even if it is one of the themes shipped with VS code) The errors go away after a reload, but installing a theme does not tell me a reload is required.
Ok, with the extensions view open, I sometimes see Does not cause seem to cause any actual problems
I get that as well sometimes, but do you not get the webview must be attached to the DOM error as well?
I can reproduce it. Steps: on any extension to load it's Readme in an editor that editor theme (this triggers the webview error) step 1 (this triggers the guestInstanceId error)


Issue Type: <bBug</bkeyboard shortcuts for "npm.packageManager" ! VS Code version: Code - Insiders 1.62.0-insider (, 2021-10-11T05:16:36.885Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (26)</summaryExtensionVersion ------ vscode-javascript-repl0.7.2 Bookmarks13.2.2 gitlens11.6.1 copilot-nightly1.5.3048 remotehub0.15.0 rest-client0.24.5 monkey-patch0.1.15 search-node-modules1.3.0 vscode-docker1.17.0 vscode-edge-devtools1.3.1 remote-containers0.202.1 remote-ssh-edit-nightly2021.10.5220 remote-ssh-nightly2021.10.5220 remote-wsl0.58.2 hexeditor1.8.2 js-debug-nightly2021.10.817 vscode-typescript-next4.5. debugger-for-edge1.0.15 vetur0.34.1 explorer-exclude-vscode-extension1.2.0 reveal1.2.7 luna-paint0.10.0 vscode-icons11.6.0 cloudmusic9.2.4 markdown-all-in-one3.4.0 material-theme3.13.2 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


We have the ability to select which branch to push to in the source control, could we please have a pull from option? To target specific branches. Unless it exists already? I have only recently started using VS Code and i love it!
This is an easy contribution, care to submit a PR? PS: You currently have the ability to select which remote to push to, not which branch.
I'll take on this. Is it correct that branch names are not stored anywhere? I've checked in and cannot find anywhere they could be stored. If there is nothing, I'll just take a user input using showInputBox.
I created a pull request for this: Please take a look when you have the chance.
merge conflict is fixed.
Merging with


VS Code 1.46 start VS Code Stable use this launch config: close "" editor run it Observe: (everything is good) <img width="749" alt="2020-06-1609-34-37" src="https://user-"- shutdown VS Code open same project with VS Code Insiders (or any other editor) modify "" and include argument "1234" between "hello" and "world" shutdown VS Code Insiders launch VS Code Stable again go to debug view and run "echo args" launch config open Observe: <img width="1080" alt="2020-06-1609-39-11" src="https://user-"VS Code runs old launch config which lacks the "1234". Workaround: an edit change of is needed before VS Code will run the correct launch config.
We no longer store the configuration in storage. The only downside is that now when you select a dynamic configuration, reload, we do not preserve the dynamic configuratoin and you have to select it again. For that we would have to store the "origin" as you suggested, but that I will tackle as a seperate issue, thus reopening
I've verified that no stale launch configs are run.


is used in the inline chat widget to accept a suggestion is used in the accessible view to accept an inline completion suggestion There is no keybinding to insert the current chat code block suggestion at the current cursor location is used to submit a comment from within a comment widget suggested aligning these. what do you think of adding a default keybinding of for inserting the current chat code block at the current cursor location? I will change the inline completion suggestion acceptance in the accessible view to .
-- Did you mean ? I think can be used for submission. There is no issue with this key. Submitting pull request, for example, is also . However, when Accepting something, we may want to use for the consistency.
I was suggesting we align all of these to use rather than .
I don't think people will be in favor of to accept in the inline chat widget as that would break muscle memory.
-- FYI, the following keybinding is also :
I've refined the original content of this issue to reflect the ask. We shall see what people say.
Here is my summary: for submitting actions. Evidence: GitHub Pull Request uses this keybinding. Also, "Report Issue" under Help menu also adopts as its default keybinding for submitting issue content. for accepting or inserting suggestions. Evidence: already uses this keybinding. Also, Accessible View adapted this for accepting the current inline suggestion.
I think that's not a good keybinding and that Ctrl+Enter is way better because it's easier to reach, e.g on a DE/CH keyboard you need to press Shift+7 to get /
I am then not against unifying all the listed keybindings in favor of .
To verify: Focus an editor Enable screen reader mode Focus a chat code block Use and verify that the code is inserted in the editor at the current cursor position


<!-- 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: OS Version: Steps to Reproduce: up a keybinding to launch quick text search a diff editor some text quick text search Nothing in input: ! Expected: !
Hi , I guess the PR has fixed this already. I tried reproducing it locally with the changes of my current PR, and it seems to be working fine. Attaching the screen recording for your reference.
You need to open a diff editor. For example: open a folder that is a git repo Make a change in any file Go to the source control viewlet and click on the changed file: <img width="1679" alt="Screenshot 2023-10-08 at 2 57 57 PM" src=""Select text in the right editor The bug appears.
Got it, will try to correct it
Hi , I understand that you must be busy. Can you take a look any time you are available? I need some help in figuring out where exactly the diff editor is interacting with search bindings. For example, I am not able to understand how hitting cmd+f calls the search function from the diff, or where it is getting called from. Similarly for the quickTextSearch, can you point me in the right direction?
I was looking for code pointers and ended up finding the bug anyways:


Version: 1.94.0-insider Commit: Date: 2024-09-23T05:12:01.964Z Electron: 30.5.0 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 Steps to Reproduce: a very long line. Google IME for Japanese. at the last of the long line. position of the IME widget is not optimal. ! With , it is worse. !
Hi yes thanks a lot for opening this valuable issue. This is happening because we use the model ranges instead of the view ranges in the control bounds, selection bounds and character bounds positioning. The following PR fixes this:
I try the OSS version from the repository. The issue with is fixed. However, I still see the issue with Version: 1.94.0 Commit: Date: Unknown Electron: 30.5.1 ElectronBuildId: undefined Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 a very long line. Google IME for Japanese. at the last of the long line. position of the IME widget is not optimal. !
Oh I see thanks for letting me know that is curious. I will reopen the issue and have a look.
After investigating the issue, I believe this happens because I didn't remove the editor scroll left position from the bounds set for the selection and character bounds. The following PR should fix this.


<!-- 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. --I'm currently implementing hit conditions in vscode-php-debug. Xdebug has very limited conditions it supports and we need to signal the user if they typed something unsupported. If a breakpoint has such a condition we try to return that in the field in the setBreakpointResponse/body/breakpoints. There is the implementation line: I noticed that the message is only visible when hovering with the mouse over the unverified breakpoint and only when the DAP isn't in a running state. If the adapter is in a breakpoint, there is no indication why this breakpoint isn't valid. Steps to Reproduce: and build vscode-php-debug from branch . a PHP debug Optionally add under setting. a breakpoint with hit condition "blabla". breakpoint should be unverified, hovering over it should show the message. Messages exchanged until now: launchResponse initializedEvent setBreakpointsRequest (see full message below) setBreakpointsResponse setFunctionBreakpointsRequest setFunctionBreakpointsResponse setExceptionBreakpointsRequest setExceptionBreakpointsResponse configurationDoneRequest configurationDoneResponse threadsRequest threadsResponse () a PHP process that will cause the debug adapter to move into running state. Following messages will be exchanged: ThreadEvent () StoppedEvent () threadsRequest threadsResponse () stackTraceRequest stackTraceResponse threadsRequest threadsResponse () scopesRequest scopesResponse variablesRequest variablesResponse this point hovering over the unverified breakpoint will not show the message.


Full breakpoint messages Version: 1.59.0 (user setup) Commit: Date: 2021-08-04T23:13:12.822Z Electron: 13.1.7 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: Windows_NT x64 10.0. Full log of message exchange (DAP and Xdebug)
Maybe a good issue to get introduced to the breakpoint message computation. Thus assigning to Code pointer where we compute breakpoint messages There is probably some check wrong depending on the debug state.
Any luck looking into this? I just want to check if there is something I did wrong before releasing. Btw: Is there any way to enable DAP logging of node/typescript adapter so I can compare messages?
we just did not have a chance to look into this yet. will probably look into it soon, if he is busy I can also help. Yes, it is possible to enable DAP logging for js-debug. Add to your and start debugging. The location of the log file on your disk will be written to the Debug Console. That log file should have the communication.
I totally lost this one, and it's fairly straightforward. This is due to us disabling editor hover in favor of the custom debug hover.
<!-- 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!


Steps to Reproduce: recently opened ("Clear Editor History") quick open and search for a file (such as a TS file) to see symbols (notice how the file opens in the background) to a symbol = when you open quick open again, the file is not part of the recently opened section //cc this is a regression from the transient work we did


Type: <bBug</b<!-- Please fill in all XXX markers --Python Debug Console shows "Shell integration failed to activate" ! a Python file command over terminal with mouse <!-- After creating the issue on GitHub, you can add screenshots and GIFs of what is happening. Consider tools like , or for GIF creation. --<!-- NOTE: Everything below except Python output panel is auto-generated; no editing required. Please do provide Python output panel. --- Python version (& distribution if applicable, e.g. Anaconda): 3.10.5 Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Poetry Value of the setting: Default <details<summaryOutput for <codePython</codein the <codeOutput</codepanel (<codeView</code→<codeOutput</code, change the drop-down the upper-right of the <codeOutput</codepanel to <codePython</code) </summary<p</p</details<details<summaryUser Settings</summary<p</p</detailsExtension version: 2022.12.0 VS Code version: Code 1.70.1 (, 2022-08-10T06:08:33.642Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Same problem here
Same.
VS Code creates this terminal as a part of the request that gets sent over DAP. It seems like it is failing when VS code tries to create the terminal, moving this there for further investigation.
what needs to be done here for correct activation?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Can you elaborate why this ticket was closed? The issue is still there.
what needs to be done in order to prevent the "Shell integration" from failing?
If run in terminal replaces the shell args then this warning shouldn't be showing (as shell integration should be disabled). It does works in the JS debug terminal which is a terminal profile that sets an environment. If the terminal is launched without args this would be an issue on the terminal. how do I create a python debug console?


in a Python file the "Debug Python File" action from the editor drop down opens a python debug console
And Python debugger creates the "Python Debug Console" here: It is unrelated to the "JS debug terminal". It is just an integrated terminal where the debugger or runtime is launched.
Looks like the path and args should be supported because they're the defaults: Unless they were configured specially. We'll need to look into this.
I noticed I have the same problem
same here with using powershell core ! but i can't reproduce it with fresh system and latest vs code and latest powershel core using windows sandbox !
Getting the same error for the past couple weeks, on ssh terminal. !
what's the terminal profile you're using there? Is it a custom ssh one defined in your settings?
i'm new to vs and having this issue as well.. anyone please help~ thanks~!!
Can you share your file and also do a trace log while creating a terminal? /label info-needed terminal
i've uploaded 3 images at 1) terminal 2) renderer log 3) file let me know if you need anything else.. thanks~!
thanks for that info. I see the when I create a terminal like you do does using pwsh instead as your default profile fix it?
I am using default bash terminal over ssh. I did not define any specific terminal profiles. Here's the installation printout when it says starting ssh terminal. I can do but I don't know what to grep to share.
thanks for helping but i've just tried.. and it doesn't work.. same error still there.. what else can i do??
this is working for me - anyone seeing this should closely inspect their default profile - that's the primary reason shell integration would not get activated !
Same issue, but my debugger is cppdbg. Really annoying, I hope someone fixes it soon
Same issue with npm + devcontainer
I was having the same problem, but removing and using instead in seem to work for me
, very interesting, I tried what you have described (I just used "terminal.integrated.defaultProfile", but not "terminal.integrated.automationProfile", since I couldn't find it in settings), and it partly worked on one computer (the debugger showed up in the terminal and worked as intended, however when pointing at the terminal it still said "shell integration failed to activate").


THE INTERESTING PART IS THIS: I tried the same , , , on a different computer and the debugger didn't work at all, with the same error. The only difference might be that on the first pc I used mingw from MSYS gcc , and on the second pc I use normal MinGW gcc. I will check later to see if that is the cause
If this issue is related to what we expect, then you should see a warning of the form can one of you pls check if you see this?
i can't see this warning, all i get is "Shell integration failed to activate" and nothing more.
the warning would show up in devtools' console I think. For this issue I'm going to fix the shell integration failed to activate message in the hover when we didn't even try to inject. For example: !
is there any solution to this issue?
Yes you should no longer see that message. Can you please verify that's true in insider's?
<!-- 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!
the issue was fixed, thank you for your responsiveness,
When will this be resolved for regular users (not Insiders)? I am using 1.72.2
in abt a week


Type: <bBug</bwhen I do a ctrl-f and run search replace. When I put in a & to search for and a & with a new line it crashes visual studio code and once and a while my whole os VS Code version: Code 1.74.0 (, 2022-12-05T16:47:18.476Z) OS version: Linux x64 6.0.6--generic Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (41)</summaryExtensionVersion ------ language-x86-64-assembly3.0.0 vscode-intelephense-client1.8.2 compare-view0.10.0 vscode-eslint2.2.6 prettier-vscode9.10.3 theme-editor1.9.0 vscode-docker1.23.2 isort2022.8.0 python2022.20.1 vscode-pylance2022.12.20 jupyter2022.11.


jupyter-keymap1.0.0 jupyter-renderers1.0.12 vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 remote-containers0.266.1 remote-ssh0.94.0 remote-ssh-edit0.84.0 remote-wsl0.72.0 vscode-remote-extensionpack0.23.0 cmake-tools1.12.27 cpptools1.13.8 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell2022.12.1 remote-explorer0.0.3 vsliveshare1.0.5788 vsliveshare-audio0.1.91 vsliveshare-pack0.4.0 gremlins0.26.0 format-html-in-php1.7.0 nunjucks0.3.1 markdown-preview-enhanced0.6.5 code-spell-checker2.12.0 best-light-themes-pack1.0.2 cmake0.0.17 theme-generator0.0.8 php-debug1.29.1 php-pack1.0.3 linkerscript1.0.2 php-intellisense1.0.13 (11 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.74.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Updated to the latest version still same issue
Which find widget is it? Is it the find within a file or globally across the workspace?
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our . Please take the time to review these and update the issue. Happy Coding!
It's within a file
are you searching against a large file? Can you please share the document you search if possible to help troubleshoot?
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our . Please take the time to review these and update the issue. Happy Coding!
I used this text in a new file and when I did the above steps it crashed my system.


It's pure javascript code but not sure how this can crash the system. Assigning to our Electron experts.
Hi, could you attach a ?
It is not creating a dump file. Any suggestions to getting crash data from linux (Pop!_OS)
Can you please share a screen recording of the steps you have tried to get the crash dumps, thanks!
I finally got it to dump. Let me know if there is anything else I can do to help
Are you using a screen reader ? Seems like accessibility tree is enabled in your instance and the crash stacks point to Segmentation fault in the accessibility code path. Crash is addressed in
cannot repro, but would be good if also verifies this is fixed
I used the latest insiders and it worked as expected. Thank you very much! I tired it on the current release to make sure it was not fixed by me updating my system. The current release still crashed.
Also to note in current release I disabled all plugins and it still crashed and anytime I do it twice it crashes my whole system. So it is definitely fixed in the insider release