Currently when one types a term in the search-bar of the settings-UI and no matching settings are found then a Clear Search option appears which deletes the term in the search-bar if clicked. However, this option does not appear when matching settings are found. If one wants now to remove the term from the search-bar one has to manually select the typed term and press the delete-button. It would be more convenient if there always would be a 'Delete Search'-Button. This could be a little X symbol on the right of the search-bar. Currently when the Clear Search option is clicked the search-term is deleted but the search-bar loses focus. It would be more convenient if the search-bar would get the focus such that one could immediately start typing the new search-term.
This should be a case for all the inputs around the editor (search, replace etc.), to have a little to quickly erase the input's content. !
I disagree, the user is going to be typing anyway, they can press backspace. In the search view at least you can still use the "clear search results" button to clear all the inputs whether results are present or not (in Insiders only)
This I agree with, I will keep the issue open to do this.
May I ask you why there is only a clear-search-option when no matched settings are found? Why can't we have it also when results are found? Feels kind of half-baked to me. Either there is an option available which enables to clear every search or there is no such option.
I don't want to clutter the UI by adding buttons for something that doesn't really need a button.
Why then not remove the clear-search-option completely? What purpose does it give in the case when no settings are found in contrast to when settings are found?
I guess that when no settings are found, you definitely want to clear the filter because there's nothing else to do, but when you are searching, you either found the setting you want or you want to tweak your search query to search for something different. When the page is full of settings, adding a button/link to clear the query would be UI noise.
I find myself often in one of the following situations when some settings for my typed search-term are found: Wrong settings are found because I didn't know the correct search-term and now I want to delete the complete term and type a completely knew one with the hope that the new term will show me the correct results. I typed the correct term and found the correct settings. After changing the settings I need to type a completely knew term because I want to search for the next settings which I want to change. I typed the correct term and found the correct settings. After changing the settings I want to come back to the default settings-view (where all settings are show as if you just opened the settings-UI). For this however I need first to select the entire search-term (double/triple click the term or select the term manually with the mouse) and then I need two press the del-button and afterwards move my hand back to the mouse. Instead one could simply click on a tiny del-icon right within the search-bar and instantly start typing the new term or even keep the hand on the mouse and keep searching trough the default-search-view. In fact I find the case when no results are found the most useless for a clear-search-button because when no settings are found I instantly can see that. In such a case my hands are usually still on the keyboard what means that it is easier to delete/correct the term with the keyboard instead of reaching to the mouse, clicking on the button and then again moving back to the keyboard to type the new-search-term.
Actually such a clear-search-button already exists in the keyboard-shortcuts-search-bar. You can see it in the screenshot on the far right within the search-bar. !
Got me there. I guess would take a PR that adds the same button to the settings editor.
I've been working on this issue.. Currently I have the search clear button working in the settings editor, I just need to tidy up placement as there is a search counter that appears where the action bar icons normally appear. I was thinking to just place the search counter that appears, slightly to the left beside where the clear button will be. What would you suggest for this?


Issue Type: <bFeature Request</bThis new feature is over-eager and triggers on unsaved files that are not part of the commit, which I don't think makes sense. If I have staged file and am committing only file , I should not receive a warning that is unsaved. Ideally it will only consider staged files unless I am committing all staged and unstaged. VS Code version: Code 1.30.2 (, 2019-01-07T22:54:13.295Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Hi, can I work on this one?
Sure!
I'm not in favor of changing this. Or if it is changed, perhaps give finer grain control over when it prompts. I always want a prompt because I'm a bit lazy and usually let VSCode add the files to staging for me when I commit.
I see the value in your use case, but I don't think it makes sense in this feature. If you committed with a file that was untracked but saved this warning wouldn't help you. I think it would make more sense as a separate feature that warns on commit if there are untracked files regardless of save state.
Experienced this today. I had to loop on this experience 3 times before I finally groked what was occurring and my choices in the dialog. I believe there are two issues here: rules triggering the dialog dialog itself In my scenario today, this was triggered by me having an untracked file named open in VSCode. was previously saved to disk. It continues to be untracked. I had made some more changes to this file, but not yet saved those to disk. The key concern here for me is that this is an untracked file. I do not want to have any dialogs given to me by VSCode for untracked files when I attempt to commit. This is the dialog I was presented: I kept clicking cancel. Because I equated with . I wanted to answer to the question . On my 3rd time, I read again the dialog and every choice. I finally clicked and got the effect I desired. This dialog is poorly designed. The question proposed is a yes/no question "Would you like to save it before committing?". Unfortunately, the three buttons are not or . Instead they are answers to a question not asked...something like "What would you like to do now?". Naturally, that's a poor question and instead, this dialog needs to be reworked.
I've rephrased it to . Changed the to support for your use case.
, The text you proposed doesn't address the situation. Referencing the post I made, the file in question was unstaged. Therefore the text you propose doesn't address the unstaged files that are triggering this dialog box. You could change the text to but that's messy. Having two dialog boxes (one for unsaved staged, one for unsaved unstaged) is also messy. And one dialog box for each file is equally messy. All of this suggests to me that the feature itself needs rethinking, not just text in the dialog box. Personally (as a focus group of one), I don't want the feature. But someone somewhere though this feature was cool. So exploring with that group can perhaps surface a better mechanism to address their needs.
I see what you mean now. I simply removed the qualification for now. Thanks for the ping. I don't really think this small feature warrants such a big investment as a user study group, though.
One more small thing, the warning says But if the file has saved changes and also some unsaved changes, then the file will be included, it's just the unsaved changes that won't be included. This seems like it would be a common case so maybe it could say "will be incomplete in the commit" or "is unsaved and those changes will not be included" or "has unsaved changed that won't be included in the commit" something.
Changed to .


Issue Type: <bBug</bRepro steps: settings to for a setting screen really large :bug: Content does not center with the header <img width="1282" alt="image" src="https://user-"VS Code version: Code - Insiders 1.31.0-insider (, 2019-01-23T06:13:04.232Z) OS version: Darwin x64 18.2.0 <details<summarySystem Info</summary </details<details<summaryExtensions (6)</summaryExtensionVersion ------ vscode-browser-preview0.2.5 vscode-svgviewer1.4.7 prettier-vscode1.7.3 vscode-typescript-tslint-plugin0.3.0 debugger-for-chrome4.11.1 code-settings-sync3.2.4 (5 theme extensions excluded) </details<!-- generated by issue reporter --


VSCode Version: 1.31.0 OS Version: windows 10 Steps to Reproduce: the Help menu and select the release notes. any menu again click, right click, or select operation on this content page will not automatically close the open menu. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.502 --- <!-- score: 0.45 --<!-- potentialduplicatescomment --
Do not repeat with the above questions
Same root cause as I believe
Actually will keep open to make sure this is resolved by the fix


Broken due to refactorings of the workbench CSS. Fix is simple (CSS only change).


I do not see a duplicate of my issue: ! So I'm in the clear. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.32.0 OS Version: Windows 10 1809 Stable Steps to Reproduce: Visual Studio Code, click on the "Search" sidebar menu item to bring up the huge Search menu. ! for a common word used quite a lot. Like "a", "let", "var", "i", and so forth. the Search displays the total results count, dismiss a few of them. total results count should decrement by 1 per dismissal, or indicate both the original total results count and the remaining non-dismissed total results count side by side when dismissing the search results. For example: ! Does this issue occur when all extensions are disabled?: Yes
For me, it does decrement. You don't see that? You are clicking the 'x' icon on a result row, right?
It doesn't. !
Ok, so I was about to get it to decrement, but that's not done in real-time. ! Both of the GIFs are done in 1.32.1.
That's right, I thought you were talking about the total shown at the top ("x results in y files") in your original post.
This also happens when a new match is or deleted in an existing file match. !


