Issue Type: <bBug</bWhen pressing F8 in editor without error markers in current file, tab will switch to another opened file with error. Is it possible to prevent tab switching when F8 is pressed and there is no errors in current file? VS Code version: Code 1.22.0 (, 2018-04-05T17:25:43.982Z) OS version: Darwin x64 16.7.0 <!-- generated by issue reporter --
It's caused by a change in behavior in 1.22 (). I think it's a change to the worse: it's very easy to get used to hitting F8 to get a quick feedback for whether the current file has any errors, and this change breaks this workflow in a very noisy way. It also punishes those who work on 'dirty' projects with lots of errors and prefer to concentrate on one file at a time. I think it would be great to have a config switch for "F8 checks all files/current file", or at least a pair of keyboard bindings for the old behavior. I'm actually surprised that it wasn't implemented with this change.
Understood. The goal was to keep the number of setting low, but I understand the different use-cases and muscle memory. Until then, a workaround, albeit weak, is to hit Shift+F8 which takes to back to the file.
Yeah, I agree that "convention over configuration" has its benefits, and it seems that the suggestion that caused this change was quite popular, but IMO this warrants at least a pair of shortcut bindings. Speaking about conventions, I've just checked that for example similar shortcuts in PyCharm (and I assume all other JetBrains IDEs) only jump through errors in the current file. One upside of the old behavior was that when the current file had no errors, there were no visual changes after pressing F8, and the cursor stayed where it was. Now in this case Shift+F8 after F8 won't even bring you back to that file, it would jump to another file with errors. "Go Back" or "Open Next Recently Used Editor" works though. It was also very useful that F8 would wrap around and bring you to the first error in the current file if you are working near the end of it and did some changes that e.g. made some imports or vars unused.


I think I was relying on this behavior 80% of times when I pressed F8. And now it's become quite difficult to predict whether F8 or Shift-F8 would keep you in the current file or move to another one.
We have the two old commands back (in addition to the new commands). That means there is now "Go to Next Problem" and "Go to Next Problem In Files" as well as the other direction. We have not changed the keybindings, so F8/Shift-F8 walks across the project and you would need to reassign the them to get old, old behaviour back.
Wow, I didn't expect this minor issue to get resolved so quickly! Big thanks to the team, it's really a marvel to witness the development of this amazing project.
Thanks to
I verified the new command works as expected, however is the name "in Files" really clear what it does. Why not "across Files"?
We chose "in Files" to match "Find in Files". "across Files" makes sense too though and might be clearer for users who haven't used "Find in Files" before.


