jiebi/CodeConvo huggingface dataset:
Type: <bBug</ba git repository on a UNC path the folder in VS Code the repository as safe ! repositories will be shown instead of one. ! The issue is ephemeral and only one repo shows after reloading the window. ! VS Code version: Code 1.84.2 (, 2023-11-09T10:51:52.184Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ 2sxc0.0.1 vscode-tailwindcss0.10.3 dart-code3.76.1 flutter3.76.0 xml2.5.1 batch-rename-extension0.0.6 csdevkit1.0.14 csharp2.10.28 vscode-dotnet-runtime2.0.0 vscodeintellicode-csharp0.1.26 python2023.20.0 vscode-pylance2023.11.10 remote-ssh0.107.0 remote-ssh-edit0.86.0 remote-explorer0.4.1 sqltools0.28.0 postman-for-vscode0.13.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
are you able to reproduce the issue with the latest ? I went through the steps, but in my case only one repository is being shown. If you are able to reproduce with the latest VS Code Insiders release, could you please go through the steps up until the point where two repositories are shown and share the contents of ? Thanks!
<!-- 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!
<!-- 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. --Steps to Reproduce: a vscode extension repository (e.g. ) to contributes commands (e.g. ). "command" and observe the tooltip <img width="857" alt="Screen Shot 2020-09-05 at 21 07 16" src="https://user-"<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Does this issue occur on Insider?: Yes
Type: <bBug</ba TS file at the language status item in the status bar Bug The bracket icon is instead rendered as a pie chart icon <img width="222" alt="Screenshot 2023-01-18 at 1 28 37 PM" src="https://user-"VS Code version: Code - Insiders 1.75.0-insider (Universal) (, 2023-01-18T08:53:10.224Z) OS version: Darwin x64 22.2.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Looks like the id for got duplicated:
The static "when" clause on chat participants should be moved to the set of things that are finalized.
what would happen when a participant becomes "disabled" after having been interacted with? Evaluating going from to and to again
It would just stop showing up in the suggest widget and you wouldn't be able to invoke it. But it can still show up in your conversation thread. Same as if you uninstall a chat extension.
Verify that can be set and used on the chat participant contribution in without api proposal needed. Easiest to use the .
an explorer with a lot of elements tree horizontal scrolling covers the last element and there is no way to read nicely the content of that element I would expect the scroll is rendered below the last element, not on top of it
Can you share a screenshot?
If it could help, here is it: !
Also here's one from the explorer !
Seems to be a special case of combination between our scrollbar and the tree: the row is less than double the height of the scrollbar. We should add some extra pixels at the end of the view.
Hello. I want to take this issue. Could you give me a hint where should I start?
can i take this up? some insights will be helpful..
Type: <bBug</bI suddenly started getting the following message when my terminal starts up: I did not install anything but I did update the application. VS Code version: Code - Insiders 1.80.0-insider (Universal) (, 2023-06-21T08:23:42.803Z) OS version: Darwin arm64 22.5.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ vscode-tailwindcss0.9.11 language-hugo-vscode1.3.1 vscode-eslint2.4.0 gitlens14.0.1 prettier-vscode9.15.0 vscode-github-actions0.25.8 vscode-graphql0.8.13 vscode-graphql-execution0.1.8 vscode-graphql-syntax1.2.0 endwise1.5.1 vscode-duplicate1.2.1 remote-containers0.296.0 code-spell-checker2.20.5 vscode-mdx1.3.0 simple-ruby-erb0.2.1 gistfs0.4.1 pretty-ts-errors0.4.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I also encounter this issue!
Reproduces only when fish is installed via
IE contains binary so hard to know what's going on here !
any thoughts here?
FWIW is a (if you weren't using directly, vim, maybe you were looking at it with ?) and those are binary but probably isn't. It probably isn't interesting either. As for the problem, this happens at the initial invocation of so I'd guess it runs into the branch where exists and it's trying to initialize the integration but that function isn't defined yet, and I'd guess moving that invocation from line 125 to after is defined should fix this issue.
I think the idea that this bug is only present when using brew to install fish is not quite true, I'm seeing the issue on a Windows machine using WSL2.
Thanks that fixes the error. Shell integration still doesn't work because isn't getting run, so will investigate that
For this case, when installed via brew, there is a . Moving from to fixes this.
So the repro is to have a
<!-- 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!
should I be able to repro this just by installing fish with brew and using shell integration there or is there other custom fish config required?
Yep that is how I reproduced it
I have fish installed via are and have shell integration enabled and I am not seeing any errors neither in stable nor in insiders. Is there a step I am missing here to verify?
Reproduced in 1.80.0-insiders Verified fixed in
Issue Type: <bBug</bRepro settings editor, search for Bugs <img width="588" alt="Screen Shot 2020-03-16 at 10 04 28 PM" src="https://user-"In the settings UI: If I don't know what ligatures are, the description is not useful. Maybe link to our documentation? The description also does not explain the font features part. Maybe have an example? I have to use the settings json editor to actually change this setting. I suspect the most common use of this setting is turning it on or off In the settings json editor: It was not clear to me at first how to configure the font features (for a while, I thought it was supposed to be an object instead of a string) If you have and hover over the string, the description of what this string does is very generic VS Code version: Code - Insiders 1.44.0-insider (, 2020-03-16T07:10:59.884Z) OS version: Darwin x64 19.3.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
I'm moving this to backlog since this is more of debt/polish item (it's not one we'd expect users to search out and vote for)
Issue Type: <bBug</bAfter upgrading to 1.68, text selection in the integrated terminal does not show selected text. This is purely a visual glitch, as I can still copy what I had selected on the terminal. My colleague has the same version but does not have this issue, so I'm wondering if it's an issue introduced through my update. VS Code version: Code 1.68.1 (, 2022-06-14T12:48:58.283Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ project-manager12.6.0 github-markdown-preview0.3.0 markdown-checkbox0.3.2 markdown-emoji0.2.1 markdown-footnotes0.0.7 markdown-mermaid1.14.0 markdown-preview-github-styles1.0.1 markdown-yaml-preamble0.1.0 keymapceditor-vsc0.7.7 gitignore0.7.0 doxdocgen1.4.0 transformer1.12.1 git-extension-pack0.1.3 githistory0.6.19 gitlens12.1.1 EditorConfig0.16.4 align-mode0.0.21 better-cpp-syntax1.15.18 cmake-language-support-vscode0.0.4 theme-karyfoundation-themes26.2.1 vscode-docker1.22.0 vscode-dotnet-runtime1.5.0 python2022.8.0 vscode-pylance2022.6.20 jupyter2022.5.
jupyter-keymap1.0.0 jupyter-renderers1.0.8 remote-containers0.238.2 remote-ssh0.82.1 remote-ssh-edit0.80.0 remote-wsl0.66.3 vscode-remote-extensionpack0.21.0 cmake-tools1.11.26 cpptools1.10.7 cpptools-extension-pack1.2.0 makefile-tools0.5.0 indent-rainbow8.3.1 vscode-pbtxt0.0.4 cmake0.0.17 vim1.22.2 clang-format1.9.0 vscode-open-in-github1.3.6 (5 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Same issue, I'm using theme. When I switch to a different theme the selection is visible. Looks like a theme issue.
Can you reproduce the issue in Insider's? I see selection in Insider's when using solarized light, but it does seem pretty light !
I believe we're implementing solarized light correctly here and that's how it's meant to work. If you're not a fan of the low contrast selection you can change it with this setting: Otherwise change to a theme that you prefer. Let me know if I misunderstood and the selection is actually not visible (not just subtle).
I was using the theme for a while and I was used to the low contrast on selection. It was quite ok on my screen TBH. Now there's no visible selection. Here I've selected "Counting objects". I've actually pasted it from the terminal instead of typing to be sure. ! I don't think this issue is ready for closing.
Do you have any settings set and does changing help?
I strive to work on defaults. No settings in Setting to true causes selected letters to become slightly lighter, but no background. "si" selected ! Not sure if it has anything to do with it, but the issue seems to have started after the recent update (via PPA on an ubuntu flavor). After updating I didn't restart immediately, but attempted to open an image and everything crashed. Restarted after that and noticed selection not working a bit later.
Some more things to try: Does closing all windows and running fix it?
If not, can you share your full file? Running the Generate color theme from current settings command will let us see if there's something weird going on with the theme
Confirming this is only happening in Solarized Light
Disabling GPU doesn't help <details</summary{ "window.menuBarVisibility": "toggle", "editor.minimap.enabled": false, "[javascript]": { "editor.defaultFormatter": "vscode.typescript-language-features" }, "javascript.updateImportsOnFileMove.enabled": "always", "[json]": { "editor.defaultFormatter": "" }, "[typescript]": { "editor.defaultFormatter": "vscode.typescript-language-features" }, "": "stuff=", "explorer.confirmDelete": false, "explorer.confirmDragAndDrop": false, "[html]": { "editor.defaultFormatter": "" }, "[jsonc]": { "editor.defaultFormatter": "" }, "workbench.colorTheme": "Solarized Light", "editor.inlineSuggest.enabled": true, "editor.renderWhitespace": "none", "[css]": { "editor.defaultFormatter": "esbenp.prettier-vscode" } } </details<details<summarycolor theme from current settings</summary</details
I can't reproduce based on those settings so I'm a bit stumped on what to do with this one
So I checked the terminal background on the screenshot and it's which is exactly the same color as the default selection color. the dump I pasted above had in it, which seems odd. But since you didn't raise it, I'm assuming it's supposed to mean the actual background is the one of the panel inside which the terminal is working. What I also noticed about the terminal panel is it's no longer giving me the option to move it to the bottom of the window, which is odd, but most of all when I right-click, it no longer says "move terminal right" as an option, but "move sidebar". I checked, and means I will no longer see my selection. Conclusion is what ends up being the color behind terminal text. The theme should probably set terminal background or change the selection color as a fix. I wonder what else breaks because terminal is now a sidebar not something else.
Ah ok, thanks for looking into it. Because of this, setting the terminal background explicitly is a good solution for now.
The : This doesn't currently work in VSCode. It does support a very wide range of formats and I don't recall ever seeing this format before (even from GNU tools) so I suspect nobody else uses it. Nonetheless it's easy to add support in VSCode. See
Doesn't seem to work, see <img width="825" alt="Screenshot 2023-08-29 at 14 41 05" src=""
The PR intentionally left that out: But it should be easy to add so will leave this open.
<!-- 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.73.0 (Universal) OS Version: 13.0 Steps to Reproduce: open (cmd+p) file The UI button for from quick open works. The shortcut also works for file selection in the explorer My settings: Related to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.73.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Setting aside your Ctrl+Enter issue, did you know that Ctrl+RightArrow will already do what you want? It intentionally leaves the quickpick open so you can open another of the matches, but it's easy enough to close by pressing Esc.
ctrl+enter appears to be working for me even with your settings. What is it doing for you?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
sorry for the late reply. has the same effect as for me, it opens the file in the current tab. this also opens the file in the current tab for me, leaving quickopen open
if you remove these keybinding settings, does anything change? I'd also love to see what settings you have in your user settings to see if maybe something is up there.
Thanks for reaching back. I commented all keyboard shortcuts and disabled all extensions. Indeed I got it to work when I commented all config of . Then I got to pinpoint it to this setting: which apparently needs to be .
Thanks for your help!
That's interesting. is there are scenario where we can open to the side but as a preview? I wonder if this is why this setting affects the behavior.
This is driven by this line: I can only speculate that when I re-implemented quick open, I took this behaviour over from our first version. If I had to guess, then we had this rule back then: always opens to the side opens an editor as non-preview when preview editors are enabled opens an editor to the side when preview editors are disabled So I would argue that -click is the key to use here, same as for the explorer for example. And has special semantics depending on your settings. But we can certainly revisit this and make it consistent if there is inconsistency.
Thanks. That is the behavior I see. Maybe we update the setting description to make this more clear? Current: Maybe we add: "non-preview" or whatever jargon we use. Thoughts Not entirely sure we need to define Preview editor here too.
Yeah I like the idea of updating settings, feel free to do that!
verification: read the docs for the settings. Does the use of there make sense (knowing that we don't want to change the behavior)
Visual Studio's Output window has a "Toggle Word Wrap" button, but VS Code has word wrapping always (?) enabled. For certain scenarious like the pending "C/C++ References" output it is desirable for word wrapping to be disabled for the results to be more easily read. There is a "View: Toggle Word Wrap" command, but it applies to the active document only (and not the Output panel, even if it's active). And/or if the OutputChannel interface could add a toggleWordWrap capability, that would allow extensions to set an appropriate default for their particular Output channel. This seems like a pretty basic feature that other Output channel providers would want, but I couldn't find an existing feature request on this.
This describes the same issue and led to adding a config option but it doesn't seem to work or the feature request was misunderstood?
Thanks a lot -- I can use that [Log] setting as a workaround (by setting it in our configurationDefaults); however, the result is still not ideal because it will apply to all Output windows and our C/C++ extension would prefer to isolate the behavior to a specific one. (And a button in the UI would make it easier for users to figure out how to overwrite our "no wrap" default).
Currently, one workaround is to set:
Yes, that is the same workaround I was describing (which our C/C++ extension uses), but it applies to all the output panes, and we'd prefer to isolate the change to a particular output pane (e.g. "C/C++" or "C/C++ References" and not "Git", etc.).
that's a nice to have feature.
For log files, I had the word wrap button visible & after a few moments it just disappeared
It looks like the 'editor.wordWrap' setting no longer works for [Log]. Was it removed intentionally or it is a bug?
That setting is working for me with non-Insiders VS Code with our C/C++ output window, but I see certain output panes like "Window" ignoring the setting somehow (i.e. it always wraps).
Ah, it's working for me now. It looks like it requires a Reload Window after it is set.
command is now also supported for Output Channels.
Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.
Testing ! !
doesn't reproduce in the panel chat
I somehow suffer from this change which explicitly targets some monaco tokens...
This isn't nice but there's actually no other way to override the foreground color of an editor- because typically you have syntax highlighting. We do this for all the other "input box"-style editors. I think I opened a feature request when I did this. We should align this rule with your rule for coloring the decoration so that it can override it properly.
labeling so it gets verified
Thanks
in the latest insider's, still seeing this ! !
There is two separate issues with different steps. There is a difference between rendering of slash command and normal prompt text. the only useful/visible information in the original issue description is slash commands (please use words and not images to describe issues!). For verification you have not used slash commands but normal prompt text which is a different case. Please file a separate issue, use words/steps and don't rely on screen captures with just white on white text
Steps to reproduce/verify use HC light and dark theme open inline chat and type a slash command, e.d make sure the command is readable when selecting its text
<!-- 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.71.0 (user setup) OS Version: Windows_NT x64 10.0. Git Version: 2.30.2 (Windows) Steps to Reproduce: a new directory a new Git repository a new file and append some text on the first lines this file to the staging the line with text An OS native dialog box error pops up with the title of this issue as text. In the console output for Git: I have had this problem for a long time, 2 years I would say. I thought someone would have reported it but it seems not.
I'm having a similar issue on macOS 12.6 (21G115). If you have deleted lines at the top of a file and click the little arrow to undo the change, the error pops up. Notably, it still completes the undo. <img width="396" alt="image" src="https://user-"
apologies for not getting back to you on this. I used the repro steps above but I was unable to reproduce the problem with the latest VS Code Insiders (1.75) release. Could you please do me a favour and see if you are still able to reproduce the issue? If so, could you please share a recording using so that I can further investigate the issue? Thanks!
Issue is still present in the latest insider release on macOS. !
VSCode info: Version: 1.75.0-insider Commit: Date: 2022-12-19T05:35:41.089Z (10 hrs ago) Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: Yes