Issue Type: <bBug</bSee also - but note that people say they Debug console behaves normally Debug console scrolls to top after each evaluated line this code as breakpoints at "Uncaught exceptions" in VS Code hitting SystemExit exception, run in Debug console. a bunch of times (1-5 times) in the Debug console. that at one point, Debug console scrolls to top to bottom of Debug console output in Debug console. that you don't see due to Debug console scrolling near top again. VS Code version: Code 1.32.1 (, 2019-03-08T00:51:49.278Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (5)</summaryExtensionVersion ------ latex-workshop6.2.0 svn-scm1.47.1 python2019.2.5558 multi-command1.3.0 code-settings-sync3.2.7 </details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.628 --- <!-- score: 0.584 --- <!-- score: 0.578 --- <!-- score: 0.544 --- <!-- score: 0.502 --<!-- potentialduplicatescomment --
Yes, looks like is a duplicate of this one, although does not have specific reproduction steps. This one does. Also, it looks like they investigated 1.32.0-insider, while I am still seeing this in 1.32.1. Also, I can repro this in the latest insider build with only the Python extension and no settings changed whatsoever (see below). Finally, I must admit finding repro steps was a bit difficult. So I am not fully convinced this issue is fixed, as implied by .
I can not reproduce this. Can you attach a gif / video showing this can you repro this using python?
Sure, here's a GIF: !
I can not reproduce with node. please try reproducing with python if you F1 developer tools put a breakpoint what do you see as scrollTop, scrollHeight and renderHeight at the exact moment when the debug console scrolls unexpectedly?
I encountered exactly the same issue as
then you can also try to answer the quesionts i asked . Get your hands dirty and do some debugging. Thanks
Breakpoint is hit twice per manual . After the first time manually entering , with the breakpoint hit at line 85: scrollTop = 0, scrollHeight = 19, renderHeight = 214 scrollTop = 0, scrollHeight = 480, renderHeight = 214 After the second time manually entering : scrollTop = 266, scrollHeight = 480, renderHeight = 214 scrollTop = 266, scrollHeight = 80, renderHeight = 214 (+) After (+), debug console is scrolled to top. I noticed that during (+), the debug console is empty, but not during any of the other breakpoint hits. I double-checked: is not a typo of , the above numbers are correct.
Yes, I too can replicate this issue on my Mac
Ok, thanks for help everybody. I can repro on my mac. Investigating...
After investigating and discussion with we figured out it is a dup of
Version: 1.34.0-insider Commit: Date: 2019-04-19T19:59:19.092Z Electron: 3.1.8 Chrome: 66.0.3359.181 10.2.0 V8: 6.6.346.32 OS: Darwin x64 18.2.0 This issue is not fixed in latest Insider and bugs me every day: !
I'm facing this since few months now. Any clue on how to avoid this issue? Please do not keep on closing this issue as it is real.
Check the insider release and see if it's fixed for you (it was for me). It seems the maintainers have chosen to leave this broken for everyone until their next major release next month which is unfortunate.
I'm on Insiders, it's not fixed for me.. Version: 1.34.0-insider Commit: Date: 2019-04-19T19:59:19.092Z Electron: 3.1.8 Chrome: 66.0.3359.181 10.2.0 V8: 6.6.346.32 OS: Darwin x64 18.2.0
I have the same issue. Version: 1.33.1 Commit: Date: 2019-04-11T08:20:22.771Z Electron: 3.1.6 Chrome: 66.0.3359.181 10.2.0 V8: 6.6.346.32 OS: Linux x64 4.15.0-34-generic snap
I'm having this issue even on the latest Insiders version (1.34.20-insider) See gif here :
Same issue here. Version: 1.33.1 (system setup) Commit: Date: 2019-04-11T08:27:09.080Z Electron: 3.1.6 Chrome: 66.0.3359.181 10.2.0 V8: 6.6.346.32 OS: Windows_NT ia32 10.0.
please do not close this issue. I am experiencing same problem: VSCode version: 1.33.1 System Software Overview: System Version: macOS 10.14.4 (18E226) Kernel Version: Darwin 18.5.0 Boot Volume: Mac OS Boot Mode: Normal Computer Name: iMac001 Secure Virtual Memory: Enabled System Integrity Protection: Enabled Time since boot: 7 days 6 minutes
sorry that this is a pain. I am looking into it but can not reproduce. Can you provide exact steps please?
Hi OP here. I can still repro the bug in official 1.34.0, so this is certainly not fixed. However, my repro steps from the original description do not work any longer as running actually ends the process that is debugged. I managed to repro the same issue with . So these are my current repro steps: this code as in VS Code hitting the breakpoint, run in Debug console. a bunch of times (1-5 times) in the Debug console. that at one point, Debug console scrolls up quite a bit to bottom of Debug console output in Debug console. that you don't see due to Debug console scrolling near top again. Here's a gif as well. (The gif misses step 6, but I think it gets the main issue across.) !
Thanks for the steps, I will look into this this or next week.
we have pushed a fix with the help of Please try it with VSCode insiders starting from Tuesday which will have the fix. Thank you
I have just checked and it seems to me the issue is gone, thank you! (Of course, I will be more confident once an actual release has the fix as I haven't re-setup insiders the exact same way I use my release version - let's hope for the best!)
Thanks. Adding verified label. Let us know how it goes once you get the stable update.
Stable looks good to me, too, thanks!


Hi, I am a bit new, and I have a simple code example on VS Code v1.32.3. It says I have an error, ok fine..... but then when I chose the "Quick Fix" option there is never a Quick Fix for this or any other thing in the past I tried to do a quick fix on. Whats the point of having a Quick Fix feature, if it doesn't do anything ? Im a bit confused. . This is the code I tried to do a quick fix on (its an extremely simple code): . ! When I try to fix, I get this: . !
I also get this issue for Python but seems to apply to any language. I have the Python extension as well as Intellicode. Still a current issue with 1.33 (Insiders) with the latest update.
Quick Fix... action is shown even when there are no quick fixes (code actions) available. May be it can hidden then.
Optimally, an actual corrective action would be taken (or at least suggested) based on the feedback provided by the language extensions (Python and Intellicode for my use-case).
Same here, I always get the "No code actions available" when I try to Quick Fix my code, no matter the language used, and even if I have no extension installed. ! ! I do not really know why it is not working, but I can't get to remember since when this bug is occurring to me ( I remember last summer it was okay, and I think during December too while I was working on an Angular Project )
Our C/C++ extensions does have lightbulb code actions for the error squiggle, but the quick fix still says "no code action" available -- is that a bug? Let us know if our extension isn't doing something correctly. I didn't understand the docs at . ! !
Can you please provide simple steps to repro this?
It occurs when you have a .c or .cpp file with text . We report the squiggle message via textDocumentpublishDiagnostics and the code action from textDocumentcodeAction. Do we need to do something special to associate the code action with the squiggle's QuickFix?
Quick Fix action asks for all code actions in that diagnostic range and of kind . What kind are your quick fix code actions?
Okay thanks a lot for informing us -- the "CodeActionKind" type is completely new to us. Our code action just returns a Command and not the additional info like the CodeActionKind. I filed a work item for us at . We have a lot of "catching up" to do with the LSP updates.
I have had this issue for weeks with C#, and I finally figured out that it was just the menu. Basic stuff where it used to suggest "using System;" no longer showed up. After reading this issue, I tried the command and the keyboard shortcut works but not the menu. This image shows what happens when clicking the "Quick fix..." menu: <img width="387" alt="screenshot from menu" src="https://user-"And this is what shows when pressing : <img width="414" alt="screenshot from keyboard" src="https://user-"This looks similar to the screenshots from and .
Seriously kills productivity, I am reinstalling PyCharm
Looks like C# extension is also not using the code action kind for their code actions. Probably we have to show all code actions for the given range.
I see the same issue with JSHint/JavaScript. ! !
The same thing (No code actions available) with PowerShell.
Same issue with TypeScript in .tsx file. ! !
This has been nearly two months! any fixes for this ? I'm having this issue in the latest version as well(Python)!
This feature becomes very important when you're upgrading code from a legacy version (such as Python 2) to the updated version (Python 3). I'm sure there are other languages have similar stipulations such as converting C to C++ or C# or vice versa (or even C# to C++ and vice versa).
I also have this issue, and this is very important when create the new project, but the works for me!
I also had this issue and only learned today from some searching that (on Linux) brings up the quick fix list of actual working suggestions EDIT: As shows below, that's the same issue I find when hovering using C#
This doesn't seem to be a problem for C# in my case atm (I'm using Unity/Mono). I exclusively use though.
I get the same with Powershell. ! ! However selecting it and press ctrl+. gave me the suggestion !
On a Mac, the Quick Fix shortcut appears to be ⌘. (Command + Period). It would be super helpful if we could get the quick fix to appear on mouse hover, though!
Hello there, I have the same problem since today. Quick fix was working a week ago but now clicking on "quick fix" and then clicking on suggestion do nothing. But if I use ctrl+; to show suggestion it work.
Just to clarify what was fixed by : we now only show the button in the hover if we know for sure that that quick fixes are available. A few extensions provide quick fix style code action but do not explicitly mark them as quick fixes. Those code actions will show up in the lightbulb menu but not if you click in errors hovers (because we only want to show code actions that we know for sure will fix something). Extensions must mark their quick fix code actions as  to have them show up in the problem hover menu too
can you verify that the python extension is good in this regard?
I took a look at my installed extensions and noticed the C# extension was complaining that it needed to be reloaded. Hmm, so check your extensions list first. This is what I was presented after clicking reload. Notice the version I'm running as of today's date stamp after I reloaded the C# extension. I hope this helps some of you. ! ! ! Be sure to click on the instance first, then use ctrl+. for windows ! You should now see the using statement, for example like on line 1 !


<!-- 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.