mentioned that the diff editor experience is a little confusing because we don't explicitly state that the current editor is the modified one vs the original editor. AFAICT, there's also no way to jump between the original and modified ones. Is this correct? & I'd appreciate your thoughts here. Edit: action items: [ ] add info in help dialog about switch sides command [ ] get accessibility signals to work in original editor
There is the Diff Editor: Switch Sides command that moves focus to the other side. Maybe the wording could be improved. So not sure what needs to be done here? Feels like similar to the other issue you created about missing clarity in announcements on original vs modified.
Yes, I was unaware of that command. We should include it in the diff editor help dialog and include a default keybinding for when in screen reader mode as that's definitely something users would want to do IMO.
pointed out this should maybe be a tab stop if possible
I have the following keybinding, but there was no noticeable change (at least to from a screen reader user's standpoint) after switching into the other side. :
could you tell there was a focus change at all? Is there also no difference if you run the command vs use the keybinding?
Audio cues do not work when I'm navigating in the original editor. !


There's an unnecessary whitespace in "i18n/vscode-language-pack-". The whitespace after "command:" makes the link dead. !
you can add a comment to this string like so: to ensure that the command never has a problem like this. Notice that the example string has, in the Locked area, a at the start of it. This will make sure there is no whitespace between them.


Steps to Reproduce: text into PowerShell (with Terminal suggest enabled) see batched pasting behavior
maybe related to
Haha, I think this is it triggering completions while the pasted text is being send then kicking in. Pastes should never trigger completions so let's track that here.
When verifying make sure you're on macOS.


todays insiders do any inline chat query the edits are done live and shows inside the chat diff editor <img width="946" alt="Screenshot 2024-06-14 at 10 59 47" src=""


Testing When I was on the section of the walkthrough I clicked on "open remote repository" and it had the dropdown. I noticed that I couldn't just click outside the dropdown (back on the welcome page) to make the dropdown disappear and instead had to use the "esc" button. From my experience with other dropdowns if you click away from the dropdown it disappears and think that behavior would make sense here.
does the quick pick come from ? If yes, who should I direct this issue to?
Yes that's where the quickpick comes from. owns the desktop git extension.
could you please help with this? Thanks.
Clicking outside of the dropdown still doesn't escape. !
It turns out that the "Remote Repositories" extension does not leverage the picker from the git-base extension so the fix that I made is not relevant. To verify this, please download the latest pre-release version of the "Remote Repositories" extension.


On previous versions of VSCode (1.47) you received a message when attempting to save a file that was marked read only: ! As of 1.48, you receive a different message that lacks an overwrite option: ! When a file is simply marked as read only, retrying as admin is not an appropriate option and fails to resolve the issue. Please restore Overwrite functionality as it is very useful for us that use archaic source control systems that rely on making files read only. VSCode Version: 1.48.0 OS Version: Windows 10 (1903) Steps to Reproduce: a file with the read only flag set a change to the file the file Does this issue occur on the latest insiders build?: Yes Does this issue occur when all extensions are disabled?: Yes
Thanks, a regression we can probably fix for recovery.
Was just about to post this as well. This changed about 3-4 weeks back in VSCode Insiders as well if that time frame helps.
Works great, I have verified the fix on windows with read-only files.


<!-- 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:Version: 1.64.0-insider (user setup) Commit: Date: 2022-01-30T20:09:01.122Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: to install version 1.8.0 (pre-release) or 1.8.1 (pre-release) of the C/C++ extension using VS Code (possible) versus VS Code Insiders (not possible). FYI, we have 1.8.2 (non-pre release) and 1.8.3 (pre-release) released.
Before I was getting this dialog After the fix I can nicely install -verified !
Closing as it appears to have been merged into release branch and verified


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.46.1 OS Version: Ubuntu 20.04 LTS x86_64 shell: bash When alt-clicking in terminal (e. g. to open a file or URL), it gets filled up with lots of or : ! Steps to Reproduce: integrated terminal (or, for a more practical example, in a temp dir) -click anywhere <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Having the same issue in WSL with Ubuntu 18.04 when alt+clicking any link.
Looks like this is an issue where the alt+click feature (move cursor when clicking) is conflicting with links, only when is used.
This issue also occurs on MacOS, only with Opt+Click instead of Alt+Click. I thought at first that this was related to the Opt+Click on a detected link in the terminal (since that is an Alt+Click on Windows/Linux). But this truly does occur when Opt+Clicking anywhere in the terminal while a command is waiting for input. I can confirm that this occurs on my MacOS regardless of the value of setting.
set in , now the way you click url is cmd + click, and it wont happen again
nope, that only slightly changes the junk that is dumped into the Terminal, but it doesn't get rid of it... With (default): With :
emmm, you say is right, i just change a way to open url in vscode terminal to avoid echo ^[[D but not fix it , this also occurs in , if you use option + click. by the way,my final setting as follows (if , vscode still let you click url with option + click ) !
Oh! That's a great observation, Alt+Click fills the terminal with junk even in the standard MacOS Terminal app and also in iTerm2. Now, I am aware that is originally reporting this for Ubuntu. I checked my Linux laptop (Fedora 31), and Alt+Click in the standard system terminal emulator does nothing. It only occurs in VSCode's terminal.


But this still makes me wonder if all of this is system-level issues, or perhaps terminal "emulator" issues, not really a VSCode issue. Hard to know. But the Microsoft devs would know.
As for your workaround, thank you so much for that!!! I still don't see any change in VSCode's behavior when using , but changing definitely avoids the core issue. I hope you don't mind me describing in more detail... According to , "The Go To Definition and Open Link gestures will also respect this setting and adapt such that they do not conflict. For example, when the setting is ctrlCmd, multiple cursors can be with Ctrl/Cmd+Click, and opening links or going to definition can be invoked with Alt+Click." You probably did what I did when originally installing VSCode... I'm using to using Ctrl+Click in Linux and Cmd+Click in MacOS to multi-select files in Finder, items in a list, etc. So I set to be . However, this means that attempting to click on a link in the terminal (for example, an error message referencing the offending line in your source code) requires the use of the other shortcut (Alt + Click). Since it seems that Linux and MacOS have various strange behaviors when Alt + Clicking in a terminal, you are suggesting we switch back to the default . Now we'll use Ctrl+Click / Cmd+Click to follow links in the Terminal, avoiding all that ^[[D^[[D^[[D^[[D nonsense that sometimes causes the terminal to hang. For multi-selecting in the editor window, we'll have to get used to using Alt + Click for that, but in my opinion, that is better than having terminal hanging issues unexpectedly.
So to clarify what I originally posted to Alt+Click will still cause junk to fill the screen, regardless of the value of "editor.multiCursorModifier" setting. However, the above workaround means we don't need the Alt+Click anymore.
it's a feature that's sending keys to move the terminal cursor to the position of the mouse cursor. It needs support in whatever program is running in the terminal though which is why you might see the printed, we cannot detect this support though. The advice right now is to avoid alt clicking if it doesn't work in the program.


could you clarify... Is this a feature in Linux that's doing it, and vscode is not able to see that it's happening? Or do you mean this is a feature in vscode to move the cursor, and vscode is not able to tell if the terminal shell supports it?
it's a feature in , you can see the PR here
what an interesting feature, and I never even knew that was there. Thank you for the perspective. I looked through that PR and searched the settings in VSCode; unfortunately, there doesn't seem to be any way to disable that cursor-moving feature.
Yeah, that feature might be useful but the ability to disable it or, even better, change a modifier to another one (so that it doesn't conflict with the “open file in editor” one) :)
I'm seeing this happen regardless of the setting, on Ubuntu 18.04
Just to inform that is waiting for a community PR for this.
Um, how is project related to VSCode?
Hey great question. The package is a direct dependency as you can see here: means that the behavior will first have to be patched in the underlying package and then it will likely be made available through a setting in VSCode in a future release.
I opened a PR with which would make it possible to disable this feature:
The PR was merged. What is required in order to pass the new option to in VSCode?
I meant no offense; perhaps my "Um" conveyed an unintended tone. I was simply asking, as a non-developer user who has never looked through the VSCode codebase, but is experiencing the OP's issue... how an xterm project would be blocked by an issue in VSCode.
Ah sorry, I assumed you were familiar with the package because of your previous posts (and although it’s no excuse) I’ve learned my lesson and will henceforth refrain from posting prior to my morning coffee - the tone was indeed unnecessary. The original message has been duly modified.
So, does anyone know how to disable it in vscode?
The problem with has been fixed. Could you kindly suggest what are our next steps here?
Sorry, I've been out for a while. We updated in vscode yesterday, so the next steps are to expose it as a setting in vscode. Searching for a similar setting should show how/where to do something like this.


if no one picks this up from the community it would be a good change for you in debt week.
Thank you so much! :tada:
Once it's released in insider's, to verify, set
Hi! Thanks for fixing this Just to understand, may I ask: Why will the future setting default to true? One year ago the problem didn't happen on a fresh install, so why not fix the regression Why is this issue closed but the bug still exists in the latest Insiders? Thank you
As far as I understand this is a new feature in . The special characters only get displayed in certain situations (probably when the running command prevents the shell from moving the cursor). Also the default setting for multicursor is <kbdCtrl</kbdso you would not use <kbdAlt</kbdnormally unless you want exactly this new feature.
I just want to open a file from within the terminal out of the box ! I typically do when running in watch mode On Linux the shortcut is Ctrl+Alt+Click even if the screenshot says otherwise Can users do this without having to find this issue and the corresponding setting? Also, when the filling happens, often the terminal gets stuck, I cannot kill the process with anymore, should I open another issue about this?
Thank you for voicing your concerns - I have to agree that OFF should be the default behavior as Alt-Click is mapped to the file open command in VS Code, and ON is therefore most likely to be the undesired behavior.
<kbdAlt</kbd+<kbdClick</kbdis not the default. The default for opening links and definitions is the one key not used by the multicursor modifier which is by default <kbdAlt</kbd. You can confirm this by looking in the docs or viewing the default value in the settings UI.
Just tried in Portable mode on Linux with no settings nor extension installed. The problem still reproduces. fixes the problem but I'm not sure how new users would know about this
You may be misunderstanding what this option attempts to solve. It's unfortunate that the name was chosen for the setting, since the setting is not about vs. , but rather about enabling or disabling the pseudo-mouse-cursor-moving feature in xTerm entirely. I concur with go back a year and VSCode didn't have this annoying broken "feature" of the terminal.


Now that we've recognized it's broken and updated the xTerm dependency to a version that allows us to get rid of the broken "feature", the default behavior from a VSCode perspective should be to have the feature disabled, since we really never wanted it in the first place. Also, as pointed out, when the typical user hits this strange behavior, are we just expecting them to "VSCode terminal fills with ^[[D^[[D^[[D^[[D^[[D^[[D and locks up" into Google and hope for the best? This "feature" does not work 100%. It should be considered beta/experimental and disabled by default.
I can attempt a PR that Changes the setting name to perhaps (something that doesn't mention vs. ) Default value of But I'm not sure how the open-source community handles requests like this. Any advice on how to proceed? Or is this a closed/merged PR and conversation over?
After re-reading this I realized this is capturing the bug (alt+click conflict) as well as the feature request (new setting), I thought they were separate issues. to fix let's: Override the value of to be false when . Document this override in 's description, that also makes the name correct as this feature only ever works on alt+click. I think that name is good as it aligns with . we're a little tight on time as we're closing in on the end of the iteration, can handle it
Thanks, and I'm really looking forward to being able to click links in the terminal again.
/verified


<!-- 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. --- VS Code Version: 1.54.3 OS Version: Windows 10 20H2 Steps to Reproduce: a file with the same words with different casing a find replace with preserve casing switched on the preview does not work properly (and the replace also doesn't) preserve casing does not do anything ! I'm pretty sure this worked as expected before.. <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --
The feature came via
This case is not handled. When the match is mixed-case and starts with a lowercase character, I think the replace pattern should have its first character lowercased. Would take a PR that adds this.


Testing a notebook and add a markdown cell with content at the top the replace widget and find an existing string in the markdown cell focus somewhere else in the notebook, then press ctrl+f to focus the find widget markdown cell is bumped up out of the view !
you found good bugs!


Originally posted on without success. <!-- 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.69.2 OS Version: linux Steps to Reproduce: project has files like "Bar`1.cs" to represent generic types, as is done in the dotnet SDK build task contains "problemMatcher": { "base": "$msCompile" } When such a file has errors/warnings, I get this: is fine. But I cannot control-click on that filename to open it. The file's path is not underlined as normal - there is a clickable part before the bactick, and after. Someone from SO offered this guess: " probably backticks are not part of the regex that matches the filepath, or backticks are not in the w regex set"
I can reproduce this, it is correctly validating the link, but it then recognizes it as a folder: ! I guess nothing happens if Test doesn't exist? As for the fallback "word links", you can support this type of link if you remove backtick from word separators:
This falls apart when converting the link to a URI in !
And that happens because backticks aren't allowed in the local path regex:
Thanks


VSCode Version: 1.19.0 OS Version: openSUSE Tumbleweed (Linux) Steps to Reproduce: "version" in no entry, but should As enhancement it would be nice if the show-all-command would have an entry to display the Visual Studio Code version (I know that I could pass the flag on the command-line). Such a feature exists e.g. in Emacs, where it is possible to enter and get the current Emacs version displayed.
I'd like to take this up. Any pointers? far I though to extend the current to execute and show the result? Or is there a place where we store version globally? we open up the and show the result of there?
No need to execute , that information can be obtained by requiring . Output is good, but a is better.
raised a PR . Currently in the action under . Any better section to add this in?


<!-- 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.45.1 OS Version: macOS Mojave 10.14.6 Steps to Reproduce: Recently, the autocomplete auto import text has become cropped so short as to be completely useless. In many cases over the past couple of days, I've had the option to import 2-4 same-named classes/components. Normally, I can select the correct one based on the additional text Now the package name is cropped to the same text for all options: This makes the auto-import feature completely useless (one of the most important features in an IDE). See example: ! project with React Native + React Navigation in 'Header' and cmd+space to open autocomplete (It may be that additional conditions apply, for example what the other options presented in the list would be.) <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Press <kbdCmd</kbd+<kbdSpace</kbdagain to see detailed info for suggestions. Changing width of suggestions box already tracked in and
Or just remove this completely useless feature which was around January 2020.
Agree with and others, that current implementation does not make too much sense, and adding this description to the same line as a code snippet makes snippet name and description basically useless.
Since was closed (with reference to some obscure problem from 2017), this ticket is the closest I could come to the new issue. The suggestion-list window is just too narrow for the info that is being presented there. Introducing a new feature to put more information there made the situation worse. It's simple not enough room to read the fully qualified names many are using. Snippets for PS/XML and other languages. (Sample image included) Alternative fixes : Allow us to turn OFF the 'descriptions' in column 2 of the snippet list. Allow people to customize the width of the list-window. Roll back the feature that gave us 2 columns instead of just 1 column (with the name only). I sincerely need a workaround or fix. Very frustrating. !


The autocomplete just got even more useless! Here are the options that I see (cycling using ctrl+space): <img width="735" alt="Screenshot 2020-06-25 at 10 54 43" src="https://user-"<img width="761" alt="Screenshot 2020-06-25 at 10 55 24" src="https://user-"Previously the detail screen showed details on the option, not details why this suggestion is being provided. What's the use of that to a developer? Have I unknowingly enabled some obscure autocomplete-debugging mode or something?
Yes. Press to toggle the suggest debug mode
does nothing. I couldn't find anything similar in the command palette either nor by googling.
Aha! To en/disable the suggest debug mode (on European keyboard): the suggestion dialog (i.e. the same hotkey as for (un)commenting a line) (I figured it out by seeing that on a US keyboard is .) So if you accidentally have the suggestions open when trying to comment out a line, you'll end up with a useless autocomplete system and no idea how to make it work again. May I suggest that a functionality that is useful to 0.01% of users and causes a lot of confusion for 99.99% if accidentally used would not have a default hotkey? It could be clearly labeled as "Toggle autocomplete suggest debug mode" or similar in the command palette, which would be just as easy for suggestion debugging cases but users would not accidentally trigger it.
Just a heads-up that for the suggest widget and its details parts are going to be resizable. See This issue will all about the specific TS case and how to improve the situation for auto-importing modules
There might be more to it and things I don't know esp. the doc for says it might not be human readable but it kinda looks nice already. <img width="584" alt="Screenshot 2020-11-02 at 12 37 51" src="https://user-"


similar to the 'open in data viewer' command from the jupyter variables view, we should allow extensions to contribute a view for a variables for specific language/types on the built in tree view.
That would essentially be number 6 in this screenshot from the Julia extension , right?
Same idea, either with an icon like that or through the context menu on that item. In the jupyter extension's case, we are planning to allow contributions for data viewers from extensions that didn't necessarily provide the variables.
Cool. I think icon and context menu would be great ;) It might also make sense to think a bit ahead there: there are probably some kind of viewers that are relevant for a lot of languages (tabular data, plots) and others that are very language specific. From our end, we would love it if VS Code at some point gained a generic tabular viewer, and a plot viewer that we could utilize and get rid of our custom implementations as well :) So maybe some kind of API design where in the future one could hook into a as of yet not existing generic tabular/plot viewer.
Example implementation here The menu contribution point name will likely change names when we expand the usage beyond notebooks, but any needed migration will be pretty straight forward.
I created a sample extension and cannot see any variables showing up. Do I need to enable something in VS Code for this feature to work. I couldn't find any settings/experiments that had to be enabled for this.
Found that I needed to enable a VS Code experiment (I was looking for Jupyter experiments). Not sure the API is useful in its current form. Currently when i create a viewer for DataFrames, lists, objects, anything I do not get the name of the variable. Hence I have no idea what I'm looking at, all I get is a value, and thats basically a stringified version of the value. Thus its not really possible to create any viewer, unless of course I'm missing something here.
Moving to March for now. Feel free to move back to February if the issue has been verified or once steps are provided and the issue is verifiable in the latest Insiders. Edit: I confirmed using the sample extension that the viewer does not report the variable name.


verification: sure you have jupyter and python extensions enabled the notebook variable view the or create your own some notebook cells that create variables and open the debug sidebar to see the notebook variable view that the command contributed to the menu is provided information about the variable ( should be the expression that would access that variable)


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Stable & Insiders OS Version: Any Steps to Reproduce: Jupyter extension the following cell against a Python kernel The expected output is fairly simple: ( can appear some where in the middle) However VS Codes output is incorrect We are missing the line breaks (looks like this PR seems to have broken that) (using blockinline-block` fixes this). We have duplicate entries (as you can see below, we have multiple times) i think this has to do with the fact that we're trying to re-use the previous output and append the new stuff into the previous output element Note: This can be repro'ed in stable as well, but if i were to remove the code that tries to append to the previous element, then it looks as expected. Not sure when this part of the code broken though. Didn't go through the change log to determine this, you might have a better idea.
note that this is from the test, so that could probably be modified to check for the fix
It looks like this was briefly solved (at least for me as I reported in ) but the problem is now reappearing.
I agree, I can replicate the same bug again, hence reopening this issue. Looks like subsequent change regressed the fix.
seems to be a worse regression now (only in insiders) and repros without needing to do anything with background threads (unless I just have some bad setting): !
I'm seeing something similar with the JavaScript/tslab notebook I use for teaching async and promises. Previously, the output was inconsistent across runs with sometimes missing or duplicated output.


Now all the expected output is present but with line breaks appearing only after some async code (e.g. ) is executed. <img width="661" alt="image" src="https://user-"
I reproduced output shown by above with missing new lines in code-insiders at ~14:00 UTC +1 (CET). In a code-insiders session that has been running last 24 hours. Restarting code-insiders approximately an hour later (15.00 UTC+1), the output is now shown with correct line breaks, see screenshot below. Version: 1.75.0-insider (user setup) Commit: Date: 2023-01-09T05:29:27.679Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes Output after code-insiders restart: !
confirmed that this no longer seems to reproduce on the latest.
Adding label as confirmed above.


From ! It took me a while to be able to use Copilot again. Here are the steps I took (also captured in the attached video): Reloaded VS Code Clicked "Show Extension" from the toast above, I'm brought to Copilot Chat extension in Extensions view Clicked "Uninstall" for Chat extension, nothing would happen Decided to instead search Copilot in Extensions view (thought maybe I was having issues by trying to uninstall Chat without touching Completions, though I would've expected a toast telling me that) After searching, the Copilot extensions automatically start to update Need to restart just Copilot (not chat), so I click to restart I try to uninstall Copilot Chat again, but nothing happens again Reload VS Code again Search for Copilot again in the Extensions view I can now uninstall Copilot (though I initiated the uninstall from the Copilot extension rather than Chat)
Verification steps are in


PR introduced a max-height on comments, which goes against my team's use case when using the . Since our tours have animated GIFs that support our hands-on coding labs, the reduced max-height makes it impossible for a user to see entire images in the comment frame at once, which imposes a negative learner experience. (See: for comparison across versions). Proposed feature is to allow a user to set a max-height rather than imposing a max-height.
I also think it should be settable through the API. My original on the PR has a comment exchange with about this at the place where I originally hardwired it.
Generally we try not to add API unless we see a clear case for having it. At the time suggested the max height I wasn't aware of a use case that would require a comment peek view to have a larger size. your case makes sense, and makes the case for having API for this. I would make this API rather than user configurable.
Yes, making the max-height configurable via the API makes perfect sense, since any extension can be configured with that functionality to set a max-height attribute that makes sense for the use case. Would the default behavior go back to expanding the height with the content?
I'm not sure yet which would be default. I will discuss with our UX folks and see what they prefer.
My humble preference would be to adopt the old behavior as the default. Though the CodeTour extension is open source, it’s only seen one update in the past year. My team has a stale PR from 2021 on the CodeTour repo that was never commented on, so I’m afraid that even if we opened a PR with a fix for the max-height problem, it might not ever get accepted and merged. On the other hand, my team has been discussing forking CodeTour so that we can control the addition of new functionality and bug fixes.
There wasn't enough interest in adding API for this, so I the user setting .
thanks! Is a boolean? If so, is the default (maintaining the as by default) or (no defined?
It is a boolean and the default is true, meaning the max height of a comment will be 20em.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected.


If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified Works great! Thanks!
Thanks for verifying!


<!-- 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.72.2 OS Version: Windows 11 / MacOS Monterey Steps to Reproduce: . the icons using the command. that the arrows are still not hidden. The vscode-icons extension has a setting called , which, as the name suggests, hides the explorer arrows next to the project folders. This look something like this: ! With the introduction of the tree mode in the search panel, I would not have expected to see any explorer arrows there. Alas, the panel has the search arrows, regardless of the extension setting. ! I already opened an issue on the vscode-icons repository, which you can find .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.72.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Still happens on 1.72.2!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No, this is an extension-related issue that arises across extensions with walkthroughs <!-- 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.91.1 OS Version: Windows 11 Extension walkthroughs are not launching upon install. Expected behavior: walkthrough launches automatically upon install. Tested on C# Dev Kit extension and Python extension. Seemed to work in 1.90.0 but does not work in 1.91.1. Steps to Reproduce [Windows Sandbox]: a Windows Sandbox Edge and download VS Code (stable) from the VS Code website the C# Dev Kit extension. Note: Upon install the walkthrough is supposed to launch automatically. This is not happening, but I can manually open the walkthrough using these steps. command palette. command 'Welcome: Open Walkthrough' 'Get Started with C# Dev Kit' ! steps 3-7 with the Python extension. Same behavior. Steps to Reproduce [VS Code stable and VS Code insider]: VS Code C# Dev Kit (if you have it installed) VS Code C# Dev Kit extension. Note: Upon install the walkthrough is supposed to launch automatically. This is not happening, but I can manually open the walkthrough using these steps. command palette. command 'Welcome: Open Walkthrough' 'Get Started with C# Dev Kit' steps 2-7 with the Python extension. Same behavior.
closedWith
using the steps above, I am not seeing the walkthrough open when I reinstall the extension
Was just talking with about this- if you've had it installed in the past, it won't work, but for me it works in a window with a clean user-data-dir


To prevent issues like this: and like this and many more
this is a good idea, I've been getting tagged in a lot of these recently. it's difficult to say what exactly the limit/requirements should be though. atm we require title and description (the rest of the info is fluff that is auto included). Maybe force description to be longer than 10 characters?
We can start with 10characters enforced on both title & body and see how issues keep coming. We could also maybe crowd-source ideas from the team


While testing . VSCode Version: Code - Insiders 1.15.0-insider (, 2017-08-01T05:07:59.267Z) OS Version: Darwin x64 16.7.0 Steps to Reproduce: 3 terminals from the command palette <kbdArrowDown</kbdto the last terminal in the switcher <kbdTab</kbdto rename the terminal -keyboard focus disappears from the input box (and seems to be nowhere). I need a second <kbdTab</kbdto move the keyboard focus to the rename action in the selected row. A single <kbdTab</kbdshould suffice.
This is also an issue with task configuration


Screen reader and low vision (or other accessibility) users often use our menu items to discover things. We should include a menu item to open the getting started walkthrough under .
and WDYT?
Seems reasonable to me. The title suggests that it could also be a walkthrough, or part of an existing walkthrough. The tradeoff there would be discoverability.
I see an error in the console when opening accessible view from that welcome experience:
Cc
Related:


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce: a ntoebook click on a cell, and notice the order of the cell actions same entries for regular editors is All places the order is We might want to consider changing this.
is this a papercut or ux issue I'm concerned that changing this now could result in issues due to muscle memory (i.e. users being used to this order). Thus changing this might not be a good idea, then again, i don't think it is. Thoughts?
discussed with team, Lets change this


Testing Show extension display name instead of extension id. You can also make them links to open the extension editor. <img width="522" alt="image" src="https://user-"
what's the right way to do this? I had a look and could only see async methods to do this which seemed odd to me (and would require some refactoring to get the tooltip to work with async).
1 I see this as well
There are multiple ways depending upon the source of this extension id. Since it is a running extension, I would prefer to use this api since you do not want to have async
thanks will use that. You don't have an id -name map to avoid iterating over it multiple times though?
There exists one, but it is async


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


/gifPlease
Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, files are preferred as they are displayed inline on GitHub. You may find helpful as a browser-based gif recording tool. If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording ( in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue. Happy coding!
The terminal's usage of may have regressed?
The issue I'm seeing is no longer seems to flip the terminal link modifiers and column select modifier. Additionally the cursor isn't showing anymore when using column selection.
Actually I don't think it ever flipped the column select modifier
When is set, alt+click still opens fine. After the crosshair will be working as intended, the link pointer cursor will override it correctly.
! I can still repro if . Is there something else I should set? It works fine if I set .
Since verification steps are needed and is OOF, this issue will be moved to the February 2024 milestone.
in case you know the verifications steps.
I verified that regardless of the value of , I can open links in the terminal with ctrlCmd and holding alt allows me to do column selection, which I believe is by design.
It turns out that the bug has nothing to do with the cross cursor. The real cause was extension host keep crashing after a few minutes after opening a big TypeScript monorepo.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.72.2 OS Version: macOS Monterey 12.5 Steps to Reproduce: custom HISTFILE (example custom HISTFILE per project) integrated terminal (zsh) in VS code will be /Users//.zsh_history instead of custom history file What i use: vscode I found that the changes made to break the ability to use a custom HISTFILE because the HISTFILE is always overwritten by these changes:
Trying to set HISTFILE directly in settings, fails the same way HISTFILE is always set to
Hi I have opened a PR with a possible solution to this issue. Let me know, if it solves the problem.
thanks a lot Sorry for the stupid question, but do you have any macos silicon build that I could try ? I never contributed to vscode and finding how to compile it from source may take some time
Unfortunately, I don't have a Mac, however, I use Linux with Zsh so I could reproduce the bug and I could test the fix on it.
I think this might be related to with McFly.


Type: <bBug</bTo reproduce: VS Code a folder and choose a git repo with changes a file with changes and notice the gutter is shown a folder to the workspace and choose a git repo the gutter is still visible close the file and reopen it Expected behavior: the gutter is shown Actual behavior: the gutter is not shown this may be related to . actually pretty much the same issue. However a reload (I assume that is ) doesn't help in this case. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-10T05:24:23.805Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for the @ mention and for the repro steps!
Also having the same issue. Installing a previous version () helped to solve it (temporarily, until it's fixed).
Folks who are seeing this issue: Could you please install the latest insiders build and confirm that you no longer see the issues there?
Yes. The issue resolved in the latest insider version.
Related Stack Overflow questions: I'd prefer using this one as a duplicate target on Stack Overflow since it's asked much cleaner.
Thanks for confirming that the issue is fixed in insiders!
Wow, so it was a bug, not an actual symlink-issue as I thought. So happy now, thanks! Context: I'll try the fix/update.
This issue seems to be fixed in version 1.76.2 for git repositories, however it is not yet fixed for Mercurial ( extension).
I am still seeing this bug in
can you share some exact repro steps that we can use to reproduce the issue?
I can't reproduce the issue on a new clean git repo, hmm
Im having the same issues, reinstalling helped fix the current file having the issue but any file created after wont show the indicators. Disabling extensions wont work either and Im not sure on how to reproduce the steps Version: 1.76.2 (user setup) OS: Windows_NT x64 10.0.


Testing If there's no error case, I now need to return something like:
Hi we have branched off from today, so I am pinging about the milestone here. Would you like to make this issue a candidate or move it out to the milestone?
Moving to March for now. Feel free to move this issue back to February if it turns out to be a candidate.
It's already a , which allows 'undefined' but not void. Is it weird to say ?
+1 on this, I have to explicitly today


<!-- 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.39.0 OS Version: Linux RHEL 7 Steps to Reproduce: code with --no-proxy-server flag "Option 'proxy-server' is unknown. Ignoring." error appears. I think the proxy is still disabled, the error message is simply wrong? If I run without the flag, I get prompted to log into the proxy, if I run with the flag, the proxy appears disabled (no log in prompting) but the error appears on the command line.
I suggest to include that fix in the recovery builds to avoid any confusion due to the message printed by the cli. The cli says for all chromium options, but in fact, they are used. My understanding is that most of the chromium options are not for the end-user except and the proxy settings, so I these to the list of the valid (supported) args. Please speak up if I missed one of the options. PR is
This is not fixed in the latest stable release candidate. The reason is that the PR was actually not merged and this issue was closed erroneously
The discussion in yesterday's standup was to take this, so we've now merged the PR...


<!-- 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. --<!-- 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: version 1.76 OS Version: Windows 22H2 Steps to Reproduce: a debugging session, and click on the "Edit Condition..." button (the pencil). Ensure that the cursor is in a window with a short width. ! appears. ! window. The text appears to be cut off. ! to look like this: !
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.76.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Probably we need to relayout that breakpoint editor when the parent editor width changes
I'll get it done
My phone is not working unless connected to wifi I need serious help as I am to be in GA at 7am I realize this phone is outdated a Motorola it is used but my Apple I cannot see the screen on it and I obviously can't carry my pro on the road cuz it is not activated can someone help me you can record everything l do not care I need help
All kids are grown? The Samsung used to belong to my son now belongs to coworker On Sun, Apr 9, 2023, 8:29 PM Amy Scarbrough


Running Extensions context menu -in extensions have disabled menu for !
I don't remember creating the "Report Issue" action, so I don't think I own it. Maybe you did this?
Yeah I did this. Code pointer The issue here is that the JavaScript Debugger does not seem to provide the repository URI in the Thus the action gets disabled here can you maybe provide the repository information of the JavaScript debugger so this button gets enabled here?
There are multiple built-in extensions with disabled menu item, like, , , ... (Not only js debugger).
Yeah none of them have a seperate repository. So you shuold just file in vscode repository However for js-debug we have a sepearte repository so it makes sense to have that action enabled.
I have an repository in the js-debug I think the issue is actually the line above that exclude built-in extensions: I don't think this line is necessary. Deleting it will just have people who open issues on extensions in the vscode repo open them here, which is desirable.
Yeah, agree.
Report Issue on opens this repository . Some other built-in extensions still have disabled menu item.
This action is available only for few builtin extensions (jsdebug, emmet) and this action reports issues in VS Code repository. IMO it shall be consistent and show this action for all builtin extensions. If repo is not found and extension is builtin we shall enable the action and create issue in VS Code repo. Let me know if you agree, if so shall I reopen this issue?
Works for me and let's reopen. I am opening this for community contributions and adding help wanted
I think there are two ways to do it. attributes need to be to the of each built-in extension In the , judge the extension type. If it is a built-in extension, set the base url to I think 2 is better
Yeah let's go with 2. Sounds like a good approach to me
I have submitted a PR, please help CR
thanks to your PR this is now fixed.
Fixed for built-in extensions, though just a note that it's still disabled for the github.codespaces extension.


<!-- 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.34.0-insider OS Version: All Steps to Reproduce: This issue is difficult to reproduce as it requires a special version of an icon theme extension that supports theme reloading ().
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.592 --- <!-- score: 0.528 --- <!-- score: 0.482 --- <!-- score: 0.45 --<!-- potentialduplicatescomment --
Being a maintainer of the extension, I stumbled on this issue while testing the implementation of this feature on our extension. As I'm the author of the theme reloading feature, I pinpointed the cause of the bug. The reason for it is that on we don't call the event, resulting in the not getting notified. The solution is to add a call to on the function. Although much of the code execution of the is overkill when we reload the icon theme, it has no side effects. Possible actions are: and extract the calls to telemetry and event triggering to separate function and then use only the extracted function nothing and just add the call to and don't care about the redundant code execution since it does not have any side effects. I'm more than willing to provide a PR according to the chosen action, although I suspect that you guys prefer action 2. Awaiting your response.
I like the suggestion of calling . PR is of course very welcome!


<!-- 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. -- (merged as ) and other colors relating to the foreground of icons in the activity bar when it is configured to be at the top of the sidebar. I'd like colors for the activity bar background when it is at the top. Specifically, I'd like these new colors: to set the background of inactive icons and the region of the top activity bar not occupied by icons, corresponding to . to set the background of the active icon in the top activity bar, corresponding to . See also , .
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
! vscode 1.86 Windown 10
We two new color. One for the activity bar background when it is set to the top / bottom () and one for the border between the activity bar when set to top / bottom and the views ()
Added
Verification steps: activity bar location to the top the following colors in of your file and see the color change in the activity bar at the top : Background of the activity bar : Border color between activity bar and the view container : Background color of active activity item
Thank you very much for your efforts! What needs to be is: Can you add the following color setting items: ! This color setting project has been a long time coming, but no one has ever made it happen.
Can you create a separate issue for this? These are colors that we don't yet have for the default activity bar, right? In that case, please also include a very short description for each color in the issue.
No need at the moment, thank you very much!


Due to how colors are blending together. Notice the color of the input and the selection of quick open and how the black background blends into the viewlet, so the input looks misaligned. <img width="1035" alt="screen shot 2017-06-27 at 15 23 22" src="https://user-"
Hello, I'd like to help with this! UPDATE: I believe I've fixed the issue by changing the "" property in the monokai theme from "" to "". Before the change: ! After the change: ! Shall I submit a pull request? Thank you!
Yes, a PR would be great!


<!-- 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.78.0 OS Version: Windows 10 (x64) Steps to Reproduce: "Centered Layout". the editor by independently moving its sashes (holding down Alt). and restart VS Code. The position used to be remembered in previous versions, but starting with version 1.76, the position gets reset on every start. Only the width is being remembered. It's still broken in the current insider build of VS Code 1.78.0.
Do we already know, which commit causes this regression?
I looked through the commits for 1.76.0 and I suspect it was .
Yeah, it is solved for me.


This throws the exception below. This happens when logging objects without prototypes, e.g . Instead of the property access should be used


I am forming an openEditorAtIndex command using the following syntax: '' + index 1-9 work correctly (and are default keybindings already). Would it be possible to add support for any index? I currently need to use this command if <= 9 and if 9, I have to go to index 9 and then next count - 9 times to get to the desired pane with a risk of wrapping around
trying to understand the scenario here, I do not think it makes sense for VSCode to introduce commands for more indices because this number is pretty much unlimited. Can we have another command that just goes to the next index, from the current one and you could use that instead? E.g. does it work if you use ?
Lines 55 - 89 are what I use to be able to go to any tab My case here is what I am trying to avoid Ideally I could do and never think twice about it The problem with using nextEditorInGroup is that I have no way of knowing the max editor number index, so if I say go to tab 10 and there are only 8 tabs, the current logic will try to go to tab 9 with the absolute exposed command, then use a nextEditorInGroup command.
that switch-case statement looks quite horrible, an alternative would be for the workbench to expose a command where you just pass the index as argument into. We already have that for other commands, e.g. see the "move editor command" () Would that be better?
That would work for me too! It is not very urgent since I don't think people navigate to tabs they can't see very often but for completeness it would be nice! Thanks!
Great. I would accept a reasonable small PR on this feature request.
I'll try to write a reasonable small PR for this :)
landed, thanks to
Some steps so I do not have to read the whole discussion? What command with what arguments should do what now?
here you go: write an extension that executes and verify the tab at that index opens.
Works nicely. Though the counting starts from - might be a bit confusing.
Ah yeah good point, but I think that is fine.


<!-- 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.63.2 OS Version: macOS 12.1 (ARM64) I can't get more than two launch configurations to run at the same time. I can run the rest of the configurations afterwards and everything works (debugging, etc.). StopAll will also only close the two configs that were successfully launched. I haven't found any mention in the documentation that this is limited to two launch configurations. I've only seen that two are used in every explanation or tutorial about this feature. Steps to Reproduce: multiple launch configurations in multi-root workspace inside of project roots. launch configurations to compounds in .code-workspace file debugging two of the many compound configurations will run Examples:
VS Code imposes no limit on number of launch configurations in compound config. I've verified this with this simple example project (which only relies on built-in VS Code features and not third-party extensions): unpack zip file in VS Code use "Open Workspace from file" to open workspace file inside folder switch to debug viewlet in debug config dropdown select and run "4 Debug Session" Observe: 4 debug sessions: <img width="1384" alt="CleanShot 2022-01-26 at 11 45 23 src="https://user-"Maybe there is a limit on dotnet/coreclr?
Thank you for taking a look at this After inspecting your configuration and some research in my own project I was able to isolate the culprit. The problem arises when you try to make use of inputs in the launch configuration.


I created a demo for download, the process is the same as you described above.
thanks for the additional info. I was able to create an even smaller repro without a multi-folder workspace: unpack zip file in VS Code open the "compound" folder switch to debug viewlet in debug config dropdown select and run "Compound" Observe: only one debug session starts
Is it possible to implement the input that allows blocking another input request until the first input has completed? Latter quick pick also cancels former ones so it needs to be fixed as well.
Do you own the configuration resolver Is my solution correct or should the service guarantee correct behavior when calling into it multiple times simultaneously?
your solution looks good. The configuration resolver service doesn't currently make any guarantees about what will happen if it's called into multiple time simultaneously. I would also be fine with the change being in the configuration resolver service though. We can change it's behavior so that it does make that guarantee.
Yes, making the fix in the configuration resolver service sounds better.
This fix doesn't fully cover our scenario (tested in latest insiders). This fixes case, and yet we also prompt for input or quick pick in , which is not covered in this PR. Is it appropriate to wait for as well?
Good point. Yeah, I think that makes sense.
I guess we'll need Queue's for and Would you like to make the changes, or should I work on this?
I can take care of it
This gets a bit weird. Since one launch config can be calling into the variable resolver (the first fix) while the second is calling the extension config provider, we also need a queue that orchestrates those two things. Easiest fix is to start launch configs one at a time instead of kicking them off in parallel: and I'm not sure what other impacts that could have. Perf to some extent, probably. So I wonder whether we would ever consider queueing calls into the quick pick control so that invoking the quick pick while it is already visible would wait instead of cancelling the first one as it does currently. Example of what I'm talking about (but in my real situation it's an extension competing with code in core): This extension code only shows one input box, while we could have the second wait for the first to complete. This could possibly be a breaking change for some extensions though, so it could be enabled with a flag.


As an easy workaround, I can put a queue around calling into the vscode variable resolver and calling an extension debug config provider. But, putting a queue around two unrelated pieces of code seems to say that I'm solving the problem at the wrong level.
Or maybe make them the same level by moving the resolve queue to
Just to be clear. The two callers of the are in two different places right (core and extension)?
Right
Ok I've not heard of any feature request like this but feel free to open one... I wonder if maybe instead Core could have concept of "important" quick picks that can't be stomped over by extensions and instead the extension calls wait until Core is done. Then we don't need any more API
It can also go the other way. The problem is just that there are two async processes that have to run and show a quick input, and we need both of them to complete and not to get canceled by the other. Filed I'll go with a workaround for now, so I'm not blocked, just figured I'd start the discussion
Sorry for the late reply. I tested this today and it works for our scenario. Thanks for the quick fixes!


Issue Type: <bBug</bThe description for is copied from VS Code version: Code 1.64.2 (, 2022-02-09T22:02:28.252Z) OS version: Windows_NT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.4.0-100-generic <details<summaryExtensions (15)</summaryExtensionVersion ------ jupyter-keymap1.0.0 remote-ssh0.74.0 remote-ssh-edit0.74.0 vscode-icons11.10.0 gitlens11.7.0 cmake-language-support-vscode0.0.4 git-graph1.30.0 vscode-dotnet-runtime1.5.0 python2022.0. vscode-pylance2022.2.3 jupyter2022.1. jupyter-keymap1.0.0 jupyter-renderers1.0.6 cmake-tools1.9.2 cpptools1.8.4 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


Track picking up
To verify, just open a TS file and click on the language status to check that the bundled TS version is 5.1.6


in VS Code stable and VS Code insiders all cells in each quickly up and down through the notebook :bug: in VS Code insiders scrolling over notebook outputs is not smooth anymore; scrolling appears to stutter and halt over notebook outputs I took performance profiles in stable and insiders but devtools won't let me save them unfortunately. Nothing stood out though in terms of memory usage or a particular function call increasing in percentage across profiles. LMK if I can provide more info
Is this with a trackpad? I might be seeing this. Could be a regression from
I've the same issue with a trackpad on Windows.
Yeah, trackpad on Windows for me as well


Variable substitutions that are available for (see ) do not include currently selected text. I am looking for something similar to $(CurText) that is available in Visual Studio Arguments for External Tools (see ). Please add a variable ${curtext} which would be replaced with the currently selected text in the editor window. If no selection is available, it could use the current line at cursor position.
Nice idea, but I think it's too late for implement that in the current milestone...
Fixed by in
Verifiers: what happens if all text in a 300 MB file is selected...
good point. Maybe we should put a limit on this. Or only to copy the howl line at most (even though the line could also be 300mb I am fine with that) thoughts?
Selecting lots of text, at some point I get . If there's a predictable limit where this will fail, we should just cut the string off there. Unless only sending part of the text could be dangerous or unexpected for the user. In any case I think that sending multiple lines of text could be useful.
there is not a predictable limit since the variables are used in different scenarios. If somebody has an idea for a limit I am open to PRs


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


Following the discussion in Repro steps on Windows: use a monospace font, make sure ligatures are not used, etc. (i.e. default editor related settings) change the scale setting of the display the editor decorations / selection should render correctly (on top of the correct text) (the problem was that the font measurements done with a certain display scale were used across all display scales).


<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: OS Version: Window 10 Steps to Reproduce: gif: !
(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.491 --<!-- potentialduplicatescomment --


<!-- 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?: No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.77.1 OS Version: All Steps to Reproduce: This is not a problem in the extension, the extension code is the same, but a commit changes the way webviews are loaded and it's breaking it. This commit: Has introduced a regression that makes my extension unusable. It introduces a problem on webviews in which workers are not available, and causes the following errors in the console: Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'active') at I have been tracking all changes since 1.76.2 release, building VSCode myself, and setting the build to the previous commit, my webview works flawlessly, if I checkout this commit, it's totally broken. I have not been able to send you are reproducible test case, but if interested, I can show you a video on how to use my extension, so you can check for yourself the issue. Thanks!
To add more information, check these two videos: Not working scenario, with the code at 1.77.1: ! Working scenario at the commit previous to the one I mention. Just remark that checking out the code at the commit I'm pointing, causes the not working scenario: !
Sorry you are running into this. Do you have an extension you can share that shows this issue? I can't simply revert the change because it was made to fix an hang with webviews opening. If I can repo this locally though, I can try to investigate
Thanks for checking this one!


My extension is this one: Find attached a sample project: These are the steps: Install the extension Unzip in its own folder Open the folder with VSCode With selected, issue the command Toggle Design/Code This will open up the webview, and with the changes, you could see in the console the issues Find here a video with the steps on how to open the webview, and the behavior when its working: ! Thanks!
Needless to say that if I should perform any changes on the extension to make it work, it's not a problem at all. That is, if I can get an idea on what the changes are, have no problem on that. :-) Thanks!
Thanks for the repo steps I have a potential Please try the next VS Code insiders build that comes out and let me know if you still see the problem. With the fix, things seem to be loading correctly: <img width="1129" alt="Screenshot 2023-04-12 at 4 06 24 PM" src="https://user-"
Checked insiders, but not sure if the fix got through, as I see some checks failed: ! Also tried update from the repository, and it seems still is not merged. In any case, what I see in your shot is that the Tool Palette is missing content. The content is provided by loading an external file called "" and it seems the webview is not able to load it: ! Will keep checking, THANKS!
ignore my last message, I have merged your changes locally and works perfect! So once this is merged, consider the issue fixed, thanks a lot!! !
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


creates a tree view opens the tree view disposes the tree view while it's still open creates the tree view again The tree view will stay empty until it's is toggled Real world repo (also works as steps to verify): to a Codespace (to use a specific build of VS Code you can specify a commit in the URL with , ex ) the Remote Explorer the page. This will cause the Codespace to load with the remote explorer visible 'll see that the Codespace view in the remote explorer is empty
update


<img width="1792" alt="image" src="https://user-"Hi, like visible on the screenshot, more than half of the terminal width in vertical mode is taken to display the path of the file where the log originated. I think this is not relevant to many of us since the path will point to the logger file At some point it gets really hard to read the logs Just to have an option to display path in cli would be enought for me. My screen resolution is 3072x1920 and my zoom level is -0.5 (at 0 it is even worst)
This has always been a bit off- I think only showing the file name would be sufficient
To be honest, who even needs the filename? When debugging I know what my messages mean and where they are generated. If I don't, a simple clickable elipsis will save space and perform the same function by bringing me directly to the line of code.


Tracks enabling the new drop into editor features () for code cells in notebooks Was disabled as we were incorrectly showing the drop into indicator while dragging cells within a notebook
Actually looks like may have the most experience in this area. I'll submit a PR shortly that may fix the issue but will need your help verifying it


Type: <bBug</bSteps to reproduce: a fresh, vanilla VS Code Insiders installation without any extensions. and open a new folder. , open it, and save it with the following contents: Actual results: A warning is reported in Problems tab and via yellow squiggles at line 10, column 25 (= character of the line specifying the ): Expected results: No warning is reported. Additional information: The problem matcher has been copied directly from the (). VS Code should not display warnings for unmodified examples from the docs. This also occurs in the current non-insiders release 1.74.0. VS Code version: Code - Insiders 1.75.0-insider (, 2022-12-08T05:20:51.149Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I can repro this. probably caused by your changes to the schema - could you pls take a look?
Of course. I'll submit the fix.
The PR is ready for review.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified Thanks for the quick fix!


When TS is configured with both and set to , TypeScript generates sourcemap files ending in . These files are not treated as JSON by VS Code.


I see that settings sync is suspended because of invalid token and token is not getting refreshed / updated. Sync LogMicrosoft Account Log Did not work even after Reloading the window / opening new window. Restarting VS Code worked. any insights? Is there a cache on the extension?
From the account log, the token gets refreshed before it expires. This should trigger an event which causes the new token to get set, but it seems like something about this is failing, since we then get into a loop of getting a 401 and trying to resolve the access token.
Every time we see a failure, we unset the token and send token failed request and we update the token by getting it from the account sessions. Looks like we are getting an invalid token from the account sessions. Can you please check if that can happen?
Found the issue! The token was not being set in the shared process
Easier steps to verify: in with an account to preferences sync out of the same account in to the account again Preferences sync should restart without any error.


Text in TypeScript file: With the Light High Contrast theme, I don't see the unicode highlighting outline. !


Maybe this already exists, but it would be good if <kbdctrl</kbdrendered this in markdown: <img width="35" alt="image" src="https://user-"We could then add nicely styled keybindings to various hovers: <img width="125" alt="image" src="https://user-"cc


image in Luna paint, save. on entry in SCM viewlet to see diff some more a drink to resize the window diff editor loads Haven't tried in other custom editors, don't know if this is an issue with custom editor openers or in Luna.
Seems like a core issue, also happens with hex editor with:
This seems like an important regression. No idea what changed in custom editor land
This seems to have been caused by /cc The current calls causes the webviews to end up with height in this case. On the first call to never gets invoked. Previously it got invoked before the webview was even created Looking to see what that proper fix would be for this. Some potential ideas: I feel like should probably always be invoked at least once on a newly created editorI'm not sure why the passed in always has zero height but that seems wrong. If that element has , then I believe the code would work The issue seems to be that and both have zero height
I get the following error with these steps, unfortunately... So I could not repro this. ! I am pretty sure the grid calls layout to its views whenver their sizes change. Is it possible that some layer between the grid and your webview is caching something and not calling on you? Namely the editor group layer. For example, I see a potential problem here: If the layout comes, and is , the dimension will be lost forever, since the grid will no longer send repeated layout calls when dimensions don't change. The instance should remember the last and pass it along to the active editor pane, as soon as it comes along. cc A very similar situation happened here:
I hit the same exception when following hex editor alternative steps. This might be a new bug?
Maybe is the same and has easy steps to reproduce.
Thanks the lack of milestone was hiding that issue from me! Will check it out.
btw the is storing the dimensions and applies them here already when making the control visible:
That exception you see I receive in the official build of insiders, but not when running out of sources. It implies that the resource URI is undefined which shouldn't be possible. If you have any ideas or would like to help me discover what is causing this let me know
For the hex editor, I had trouble reproducing this until I set .


The data inspector (usually) seems to trigger a relayout for me My reliable repo: a TS file and open the diff
Thanks I can repro with those steps! I will look into this tomorrow if you don't figure it out today.


Testing The setting says " speech recognized" which reads a bit weird. Maybe leave "speech" away or says "Controls whether the editor listens for the 'Hey Code' phrase and what to do with it"
Bonus points for mentioning that this happens all locally
Yeah, I think I will go with this:


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.68.1 OS Version: Windows 10 Steps to Reproduce: a Markdown file and open "Open Preview to the Side" add line: ! image in preview second line: ! second image shows up. Remove the line above image preview shows 2 images and does not update properly !
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Still happens in 1.68.1. Updating bug
Does this reproduce in the with all ?
Yes still happens with all extensions disabled


chat in sidebar something into input Session in Editor :bug: input is cleared
This still repros for me
The input is preserved but the input for the new chat session in the sidebar is not cleared


<!-- 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.67.2 OS Version: MacOS Monterey 12.4 (default zsh terminal) Steps to Reproduce: a folder containing an "Umlaut" (äöü) folder in VSCode and launch/use a terminal (for testing I used echo something in zsh) VSCode restarting, VSCode fails to restore previous session as "the directory doesn't exist" However, if there is no "Umlaut" included in the path somewhere, this problem won't occur. This issue should affect at least all german VSCode-Users (like me) who want to open a folder on their Mac located in OneDrive. The problem is that the filepath for such files looks like "~/Library/CloudStorage/OneDrive-Persönlich/..." and restoring a session isn't possible for any folder/file in OneDrive, which is a little bit inconvenient. There might also just be a problem with my terminals encoding (currently set to UTF-8 so should work I guess) that it can't open the working directory with how it spells (in this case) the ö in the filepath: <img width="390" alt="Bildschirmfoto 2022-05-23 um 00 04 17" src="https://user-"(when I try to cd to that filepath it doesn't recognize the oxccx88 as ö and says the path doesn't exist) Thanks for help in advantage :) Greetings, Fussel
Related:
Is this a windows issue only? I can't replicate this issue. I'm running Arch Linux.


the OP reported on macOS which shares most code with Linux
I'm trying to replicate the issue because I want to see if I can contribute to fixing it, but I can't seem to replicate it. I have a folder named "äöü" and I open the integrated terminal and run "echo hey". I close VSCode and reopen it, but it restores the session like it's supposed to. I even tried running a task that runs "echo hey" and it does the same.
do you close all VS Code windows and reopen? Just closing one of many will keep the original process running and reconnect to it.
I am trying to trace this bug. But it is kind of tricky because it is NOT reproducable on OSS dev build. It is reproducable on stable or latest insider production release though. On production release, after running a command in the terminal, somehow Unicode characters in the current path was saved incorrectly. (You can also see an incorrect terminal title updated.) On OSS dev build, Unicode characters in the path seems saving correctly and there is no issue restoring or splitting the terminal.
that's odd, could it be one of your settings?
I have zero settings for insider and OSS dev version. I only have some settings for the stable version. My system environment is same as OP's.
Attached a video to show the issue. https://user-
I wonder why this isn't happening in OSS: ! I think you must have settings in Insiders there because the default value is just ? Unless that's the same format zsh outputs its title?
No. I don't have any settings for insider. ! The final tab title is affected by other settings such as or ! After some testing, I can confirm that isn't updated into title sometimes. It might be another bug there but it is off-topic.
It seems like event fired unexpectedly with wrong path.
I also tried to reproduce the problem on Ubuntu but I wasn't successful (both the original problem and the split-terminal one). I even tried Persian and Arabic special letters but still had no chance.
To verifier: When testing make sure shell integration is off


a directory at path: /Users/ma//demoproject.(contains Chinese component) the directory from VSCode top menu: File - Open... a new terminal from top menu: Terminal - New Terminal. and terminal window automatically goes to path (demoproject). Command + Q shortcut to quit VSCode completely. VSCode from mac dock icon. and VSCode shows error: The terminal process failed to launch: Starting directory (cwd) "/Users/ma/xe6x9cxacxe5x9cxb0/demoproject" does not exist. the path in step1 does not contain Chinese(like /Users/ma/local/demoproject.), no error shows. the error only shows when the path contains Chinese. Extra VSCode information Version: 1.65.2 (Universal) Commit: Date: 2022-03-10T14:33:49.188Z (1 wk ago) Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 21.4.0
To verifier: When testing make sure shell integration is off


when split terminal in chinese path,error!
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.609 --- <!-- score: 0.558 --- <!-- score: 0.557 --- <!-- score: 0.499 --- <!-- score: 0.499 --<!-- potentialduplicatescomment --
I think this is language's problem.English path is very well.
It looks like your report is missing some important information, See for more info on how to report actionable terminal issues.
Thanks for your reply! version: 1.39.2 submit: Data Time: 2019-10-15T15:33:00.827Z Electron: 4.2.10 Chrome: 69.0.3497.128 10.11.0 V8: 6.9.427.31-electron.0 OS: Darwin x64 19.0.0 !
Thanks, you can probably workaround this with this setting:
I has try this settings by your suggestion. And it really not error.Thanks!But this way to create a terminal is not my default way.When I create a new terminal.It go to its father's file path , not it is before. If has a way to realize my need? !
Yeah that's what the setting does, you can't get what you're after until we fix this bug.
OK!I understand.Thank you!
I guess this is obvious, but the problem also occurs with European characters (at least french), and very likely with Arabic, Japanese, Indian, Korean characters as well. I also switched to in order to work around the problem.
I had this issue with the project folder itself containing unicode (greek letters). To my surprise, the hack still worked, the new terminal now sucesfully launches in the project folder.
Also happens when the cwd is set via runInTerminal
Note that in the latter case, it's not just the cwd that's affected - it's also all the command line arguments.
good point, this is probably an issue in debug land actually or related to encoding in the shell. Reopening it.
To verifier: When testing make sure shell integration is off


<!-- 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 built-in git extension exposes methods for most of the base git operations. Unfortunately not , which would be used to unstage changes. Could easily be to , i'll open a PR for this sometime today.
could you verify this by reviewing


in vscode , the formula is rendered with katex, an KaTeX parse Error occurred ! in pycharm , it's rendered properly with mathjax ! latex code:
The equation renders fine if you wrap it in so I reckon it's related to how we handle bare math blocks. Relevant code:
wow
Hi Can I work on this?
sure
Can you let me know where to get started? As per the last comment, it works when wrapping with "$$" so I figure I need to look into how vscode is rendering lateX in general? any other pointers?
the reason is probably katex can't process environments outside $$ , but i wonder if katex has a similar option 'processEnvironments' like MathJax provides
This is the same for .NET Interactive
This is indeed a pain - especially for someone still going through the learning process and not a LaTeX expert by any means.


They used to finish in 3m24s before - […]-5f82-0dbc-&t=-371d-5daa-d7a2-
I can confirm that tests started timing out after this commit - The first commit that is started happening is Checking what commits in between would have caused it. FYI
Assigning to as one of his commits has caused this timeout.
Mac seems to be passing pretty reliably now but now windows fails consistently on two tests Been adding a bunch of logging to investigate this. Here's the relevant new error: The service worker should be intercepting this request so it should never be going to the network at all here. Taking a look to see if I can figure out what is going on
Actually it's not windows specific: its Firefox specific. The windows browser tests just happen to be the only ones using Firefox Can reproduce on Mac too


For example: Context:
As we anticipate we might need shell scoping as well in the future, use something similar to instead. Updated proposal: One issue with this is that carries optional properties. Hence an alternative could be:
The required would need to be removed when we a second one anyway, we can just treat and the same as
Sorry what do you mean by the "second one"? Mostly I was trying to follow : But I guess we don't have to strictly follow it?
by a second one I mean a second scope, we don't want the user to explicitly enumerate all the scopes to set it which would do.
Updated proposal:
Closing in favor of as these issues were only open to finalize proposed API.
Moving this out of June as it's a feature request.
I was expecting this so it's easier to understand for an API user:
That's what I had initially had , you're the one who recommended that perhaps we should put it inside itself:
API sync also seemed to be in agreement with that, but maybe we should check again.
my mistake, I forgot some of the conversations as this has gone through a few iterations
Based on discussion in API sync, we should probably deprecate existing API and merge it with the scoped one (similar to )
Assigning myself too so it's easier for me to track
When viewing contributions, is it possible to open the preview of the markdown directly instead of the file? ! as opposed to ! I can open preview using: !
since this is an advanced feature I think the raw markdown is more flexible as the user can navigate and copy section of it better. So I don't think this is a necessary change personally
Feedback before finalization: Add an interface implements Add to the Clarify how scoped interacts with the non-scoped collection Don't deprecate
Should we also call out how it's applied in addition to (and after) the global collection? Looks good otherwise
Sure, I have modified the docstrings to append it I plan to have the implementation ready but only merge and adopt it in Python extension next week to avoid multiple iterations.


<!-- 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.80.0 OS Version: macOS Steps to Reproduce: vscode itself assigned this css var to but monaco-editor doesn't have this, it only has so should be , too.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.80.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!


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


Issue Type: <bBug</bIn the September release, we updated the suggest widget to respect the class. See The recent changes in the suggest widget for has caused a regression and brought the icons back when class is set on the widget. VS Code version: Code - Insiders 1.29.0-insider (, 2018-10-19T06:50:39.461Z) OS version: Darwin x64 15.6.0 <!-- generated by issue reporter --
I still see icons in the Setting suggest widget: !
I meant the settings search <img width="646" alt="screen shot 2018-11-02 at 10 15 38 am" src="https://user-"


<!-- 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.34.0 OS Version: Windows 10 Steps to Reproduce: terminal any command that makes any change of your current project directory after a while, like 'New Folder' action refreshing directory by the terminal command, 'New Folder' input will disappear and File Explorer remains inactive <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes !


Steps to Reproduce: an untitled file with JS mode code with errors/warnings on one =crash ! Is the resource scheme file but the URI untitled? Looks like it
Looks like is registered this as a file resource where are is not having any issues.
Thanks for the investigation. should fix this


Just to confirm that if you are aware that this change will not show the keybinding for Search view anymore at following places: <img width="367" alt="image" src="https://user-"<img width="161" alt="image" src="https://user-"Not sure if it is intended. Originally posted by in