VSCode Version: 1.33.1 OS Version: WindowsNT x64 10.0. Steps to Reproduce: folder (Ctrl+K F) a search on specified path through Ctrl+Shift+F ! With literally any folder on my system opened search works: ! I'm not sure if this is intended behavior, as the message suggests that it shouldn't work if I don't have that particular_ folder currently opened anyways, and yet it does if I open anything. Does this issue occur when all extensions are disabled?: Yes
I was just about to file an issue to find out if searching an arbitrary folder / folder tree was even possible since the note says only the currently opened folder will be searched. This is one of the things Sublime has that I was hoping VS Code had. I never tried opening any ol' folder and giving it a run.
, can i take a look at this ?
Should fix the message 'You have not yet opened a folder. Only open files are currently searched - Open Folder' makes it sound like my searches will fail with no folder open, but as long as I plug a path in it works like the issue specifies. Maybe add something along the lines of 'unless a path is specified'
I could say, "You have not opened or specified a folder, ..." I'm not sure if that's too wordy, I don't think a warning message has to explain how the whole thing works, what do you think?
Make sure you reopen issues when they are "verification-found"
This would work. How would it work once I specified a folder but haven't hit send would the message go away due to having a valid path?
No, I think it should just be updated once when the search actually runs
That seems like it would work, it would at least imply that the action being performed would work.
Now it makes more sense !


Issue Type: <bBug</bHi. I am assigning trade.occId = occId; i.e. to a property (in this case it contains 4 spaces. In the JavaScript hover view however, the property on 'trade' reads (only one space) [btw, I copied both these values right out of the IDE view]. I've just been chasing ghosts for some time because of this discrepancy and not expecting the IDE altering assigned values when viewing objects. Update ---Alright, sorry. I am not sure how to submit the first value on GitHub with the 4 spaces between GS and 1 preserved, even when using 'code' quotes (same as the VSC issue...). So the first value is "GD....190517P00155000" when replacing spaces with dots... Thanks for VS Code otherwise :-) VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ vscode-scss0.6.2 debugger-for-chrome4.11.3 vscode-scss-formatter1.4.1 vscodeintellicode1.1.5 </details<!-- generated by issue reporter --
Can you please provide a screenshot of what you see? Also try disabling all extensions. I am not sure if such an hover is provided by out of the box typescript/javascript extension.
Hi. Please see below. I disabled all extensions besides Debugger for Chrome, which I need to set a break-point to be able to inspect values. The issue is in most obvious in the field 'occId', which in fact has 4 spaces after 'GD' and not just one as displayed. Thanks for following up. [image: ] !
Ah I see.. its an hover while debugging.
You did not attach an image. So please attach an image and some reproducable steps so we can investigate more. Thanks
It did, (please check below the quote). Anyway, your question made me come up with a better/simpler example that should make things clear. Here you go: ! Btw, Gruetzi to all you guys in Zuerich. I'm originally from Basel :)
Thanks for the image. Cheers back to Basel :)
VSCode insiders will have the fix for this on monday. Try it out and let us know if it is ok for you. Though I verified and the fix from looks good
Thanks for the work and update. Unfortunately I can't switch from VSCode stable, so I'll take your word for it until this hits release :-)


Steps to reproduce: clone open a terminal Debug viewlet Launch client Observe that building never finishes Now switch the terminal to the npm: watch task Observe: building finished. Looks like the terminal is not delivering any output as long as the view is not visible.
are there any differences on when onLineData occurs in the terminal with conpty?
discovered a new issue


Steps: right click into explorer root node you see native and custom menu ! Looks like the new tree is not preventing default and bubbling of event like the old tree did?


Issue Type: <bBug</bWe are developing an extension that implements a source control provider. It successfully adds s to its section. However the standard themes display the group captions in UPPERCASE by styling them with For our use case it's important to show the group captions in their actual case. AFAIK there isn't a way for our extension to make that happen. VS Code version: Code 1.34.0 (, 2019-05-15T21:59:37.030Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Yeah... let's then change the casing style and just uppercase them on the Git extension directly.
, Removing the styling , is that it or I should add it somewhere ? Because you said
Yeah we want to keep the git extension section as , etc.
, Could not find the exact detail of what to remove. Removing the style will remove it in all places , so that is not correct. I dont understand what group captions actually mean ( CC : , if you could help ) I found there are these ResourceGroup () for which the style is applied. Please help me out with this on the correct approach.
I think proposes that you do remove that style, but that you also change the code to explicitly uppercase the localized captions of the the three items being created there. With those changes Git users won't see any change of behaviour, but other SCM extensions can set mixed-case captions and have them display to the end user.
, Sorry got confused with the group captions , Sent a PR to fix this !
I'd love to see your PR get merged, but for some reason I don't understand it apparently failed in the Windows part of Azure Pipelines. can you help get this moving?
The windows build error might be some random errors , Happened in one more PR ( ) I guess that is not an issue and should confirm that.
Is there some way you can resubmit your PR to the build pipeline? Maybe it will pass the second time. Or if it doesn't perhaps there will be more info in the log.


VSCode Version: 1.35.0 OS Version: Windows 10 Steps to Reproduce: With 64-bit VS Code installed, run run VSCodeSetup-ia32- with /SUPPRESSMSGBOXES /VERYSILENT You'll get a dialog that says "please uninstall the 64-version before attempting to install the 32-bit version.”
Hello. I can take this issue if you want, I have reproduced and identified the bug. I will open a PR when ready :+1:
Verification: 32 bit to install 64 bit, msg box should come up to install 64 bit from the command line with /VERYSILENT, msg box should not come up
or still displays the message box.
It appears that latest insider release was built using this commit: Commit fixing this is was hours later: Is it possible that insiders version doesn't include the fix yet ?
Oh yes. Normally I catch myself on this, but It's still early in the morning I guess. Thank you for pointing that out , I'll test it once insiders contains the fix.


I'd like a setting to optionally prevent deprecated things from showing up in intellisense suggestions. For example, I'd like a way to prevent from being suggested here, so that I don't use it despite a non-deprecated version being available. ! My linter can catch it, but it'd be even nicer never to see the deprecated option. There are several documentation systems that use the tag: JSDoc: TSDoc: JavaDoc: Yard (for Ruby): Other systems use different, similar tags. I'm not sure if this is an issue for the VSCode core, or for something language-specific.
Sorry if this is a duplicate or is already possible. There are enough issues here and questions/answers on Stack Overflow that it's hard to be confident. This issue is related:
Not showing deprecated suggestions can be implemented by individual language extensions today (not striking out but tracks that). Adding just to see this is something we want better VS Code api support for in some way Otherwise, we can track this as a feature request for js/s
I'd say this is a dupe of and it would be us adding some API flag and then allows users to configure how the suggest UX is handling that flag
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues . See also our guidelines. Happy Coding!
Okay, that makes sense. What does "js/s" mean?
is it possible to add a setting like , so I can disable it to prevent deprecated from showing up in suggestions list?
Hey any update on that?
Verify that the setting exists and that it filters deprecated elements from IntelliSense


Steps to Reproduce: a couple of branches on the branch picker =:bug: the branches are no longer sorted by commit date This works fine in stable, so seems like a regression. INSIDERS ! STABLE ! (my git version is )
Stable: Insiders: Yup, there's a missing.


Problem: A popup opens, displaying: "The 'Remote - WSL' extension is recommended for opening a terminal in WSL." It has a 'Dont Show Again' and an 'Install' option. Clicking Don't Show Again has no effect. Expected Behaviour: Once I click Don't Show Again, this popup doesn't appear every single time I open the WSL terminal in VS Code. VSCode Version: 1.38.1 (user setup) OS Version: Windows_NT x64 10.0. Steps to Reproduce: WSL Ubuntu installed on Windows. the WSL integrated terminal on VS Code. Does this issue occur when all extensions are disabled?: No.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.614 --- <!-- score: 0.559 --- <!-- score: 0.549 --- <!-- score: 0.54 --- <!-- score: 0.52 --<!-- potentialduplicatescomment --
I wanna take a shot at this!
Does this happen on different workspaces or on the same workspace? Edit: I have checked and this only happens when you open different workspaces (Different project folders with VSCode) I personally think that this should not be the case and should be global so I will make a pull request for it.
Sorry for the late reply. I see you've already pushed a fix for this, so thanks a lot :)
Should I close the issue now?


Steps to Reproduce: web in Safari on compact menu = it moves !
I diagnosed this and see 2 issues: the menu items are not removed from the DOM when menu is not showing () you seem to be using instead of to hide the menu items, is there any particular reason? using the issue is not as bad anymore (I only see one initial jump) I suggest we use / (our helper), but I am not sure if you rely on the behavior of visibility?
I mentioned the reasoning in the linked issue, but in the compact case we can remove them from the DOM safely so patching that should help here.


Issue Type: <bBug</ba repo with a large amount of changed files in one folder and use the tree view <kbd+</kbdnext to the folder to stage the changes or <kbd-</kbdto unstage them. : ! This was supposedly fixed in for the discard command but either the other commands or the tree view was forgotten as a potential source of problems. Clicking the button next to "changes" works fine: ! VS Code version: Code 1.40.0 (, 2019-11-06T17:02:13.381Z) OS version: WindowsNT x64 6.1.7601 <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-eslint1.9.1 gitlens10.1.2 toggle-excluded-files1.7.0 EditorConfig0.14.2 RunOnSave0.2.0 prettier-vscode3.3.5 vscode-test-explorer2.14.6 rest-client0.22.2 vscode-docker0.8.2 vscode-language-pack-de1.40.2 vscode-jest3.0.2 project-snippets0.5.0 java0.52.0 vscode-coverage-gutters2.4.2 vscode-icons9.5.0 vscode-todo-highlight1.0.4 </details<!-- generated by issue reporter --
Yup, the same fix as needs to be applied to the stage action.
+1 Same issue here in the latest vs code and latest git Windows 10 home: v10.0. VS Code: 1.44.2 Git version: 2.26.2.windows.1


I use VSCode in three different places; my home computer, my work computer, and as a portable version I carry on a drive when I need to use a machine that doesn't have it. I use an extension to keep my settings synced up between editors, and the only issue I've encountered so far is that the git path doesn't match between any of them. On my home machine I have it installed to C of course, work likes to be funny and install it on A, and for the one on my drive I have a relative path set so that no matter what letter my drive gets, that VSCode can always find git. I already attempted to use an array myself just to see if it'd work: But VSCode reads it as one entire value. What I'd like is for it to recognize it as an array and then try each path in order until it finds Git or runs out of paths.
It is better to create an issue in extension repo with requesting the settings ignore feature.
Hy
This is a good feature request, please feel free to submit a PR.
Ah, thanks. I must have just seen the section title and completely glossed over it when I was reading through the docs.
I could help out with this feature-request, if you would like. At a glance, it looks like it would require a modification to the "createModel()" function in the "" file (line 34). We could get the "pathHint" as a string array and then possibly modify the logic inside of the "findGit()" function, or, if possible, iterate through the "pathHint" array until a valid "" value is returned. EDIT: Sorry, didn't realize a PR was already submitted...
Raised PR!
Verification The setting now accepts a list of values. The git extension must go through them one by one until it finds a usable git executable.


Snippets that use the SELECTION variable should be grouped into a new "Surround With..."-command, e.g support selection with try-catch or if-else. We should also consider not showing such snippets in IntelliSense because the selection is always where users are typing.
closing this in favour of
After and given that a dedicated command is more visible we should add this
hi, Thanks for your adding support for outside code and could please add some identification for those snippet support and/or when users are using command e.g.: when using insert snippet, users never know which snippet is outside-code supported there is the ui: ! and the snippet code from C# official extension ! for that reason, I have to add some tip/text for the name of snippet when I develop the snippet extension. after that, user could know that which is outside code supported. ! I could do it for myself and my extension, I there are many snippets that have no tip or identification Please add some identification for those outside code supported in UI when users using insert snippet. that will be useful and helpful for user to distinguish
! maybe some icon for text is good
BTW, there is another issues related to this. please
hi, should I file a new issue?
To verify open a typescript files select some code select F1 Surround with Snippet try-catch ensure the selected code is surrounded by the snippet
Verification looked good with both TS and CS files.


<!-- Please search existing issues to avoid creating duplicates. --I noticed in the settings-editor that there are now duplicate clear buttons when the user searches but finds no result. <!-- Describe the feature you'd like. --I propose getting rid of the "Clear Search" text in the bottom left corner as there is now a button in the search bar that achieves the same thing but with less clutter (in my opinion). This change would make the settings-editor more consistent with the keyboard shortcuts tab as well. !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.464 --<!-- potentialduplicatescomment --
Yeah we can probably just get rid of the text link
What about the "Clear Filters" link? Should there be an extra Clear Filters button that appears in the search bar itself, or let the link stay?
Would you mind sending me a picture of the "Clear Filters" link ? Where exactly is the link ? I will look into this.
! When you use one of the @ filters it appears.
For now I think we can let the 'Clear Filters' link stay. This issue was originally meant to get rid of the duplicates. In another PR I could add a button to the search bar that adds this , and then we could get rid of that link though, although other tabs don't have that sort of button . What do you think ?
Yeah the "Clear Filters" link is all about discoverability and I'd rather leave it


A lot of extensions have configuration code. It is extremely annoying that since some version ago we are unable to copy anything from that pane, mouse or keyboard. Steps to reproduce: Go to extension description Try to copy something Video:
See I'm surprised that you can't copy using the keyboard. What key sequence are you using? What command(s) does your Keyboard Shortcuts page show that bound to?
Im using the usual cmd+c which works in other apps. And cmd+c also works in the editor mode, terminal mode - so i think its not my key bindings customization. I recorded video in presenter mode (displaying what i press) showing copying something else + not working for ext description:


VSCode Version: Code 1.41.0 (, 2019-12-11T18:37:42.077Z) OS Version: Windows_NT x64 10.0. Steps to Reproduce: a Markdown file on a network shared folder (ex.: ). that network shared folder to a drive letter in Windows (ex.: ). the Markdown file in VS Code using the mapped drive letter (ex.: ) and open its Side-by-Side Preview (). The preview should be correctly formatted. the same Markdown file in VS Code, but using the file's UNC path (ex.: ) and open its Side-by-Side Preview. The preview is incorrectly formatted. Does this issue occur when all extensions are disabled?: Yes Correct format (file opened through mapped drive letter): ! Wrong format (file opened through UNC path): !
I would like to work on this if possible.
There was a typo in the code was causing this. I have tested on Windows 10 with a file on a UNC path with the fix above and it is working fine.


If you return in a completion item, the property is when calling through . Setup: Test code: Output is: Full repro project is here:
It looks like the conversion is missing. The doc states that additionalTextEdits should not overlap with the main edit range or each other, should that be checked or is that done when the edits are carried out? Adding this: ! works, unless the range intersections need to be checked.
No checks required - this is already the way back from the UX and check should have been carried out already


<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Currently, when a debugger is executed (ie by hitting F5), a terminal is opened and the debugger is executed as a command. This command can get pretty long as it also changes to the working directory and sets some environment variables. Running the Python debugger in a simple project with only one file runs a command which is 243 characters long. This, however, means that these commands which are not meant to be run by the user but are instead run automatically are still included in the user's shell history file by default. I propose changing the command generation function to include a space at the very beginning - on many shells across various distros, is set to not add commands to history if they start with a space character. This also gives some control to the user whether they'd like for the debugger commands to be stored in history or not.
If you were wondering why someone might want this, I like that the history is there. All the time I go to my command line and use up arrow enter to rerun the last auto generated command. I've also gone through the history a bunch to rerun previous auto generated commands too.
Aye, this is why I opted for simply adding a space instead of something more aggressive such as - the shell is still in control whether to preserve history or not with . EDIT: Also, in my shell, commands which were run with a space can still be reached by pressing the up key in the active session, but I'm not sure this is the case in other shells.
This works for the integrated terminal, but I noticed the external terminal doesn't get the space on OSX !
On MacOS the leading space character seems to get dropped in the Applescript that talks to the Terminal application. So the feature at hand only works for the integrated terminal for now. I've created a for the external terminal. Since has verified that the fix works for the integrated terminal, I'm adding the "verified" label.


Right now when a breakpoint is hit, the function in is called, and it in turn calls . The logic of is that it shows the wanted element at the very bottom of the scroll view. What this means is that in the Call Stack view, we'll only see the thread that hit the breakpoint and the first frame at the very bottom -- Ideally I think we want to show this at the top, so that we can see the whole stack trace, not just the first frame.
try it out in VS Code insiders from Friday and let us know if it behaves good for you so we add a verified label here. Thanks
did you get a chance to give this a spin?
sorry for the late reply. I tested it on the latest Insiders Build and it works as expected -- on breakpoint, the stack view shows the current thread in the middle if there are multiple threads in the program and the behavior is not changed compared to the previous version if there are fewer threads.
Also another question for you I can see that you guys (i.e. the VSCode team at Microsoft) are working heavily on Debugging UX improvements and our teams at Facebook could also suggest a few improvements we could benefit from. What is the process on picking the improvements to work on? Is it only done via feature requests? If so, how do you pick and prioritize the requests?
Thanks for coming back, adding verified label. For suggestions on improvments please create new feature requests. Feel free to ping me on them. Thanks


Could be related to the Untitled file title changes. The tests hang here: ! /cc
The same on macOS.


<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Add an method to the interface. The current options are: trying to stat the and seeing if it fails — we have no way to tell why it failed; reading a parent directory — we may not have read access to the parent directory; using node's — only works for the local filesystem.
I see s are spec'd to thow on when the file doesn't exist, but does not spec such errors.
We have no plans for adding and instead should be used (this goes along the deprecated to NodeJS's -deprecation). Still, I do agree that we should spec the error
Would be a passable solution?
Re-open for API proposal/finalization. Proposal is to add a field to the -class
should I rename the issue to better reflect the proposal?
Reactions during the API meeting were positive, so I am confident that we can finalize this during the current milestone. One feedback item was to always have a value for , e.g. let its default value be something like or
I did a quick search of the codebase, and it looks like is usually used for such cases in the various error code enums.
This is now in and will be stable API with the next relase. thanks for the help


Refs: A text document can be readonly if it's underlying file system provider is readonly. I am not sure how a custom editor implementor can figure this out and provide the correct experience.
Could we add a property to ? Does VS Code internally already know if a given textDocument is read only?
We basically ask the file system provider for the resource of the document for being readonly or not. That should be doable.


Stable above, insiders below: !
Doesn't seem to happen on macOS and the regression happened in the last couple of days. have panel/view-related changes happened that could have caused this?
Affects tasks/custom terminals pretty badly: <img width="146" alt="Screen Shot 2020-02-28 at 6 42 45 AM" src="https://user-"<img width="226" alt="Screen Shot 2020-02-28 at 6 43 15 AM" src="https://user-"
Likely my fault from drag and drop change


Following up on microsoft/TypeScript, is now a valid completion directive. It should be recommended over in the editor walkthrough that mentions comment directives.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.668 --<!-- potentialduplicatescomment --


<!-- 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.43.0 OS Version: n/a I have the set to in my settings: Given a Does not produce any warnings as expected. However in : The linter says
This has the same root cause as : script are owned by the html extension instead of by the JavaScript extension. Fixing that is difficult However we could have a small fix that just makes html understand the setting. Marking this as help-wanted
Hello I'd like to try my hands on fixing this issue. Can you give some pointers as to which files are good places to start?
This change will need to be made in the HTML extension Here's where we configure TypeScript for the html extension: You should: Pass the value for in with the initial configuration Make sure that the language service updates its value for when the VS Code setting changes
Is there another way to get the setting value other than vscode.workspace.getConfiguration()? The 'vscode' module cannot be found when I try to import it into javascriptMode. I think 'vscode' would have to be as a dependency in in order to import 'vscode'.
Right now I'm passing in a default 'false' for experimentalDecorators in the initial configuration and passing the settings into getJavascriptMode.doValidation to update compilerOptions and calling ts.createLanguageService(host) every time doValidation is invoked. It has the expected behavior, but is there a better way to update the compiler options without creating the service every time it runs validation?
Is called when the file is changed? If it is, try updating the object that it returns
I am reproducing this error now with the following code: I realize this is known, but I will add the mention with respect to . Here is the relevant docs page, if a person wanted to make a unit test using If anyone finds this in the future, if is set in , it should suppress this error. Additionally, both and files, in the root of the project, take precedence over that setting.


<!-- 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.44.2 OS Version: Ubuntu 19.10 Steps to Reproduce: navigate editors through QuickOpen "navigate next" and "navigate previous" work as "navigate next after next" and "navigate previous of previous". So simply said it skip next/previous editor. Here are keybindings I use ` works ok, but and don't <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
PR: The issue is that we are listening to keys within the quick input control to do certain things but we do not prevent bubbling. This means our keybinding service will also receive these keys and check for actions to perform. In the old quick open widget we always prevented bubbling for that reason.


<!-- Do Not Delete This! bugreporttemplate --VSCode does a decent job highlighting many different shell script languages. But it doesn't seem to be aware that pdksh, dash, mksh, and posh, especially configuration files like and shebanged extensionless scripts, are POSIXy shell scripts. They just highlight as Plain Text files instead. Same for , that's a Tcsh shell script.
PR welcome!


<!-- 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.44.2 OS Version: macOS Steps to Reproduce: an extension providing in-editor comments via the comments API an editor containing comments the terminal at the bottom a command which causes the comments to be updated. For our comment provider, we automatically detect comments associated with your source control commit. So, for example, use the command line to checkout a different commit. comments will change, causing some of the previous comments to be hidden. When this happens, the editor is focused. This causes you to lose focus on the terminal. The end result UX is that you're typing commands in the terminal, and your focus gets stolen to an open editor for no visible reason, making it annoying if you wanted to keep running more commands. Notably, this depends on the way the comments API is used. I believe many comment providers do not respond to source control, and require clicking a button to activate/deactivate, so it's likely that's why this hasn't been reported before. For us, this is really annoying, and I could see this hitting other providers in the future. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No, because you need an extension which contributes via comments API
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.562 --- <!-- score: 0.513 --- <!-- score: 0.501 --- <!-- score: 0.493 --- <!-- score: 0.492 --<!-- potentialduplicatescomment --


<!-- 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 suggest an improvement to the Monokai Dimmed theme. Monokai Dimmed doesn't have colors set, resulting in 'ugly looking' fancy terminal features, such as Powerline. For a nice looking improvement, the terminal colors can be taken from the Monokai theme: Before: ! After: ! I intend to open a Pull request shortly that realizes this suggestion.
This looks much better, thanks for the PR! ! !
Thanks for accepting the PR! As a side note, I quickly looked at the other themes, and many of them haven't set any terminal colors, and even the ones that have them set usually haven't aligned ANSI black with the background, leading to weird-looking 'fancy shell features': ! ! Then again, there are documented ways how to adjust the color palettes for a particular VSCode installation or workspace, and this is quite likely a bit of an edge case anyway. Thanks for all the good work you guys have been doing!
Is there an option to disable this? or if there's not what would be the values one would need to set on terminal.X to revert what the commit changed? I prefer the non washed terminal and noticed this changed on last update. Edit: For anyone looking to use default terminal colors, add this to


<!-- 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. --- VS Code version: Code - Insiders 1.46.0-insider (, 2020-06-05T12:27:56.662Z) OS version: Darwin x64 18.7.0 Steps to Reproduce: all network connections. VSCode. "Developer: Startup Performance" from the Command Palette. Expected result: Startup Performance measurements are displayed. Actual result: Startup Performance never finishes "Loading...". Error logged in Dev Tools Console. ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Failing requests are from the extension service, not sure if this is intended during the startup metrics collection. Deferring to
I do not know how the start up perf are recorded and I assume these network requests failures are unrelated to it. Any insights on this?
I don't believe this is specific to the performance editor but must be rooted somewhere lower. The perf editor shows while it the eventually lifecycle phase and extensions being registered. So, I believe the culprit must be somewhere there
Assigning to and for lifecycle phase and extensions being registered steps respectively
Running with and checking logs, the is reached: There are 2 more things the editor awaits on: Maybe Jo could check on the former and Alex on the latter.
The former is again installed extension registered and lifecycle phase awaiting
this call is never returning: But is needed for this barrier to open:
Good digging. Thanks Adding to decide if the update service should eventually error or return false when asked for latest without internet access
I think throwing would make more sense for a service call.


Issue Type: <bBug</bPlotting a large plot (e.g seaborn pairplot) with many columns via jupyter interactive mode and then viewing in plots viewer is very slow to view/zoom/pan VS Code version: Code 1.45.1 (, 2020-05-14T08:27:35.169Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ vscode-django0.20.0 vscode-markdownlint0.36.1 python-extension-pack1.6.0 gc-excelviewer2.1.35 r1.4.2 vsc-python-indent1.10.1 MagicPython1.1.0 anaconda-extension-pack1.0.1 python2020.6. vscode-yaml0.8.0 vscodeintellicode1.2.8 </details<!-- generated by issue reporter --
This sounds like a problem caused by the extension providing the Jupyter Notebooks. Please file the issue there.
Hi same problem here, are there any workarounds in place for this?
I've moved to


Noticed how the process explorer is bundling and still. Can we not use Codicons for this? //cc
Oh this seems to be used in the issue reporter, not process explorer. But not sure how to actually see it...
are we actually using these icons? I'm not seeing it: !
it looks like these are only used when VSCode is connected to a remote to show the remote processes as well. I didn't even know we had that, pretty cool: ! Anyhow, my request still seems valid.
PR up at !


Issue Type: <bBug</bSemantic token colorization fails when a token type ID matching any object.prototype property name is provided. Some examples are: , and . is the most problematic name since it is likely to be used as a token type ID. Any string should be able to be used as a token type ID without causing the colorization to fail. Because tries to call on what was thought to be a but was actually a , which throws a TypeError and causes the colorization to fail. The easiest way is probably to use a instead of an object for . Another solution might be to instantiate using instead of an object literal in order to avoid the object.prototype. VS Code version: Code 1.47.2 (, 2020-07-15T18:22:15.161Z) OS version: Linux x64 4.19.0-9-amd64 <!-- generated by issue reporter --


latest VS Code insiders, turn on Voice Over on mac P -notice how the screen reader does not read any of the items in the quick pick This works just fine on Linux and Windows. Also works fine for stable. So it seems like an chrome update in electron broke this I can also repro running in . In Firefox and Safari all is good. I can not reproduce in Chrome cannary, so there seems to be a fix in Chrome latest. Ideally we would find the fix in Chrome and backport it to our Electron. fyi And for Chrome smartness, maybe one of your collegues fixed something like this (should be related to )
I can add this to my list (which is starting to grow I'm afraid). BUT, you don't need smartness; you need the most excellent bisect-build tool! :smile: Docs here: Once you have the regression range, you just sit there as pre-built binaries are presented for you to try and mark as good or bad. Best. Tool. Ever. Lemme know if you have any questions or need help.
Thanks a lot. Let's see if already has this set up, otherwise I can also look into it.
Yup I can do the bisect shortly.
Bisect result for when regression was introduced: Potential candidate: https://chromium-
Looking for fix now.
Upstream fix: https://chromium- Crbug:
Impressive. Thanks a lot!


<!-- 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.47.3 OS Version: Darwin x64 18.7.0 Steps to Reproduce: completeFunctionCall new tyepscript file, ype cursor at <kbdTAB</kbdExpected: Actual: Does this issue occur when all extensions are disabled?: Yes/No


<!-- 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: --So, this issue is here for a long time in vscode, i've just noticed another issue with it. Basically, vsCode shows incorrect icons, see on the screensot: ! You see that it shows react icon for babel js and simple js icon for react js. I actually know that it may be better to use .jsx files for react project, but is there any way to fix this? and also Is there a way to automaticaly recognize whether the file is for react or simple javascript(by detecting import/require export/module.exports statements or smth else)?? This is the main question for the issue. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.1(Latest) OS Version: Windows 10 2004 Steps to Reproduce: on the language selector in right bottom corner. in Javascript. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes, and it also shows more incorrect variant. !
Maybe it is the issue with the icon pack extensions that I use, so if needed i'll provide my extensions list.
I don't see this in 1.48.1 ! Can you try without custom extensions? (close all windows and run code --disable-extensions`)
i've already mentioned in my post that i tried without extensions and provided a screenshot. It shows react icon for both js and react js. UPDATE: to be honest, I've just tried again with all windows closed and nothing changed. same result
I think you have the following setting configured. Is that correct?
Yep, you are right. Should i remove that setting entirely or change it? Also the main question was: can VSCode automatically detect whether js file is for react or vanilla js? UPDATE: I removed that setting and now it shows js icon for reactjs ! However, if I select react js the file icon becomes correct) !
It's a bug in the language selection dialog. For getting the langauge icon, we use the icon of the first file extension. In your case that file extension has be reassigned to a different language. I create a PR.
Great, good luck and notify me if some actions from my side will be needed)
I pushed a fix. You can already try it out in our insiders build or in the next stable release.
I am not sure this is fixed, what are the steps? I configured my settings as outlined. I see this: !
The screenshot looks correct. In the language selector, the entry has the correct JS icon. Verification steps: Seti theme add to settings:open a js file, verify it has the react icon open the language mode quick pick, filter for verify that JavaScript shows the JS icon and the JavaScript React the react icon
great, i'll check it in nearest stable update)
Ok, but the main reason I started this issue is if vscode can automatically detect reactjs files and set the propper icon. So please, tell me if I need to start a new issue or if there is a solution for this "problem"
Yes, a new issue is needed. That said, it's a difficult request as language detection has to be very efficient as there can be hundreds of files visible in a view. Analyzing the content and even parsing it or resolving imports would be very expensive. Fee free to file the issue anyways, but I don't think we can do it.


<!-- 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. --Since you can have multiple s in a project, it would be great if vscode would be able to detect them and apply the right Language Mode (Groovy). The feature is essentially the same how vscode handles s.


Issue Type: <bBug</bsomething like Gentoo Linux VSCode in terminal get something like Possible fix: Don't hardcode the path to these :^) VS Code version: Code 1.49.1 (, 2020-09-16T23:23:33.049Z) OS version: Linux x64 5.8.8-gentoo <details<summarySystem Info</summary </details<details<summaryExtensions (6)</summaryExtensionVersion ------ gitlens10.2.2 cpptools1.0.0 vsliveshare1.0.2740 LiveServer5.6.1 vscodeintellicode1.2.10 vscode-icons11.0.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --


When executing search from extension api 2 checkboxes are not exposed: Preserve Case Use Exclude Settings and Ignore Files !
Hey , Can you please explain a little more about the issue?
It's possible to trigger a search from extension by using this api: And it has a good amount of options: But 2 of them are missing:
Thank got the idea. I will raise a PR to fix the issue ASAP :)
I have raised the . If you get time please review :)
genuinely didn't notice the existing PR, apologies
Thanks :). No problem
It great now that it's possible to control it but why does it called ? Would it possible to have the same name as in label:
Updated to as per suggestion and for consistency with search editor post . Also these to the keybindings intellisense registry.


<!-- 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. --Version: 1.50.0-insider Commit: Date: 2020-09-18T05:28:58.063Z Browser: Mozilla/5.0 (Linux; Android 10; Surface Duo) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.116 Mobile Safari/537.36 EdgA/45.09.62.5078 Steps to Reproduce: Codespaces in a browser on Android (for me, I used Surface Duo) in the editor and hit key In the editor pane you expect it to delete the last character Instead, it does nothing. Here the input: ! NOTE: This appears to be a Monaco bug as the samples on the Monaco website have the same problem. In the terminal you expect it to delete the last character on the prompt I typed "asdf" and then backspace rather than doing nothing or deleting anything... It adds an extra "asd" to my prompt (so I now have "asdfasd"). Then I hit backspace again... It adds "as" to my prompt (so I now have "asdfasdas")... Backspace again adds an "a" (so now "asdfasdasa".... Backspace again and this time it does nothing.... Backspace one more time and it actually starts working. Here's the input next to codespaces: ! I've seen very similar behavior in Azure Cloud Shell in the Azure Mobile App so I have a feeling the terminal bug is in Feel free to reach out if you want me to give something a try! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No
This is probably because you're using an on screen keyboard. It's probably a tricky problem for the terminal which is why hasn't been solved yet.
I believe it's tricky :/ one clarification, I also tried using a bluetooth keyboard and got the same result.
Forgot that we already had an old issue in Monaco-editor and
UPDATE: I switched to GBoard from SwiftKey to see if that has any change (SwiftKey is the default installed keyboard because Microsoft :) ) and GBoard actually WORKS... both in the terminal and in the editor... The only thing that didn't work in my minimal testing was backspace on an empty line did not delete the line.
Wow that's great to hear, that there may be a temporary working solution with alternative keyboards. However I wanted to add that for me, connecting a physical keyboard via USB, with an adapter, was working perfectly (since the virtual keyboard doesn't appear and, I guess, is not used at all).
The editor should now work fine via
nice! When might I be able to give this a spin?
With the next insiders or right now if you can run from master on your device. I hope things will work with a real device, I have been using an Android emulator to implement this...
I no longer have this phone to try this out :(
This could have also improved with


1) install the Remote-SSH and the Codespaces extension 2) Open the remote explorer 3) Select SSH Targets 3) Grab the SSH Targets view and drag it onto the activity bar -the drop down still shows both entries but without any view -the dropped view only shows SSH Targets (as expected) and so there is no way to get to Codespaces anymore 4) Use the SSH Targets view and move it back into the Remote Explorer -two views, one of them a zombie
Looks like somehow the remote explorer got enable for moving views again...


<!-- 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 UI allows us to click-set a breakpoint and then do "Edit Breakpoint" and set Expression, Hit Count or Log Message at any point before or during a debug session. However, not all debug adapters support these features. As soon as the debug adapter runs and capabilities are received on initialization, it should be clear if these will actually be supported. Before the debug session starts, I can hover over the breakpoint and see its details. ! Once debug session starts, breakpoint gets an exclamation point in the middle of it. At first, I thought that meant that the breakpoint was special - i.e. had conditions, but now I am realizing that it means the breakpoint has a problem. If I stop on entry and hover over the breakpoint or if I hover over it while the program is running, I do see "Breakpoints of this type are not supported by the debugger". I can no longer see all of the conditions on hover that I could see before the session started. The error message does not make it clear which of the features are not supported. That would be quite helpful as the debuggers might support different subsets. ! If the debug session hits the breakpoint, then none of the hovers are available anymore for any breakpoint, hit or not. At first I thought this was the only available behavior (see first version of this bug), not realizing that I could get more info if hovering in other conditions. It would be great if the same available information was displayed no matter when you hover over a breakpoint. ! It would also be great if the unsupported options could be disabled in the UI as unavailable while the debug adapter is running.
What you are saying makes sense, however before a user starts debugging there is no debug adapter so we can not disalow setting log points function breakpoint etc even if they will not be supported - we do not know. Yes we could disable some functionality while the debug adapter is running. For that I have decided to leave this issue open and assing to the backlog so we potentially tackle this in the future.
To clarify my original request: I am not asking for any modification before the DA runs. I understand that it is impossible and tried to make that clear in the first paragraph of my original post. I do think that it is important to make this clear after the DA runs. Disabling functionality for new breakpoints is the the last suggestion I made and would be a cherry on top. Please do take a look at my thoughts in the middle of my original report. Depending on where you are in the program, you might or might not get a hover error message "Breakpoints of this type are not supported by the debugger", but even when you do (not always), it doesn't list any of the details. Is it the hit count that is not supported? The expression? Both? There is no way to tell.
Agree. We should improve this.
I will fix this I don't want to do this, since the fact that one debug type is running does not mean that the user doesn't want other debuggers to be run as well.


Connect a mac-windows SSH remote Open terminal See this popup ! So fails here because it checks ".PATH" on the environment when this is actually "Path" on windows. has special behavior where it resolves property accesses in a case-insensitive way on Windows. We changed many accesses from using to a constructed environment object, and need the same behavior there.
is this a mac-specific issue or are there steps to repro/verify on Windows?
Can't be verified on windows. Thanks


<!-- 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.50.1 OS Version: Steps to Reproduce: vscode/extensions/theme-tomorrow-night- that wrong value for themeLabel is given ("Quiet Light" instead of "Tomorrow Night Blue") <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Incorrect value "Quiet Light" commited in


Testing Unfiltered notebook noob feedback: ! I was expecting a tooltip to tell me what it meant.
Agreed that we should add tooltip for it.
how would you interpret it if there was a tooltip that said "Execution Order"?
when you run all cells it goes in that order? I was expecting that to be sequential from the top?
It's the order that it was executed it, not the order it will execute in. Hopefully a user would figure that out if they run the cell and see it change.
oh, more explicit would be better then imo I also question why this is useful but I'm guessing this is a common notebooks feature elsewhere?
Yeah it's what people expect from Jupyter and can help you understand the state of the kernel
Thanks that needs to be localized though. btw if you are going to merge your change in, you can just commit directly, no PR needed


<!-- 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: --FYI Related to ? Steps to Reproduce: Set up a keybinding for with any Trigger the keybinding, search editor opens but none of the are used Same keybinding works in Stable Demo using a workspace file: Same result: (not involving OneDrive) ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Version: 1.53.0-insider (user setup) Commit: Date: 2021-01-29T21:49:22.151Z Electron: 11.2.1 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: Windows_NT x64 10.0. Log Window) with enabled: [2021-01-31 19:44:09.185] [renderer1] [trace] CommandService#executeCommand [2021-01-31 19:44:15.502] [renderer1] [trace] KeybindingService#dispatch Ctrl+Shift+G [2021-01-31 19:44:15.502] [renderer1] [trace] CommandService#executeCommand
Thanks, I can reproduce.
To verify: Add a keybinding like: Execute it, expect to see the context line input properly filled out.
Works for me (W10). Used this keybinding just to test more args (see below for a comment in the args): I suppose an issue should be filed on not working if it was intended to - it does properly insert the full path, ala but fails silently and button does nothing.
thanks, as far as I'm aware directly putting that absolute path into the entry would fail as well, correct? So not a new issue.
Yes, it fails inserting it directly into the arg (escaped properly) and in the view in the Panel input - although in Search view it does show the error highlight around the query box and hover error message. I will not file an issue on this.


There is no drop hover feedback in the Explorer, for example, when in Light+ theme.
Broken by:


I've seen this happen a few times now, and this last time it seemed to happen right after I closed a VS Code window. After that, I got the following notification in all my other open VS Code windows. ! Here is the Shared Process output
Going to look into whether we can wait for the process input to stop before actually killing the process for windows as another workaround for This process can take a bit of time now if needed since it's off the window being shutdown which has limited time to react.
It looks like we are using the same method as before where we indicate to dispose immediate. Perhaps it's different before because the window going down would more aggressively shut down its child processes?
we can consider bringing this in for the recovery build if we start seeing reports.
No, a few seconds after I open a second VSCode instance, this error message appears in both instances. It also happens if I open a second terminal in one instance
an extension may be closing the terminal, or it might be getting relaunched if an extension changes the environment (like the git extension will do when opening a new workspace). Does it happen if you open a new window and then wait 10 seconds before opening a terminal, such that extensions can activate?
I had the problem even with uninstalled extensions. But the good old "did you try turning it off an on again" helped. After a windows reboot, everything works fine
To clarify the scope of this fix since is still seeing lingering issues in insiders for this that we aren't able to nail down. Verified here means that the mechanism to delay killing the process on Windows for up to 5 seconds works as expected.
Don't know if this helps, but I've noticed that it consistently happens if I open a terminal in 2nd level (is that the vscode term for running vscode "inside" vscode?), after closing that 2nd level all terminals are stuck.
VSCode 1.55.0, the issue is still there. Single instance of VSCode looks fine, but starting another instance fires the warning almost immediately, breaking terminals in both instances.
It did not happened with git console but happens a lot with powershell but git has this other problem .
I've been getting this recently, though consistently throughout my day, while doing remote ssh sessions through the vscode terminal window. I open a new terminal and then use wsl2, and within wsl2 doing the ssh sessions. I experience this in both of the following VSCode versions: Version: 1.55.1 (user setup) Commit: Date: 2021-04-07T15:06:02.360Z Electron: 11.3.0 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0. Version: 1.56.0-insider (user setup) Commit: Date: 2021-04-09T09:50:06.816Z Electron: 11.4.2 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0.
for me, even single instanse of vscode show this message, if i want to restart "watch" task
Update:
Started getting this error in VSCode 1.55.2 after upgrading to Chrome OS v90; appears to cause the whole VM to seize. Persists after full powerwash & fresh VM/Code install, no exts enabled. :( UPDATE: FWIW, I have not experienced the issue on Chrome OS Version 90.0.4430.100 since updating to Code v1.56.0
I'm getting this error all the time since some months. If I start an npm script in VS Code this error occurs. So I had to switch to the git bash terminal (Windows). Hope this gets fixed... Still happens with 1.56.0
I am receiving this same error myself. I only have a few extensions installed and I've been extremely stable until I installed the PowerShell Extension. At that point I immediately receive the error that "The connection to the terminal's pty host process is unresponsive", as well as two others: "the language service could not be started", and "Loading the PowerShell extension is taking longer than expected. If you're using privilege enforcement software, this can affect start up performance" I'm pretty new to using VS and programming in general so I'm not sure what to do about this.
this should be fixed in the build as of today, coming to stable in a month or so.
Hey forgive me if this is a dumb question but the Insiders build is kind of like a "beta" build? So there's the potential for it to have issues in other areas? Just weighing the pros and cons of getting the extension working vs. potentially having issues in other areas.
yes it is, you may get some instability but also access to new fixes/features. But this issue is fixed (finally), it just won't be available in stable until early next month.
sounds like you have the accessibility mode on, click the "screen reader optimized" button in the status bar.
I get this all the time even in the Insiders build and with no extensions. It started for me right after updating to macOS Big Sur v11.4
this is the only know case where this can happen on macOS
I'm getting this issue all the time at Windows10 (so I guess it's not just related to macOS) I usually keep open plenty of VS code projects (usually 2-5 at the same time). TBH it just got so unbearable, I launch external terminals manually whenever it's possible. (So basically every time, except when I'm using a debugger) My system specs are Any feedback/fix suggestions are greatly appreciated
the new release which fixes this should be out next week.


We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.


Tracks bundling TS 4.2.3 with VS Code. This includes a
Should be in recovery and in main now


Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via


It doesn't look right compared to all the other placeholders: ! It's more noticeable when using editor font (font gets smaller): VS Code version: Code - Insiders 1.56.0-insider (, 2021-04-16T11:25:09.662Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --


See I think the best way for this would be for VS Code core to rename the terminal if gets a new request with a different name -- opened an issue for that Or, at least, try to use a terminal of the same name if one exists (which would be easier and probably more feasible since the is not writable.) Code pointer:
Also fyi
I'm going to take a swing at this. Here is my current understanding of the problem and I would appreciate any feedback or comments. The issue - Launching debug sessions in integrated terminal will open duplicate terminals. Solution - Code can attempt to find a terminal instance that has the same title as the launch request and is not currently in use. If located, it can reuse that instance, otherwise it can use the existing logic to create a new instance. I believe this should also address the concerns in as Code will stop spawning new terminal instances for repeat debug sessions. Please let me know if I have any misunderstandings on the issue.
Sounds good to me
I'm looking over the current code for checking out an integrated terminal and came across the minUseDelay for determining which of the terminals is available for use. It was a fix for . As I understand it, when compound node tasks were run, they would all try to grab the same terminal instance so only the first one to run would actually get the terminal, the others would fail to run. By introducing the minUseDelay, it insured that all of the launch tasks would get a new terminal instance. Once microsoft/vscode-js-debug is merged, each Node launch task will most likely have a unique name and therefore a dedicated terminal instance (ideally) which would mean we could always return the first terminal without a child process that has the same title and get rid of minUseDelay. Right?
Obviously if someone had two launch configurations with the same name (why?) this would fall apart.
We could even enforce name-matching and reopen the terminal if nothing's running in it and the name mismatches


<!-- 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.56.2 OS Version: macos big sur I am unable to find any record of someone else having this problem! Can someone point me to how I can start to debug this issue? Steps to Reproduce: a file with some text in it: using a relative path, the file opened is blank: opened using an absolute path, the text is correctly rendered: One hint is that when i edit the file (after opening with a relative path), vscode displays this error: ! Presumably, the code CLI is not using the cwd to open the relative path, and is assuming is a file in the filesystem root. I know this is super weird and am very eager to debug! Has anyone seen anything like this before? I have already tried disabling extensions, looking into logfiles etc.
/duplicate
do you by chance have a environment defined?
Aha! I do! How did that get set?! I've an unset to my shell profile but wondering how it is that this variable is being set in the first place.
I would like to understand how this variable can end up in your terminal environment. We do set it from application code here: But this cannot end up in the launching terminal imho... If you have any clues how you got there, please let me know. Also: I assume you are not using the integrated terminal right? //cc for terminal experts, maybe you have an idea how something we write from JavaScript can end up in the terminal environment.
The terminal environment code is a little complex, but except for cases like being set for extension terminals or getting contributed via an extension, this variable is meant to be sanitized in the terminal's process:
yeah I was also thinking that any prefixed environment variable would not make it to the integrated terminal, but would be good to ensure we have not regressed. However, here I actually think, people use the external (OS) terminal and still see set, which I cannot explain how that can happen from a process launched by the terminal.
Can confirm! This issue concerned using an external terminal to launch a vscode window!
is it at all reproducible for you somehow?
I see we only sanitize the external terminal env on Windows.
I think so! If I remove the unset from my zsh profile then the issue arises again, so it's reproducible in that respect. Is that what you mean?
how do you open terminals for using them? via a command VSCode provides or via Finder/Dock?
Usually the Finder/Dock variety (specifically, entering the letter "t" into spotlight and hitting enter without looking).
I cannot explain this issue then. If you are always opening terminals from the dock, none of the environment variables that VSCode defines should be there. Here is what I think can happen (correct me if you do something different): you open VSCode (either dock or terminal, doesn't matter) at one point you open a external terminal from VSCode (through some command or action) you type in that new terminal it fails to recognise the current working directory if now you open a terminal using dock or finder and try the same () it works
That all sounds right (I do sometimes open terminals from vscode!), except the issue arises even when the terminal is opened externally (via FInder). My immediate issue has been patched (via unset in zsh profile) and I'm alright to drop the concern if this is likely to be something extremely specific to my setup!
I cannot explain that. A terminal that is opened via finder can only contain environment variables as configured by startup scripts ( et al) to my knowledge. But happy to learn how this can happen otherwise...
Ok cool! I'm running some grep -r to see if anyone else might be sneakily setting this variable. Thanks for all your help!
I started seeing this issue after upgrading to MacOS big sur. Even when vscode is not running, the $VSCODE_ env variables are set when I open a new terminal from the dock
I think I figured out the cause of this for me at least. I have zsh set up to auto load tmux. so when a integrated terminal in vscode is launched it creates a tmux session and the env from that somehow leaks into other tmux sessions. I just disabled tmux auto loading and the problem disappeared.
Do you by any chance use tmux inside the integrated terminal in vscode ?
I do not!
maybe this is a red herring, in my testing when I run the command to open an external terminal, I do not see any of VSCodes environment variables appearing. Though it is true that we do not call the method in: Meanwhile I pushed to make sure we never on macOS/Linux, so this issue should not be present anymore.
are the verification steps in the original issue still valid/could you give some?
Yes the verification steps in the original issue are still valid one second. writing better instructions
to verify, close vscode open an external terminal and modify an environment variable in a repo directory starting with for example. open vscode and launch an external terminal from that same repo confirm that the environment variable you set is not present


Steps to Reproduce: Workspace and trust it code-insiders from a folder that is not trusted. -Shows the dialog code-insiders from a folder that is not trusted. -No warning dialog the window code-insiders from a folder that is not trusted. Expected: No warning dialog should be shown Actual: A warning dialog is being shown
Pushed a fix for this to main. Fix is low risk so we can take it as a candidate.


I recently came across CSS rule. According to the : I do not think we want the panning and zooming, but the removal of the 300ms delay sounds great to get a more snappy UI when using touch for e.g. action bars. Maybe worth a try?
I wonder if would even be the right thing, but not sure it removes the 300ms delay:
Interesting, I see we use this property already, e.g. in the list:
Worth experimenting with. do you remember why you that css property for the list? For now assigning to June, might push out due to lack of time.
Did not have time, pushing out to August, since in July I am on vacation
Probably for the 300ms removal.
Adding bug, so we get this verified. Steps: ipad. sure the touch behaves as expected in the editor and some views touch triggers context menu
feels pretty snappy to me!


Issue Type: <bBug</bI currently store some arbitrary JSON-serializable object using and updating keys. At the top level, my configuration variable is an array, and each element is a dictionary that contains some keys. One of those keys map to a value like this: This sets fine, and I can look in my workspace's to see all keys and values there as expected. However, when I try to get the value from the workspace configuration again, the empty string key and its value are missing, meaning I unable to retrieve the array with in it. So it seems VSCode filters out keys which are blank strings when reading workspace configurations, although it will set/save them. This is currently blocking a project I'm working on and should be a trivial fix. VS Code version: Code 1.57.1 (, 2021-06-17T13:28:07.755Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
I am sorry that I do not understand the usage of the API here and what is being done. Can you please provide a sample code snippet to reproduce the issue?
Here's a round trip example of me saving an object to the workspace configuration, and retrieving it. It shows all data is stored appropriately, but data is lost when reading it back if a blank string key exists. The message will be shown. If you comment out/remove the key-value pair in , it will instead say . So VSCode is losing data when obtaining data from the workspace configuration if you store an object which has a blank key somewhere (at any level of depth).
There was a fairly quick initial response here, but since then a good amount of time has elapsed. Has there been any progress updates or planning related to this issue? Can you confirm you now understand the issue given the above proof-of-concept? It should be very clear.
Thanks for the info. It is in my list of issues to investigate, I will try it out and get back to you.


And we could use in browser.
Sorry, just confirm, Would this will be released in July (the next) version?


Since it seems pretty simple to stop the server now, It seems like using the task as a way to run a persistent server is sort of unnecessary. Settings should have a way to toggle whether they want the task to run or not.
Verification steps: this setting (or set to ) ! the command palette or other means to open an external preview, when doing this, the server logging task should not run automatically. setting to , the task should automatically run with the external preview launch (default behavior).


Issue Type: <bBug</bThe user defined keybiding editorScroll command with arg property "' to': 'up'" repeats slower than "'to':'down'". The key combination doesn't seems to have influence. [edit] I tested it further, and found what triggers this behavior is the conjunction of this keybinding with the setting smooth scrolling : "editor.smoothScrolling": true, Windows and Linux versions have the same behavior. VS Code version: Code 1.58.2 (, 2021-07-14T22:30:16.440Z) OS version: Linux x64 5.4.0-77-generic Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (5)</summaryExtensionVersion ------ Bookmarks13.1.0 vscode-language-babel0.0.31 cpptools1.5.1 LiveServer5.6.1 ninja0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.458 --<!-- potentialduplicatescomment --
I could not reproduce. I tried with the following keybindings: The scroll speed appears similar to me for both keybindings.
I tested it further, and found what triggers this behavior is the conjunction of this keybinding with the setting smooth scrolling : Windows and Linux versions have the same behavior.
I can reproduce a slowdown. On my macOS computer, scrolling down went 114 lines down in 10s, while scrolling up went 100 lines up in 10s.
Not sure if my case is special. My issue was closed as duplicate of this one. Windows 10 here. On two completely different and unrelated machines but with the same VSCode user configuration. Scrolling down a document of 114 lines: 4.5 seconds Scrolling up again: 13 seconds This is a major slowdown by the factor 3!


Testing disassembly view on screen reader on an element, notice the following being read out "Can set breakpoint, Instruction address: 0x000000ea, Instruction: of" We need to imrpove this aria label: most important piece of information needs to go first, so that blind users can skip the boring repetitive part. So start with the "0x000000ea address, " it more concise, I think "can set breakpoint" is not needed here do not understand the last part "intruction: of", this needs to be fixed I think
will fix this.
Is there a way to update aria label via accessibility provider? Looks like it's set only when the element is rendered? I'm wondering if we can add/remove all texts about breakpoint and stack frame. If not, we should probably remove texts related to breakpoints. Also, it's a great suggestion that we should reduce the amount of duplicates. So I'll change it to . As for , it's likely the disassembly instruction you are looking at is . For now, each line in disassembly view looks like: Where there may not be InstructionBytes. For example, Will have aria label (currently) .
no, it is not possible to dynamically update the aria label. This sounds good, I would just cut it short to be


Testing the steps in the test plan item to create an interactive window I get a notification saying there are extensions on the marketplace that can handle . I feel like this is unnecessary noise
Which extension is it recommending?
The marketplace query is ext:interactive when I click on Search Marketplace !
I forgot that we had this but we automatically query show this when there are extensions in the marketplace that match the query . I'm curious about how this works, it seems overly sensitive since these extensions don't use that file extension, seems that it just matches based on keywords? I think the only way to avoid it here is to change the extension that the interactive window uses, which is probably fine.
Discussed with and even if we picked an extension that isn't yet in use, we can't prevent extensions from introducing collisions later. What about the following (essentially, parse the notebook URI from the cell URI, and check if it's an untitled://, file:// or vscode-remote:// URI based on the notebook URI instead)?
What will the interactive window be? It won't pass that check?
Is the motive here is to not show any recommendations for this resource?
Yeah we don't want to show the '.interactive' file recommendation because it's not actually a file on disk. The interactive notebook schema is 'interactive'.
Then we shall be filtering out in our recommendations logic as you recommended above.