jiebi/CodeConvo huggingface dataset:
Pinging authors of the issues above along with those who I have seen express interest in reverting the behaviour:
Another idea I have rather than doing a full revert is to use table of contents order as a last resort sorting key for the keyword matches. Therefore, keyword matches in the title could come before keyword matches in the description, and the settings that all have a description-only keyword match could be sorted amongst themselves by table of contents order. With this concept, some extension settings could preserve their order, but an extension setting found by keyword matching would still always come before an extension setting found by a similarity algorithm.
To revert the search results in the Settings editor to order by keyword matches first in the Visual Studio Code extension, you can follow these steps Open the Settings editor: You can do this by pressing the Ctrl+, (Windows, Linux) or Cmd+, (macOS) keyboard shortcut, or by clicking on the gear icon in the Activity Bar and selecting "Settings" from the dropdown menu. Search for the "workbench.settings.settingsSearchTocBehavior" setting: In the search bar at the top of the Settings editor, type "workbench.settings.settingsSearchTocBehavior". Change the value of the setting to "hide": Click on the dropdown menu next to the setting and select "hide". This will disable the table of contents ordering and prioritize keyword matches. Restart Visual Studio Code: To apply the changes, you need to restart Visual Studio Code. Once you restart, the search results in the Settings editor will be ordered by keyword matches first.
that behaviour was implemented as part of , and yes, it is a workaround in a sense. This proposal is on ordering results by keyword matches first even when the table of contents is shown.
Try doing this way In the file, add the following property to the contributes section: { "name": "revert-settings-search-to-keyword-matches-first", "version": "1.0.0", "description": "Reverts settings search in the Settings editor to order results by keyword matches first.
", "publisher": "your-name", "categories": ["Settings"], "activationEvents": ["onStartup"], "contributes": { "configuration": { "properties": { "search.settings.sortByKeywordMatchesFirst": { "type": "boolean", "default": true } } } }, "main": "" } the extension's main script file, add the following code: const vscode = require('vscode'); vscode.extensions.onDidChangeConfiguration(() ={ const sortByKeywordMatchesFirst = vscode.workspace.getConfiguration('search').get('settings.sortByKeywordMatchesFirst'); // Update the Settings editor's search sorting algorithm here. });
Since I am coming from , it would be important to me that the order determined by the extension is retained when only " is called (as you also suggested in ). This then serves as a filter for the items in the base order. If you then place a keyword behind it, you can search "smartly" again.
Verification notes: for title bar style should show the setting first no matter what value is set to. for should show the CSS category first, followed by the LESS category, and lastly by the SCSS category.
Type: <bBug</bany open windows. to File Open Recent and click Clear Recently Opened. VS Code version: Code 1.83.1 (, 2023-10-10T23:46:55.789Z) OS version: Darwin x64 20.6.0
<!-- 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
VSCode Version: 1.36.0 OS Version: Windows 10 Repro steps: Live Share extension 1.0.488, start a collaboration session two comment threads on a single line. Comment on a line, 3 for example Comment on a second line, 4 for example Delete line 3 Now there are two comment threads on line 3 (the line that moved up from 4) /Collapse the comments with the marker Collapsing/opening such comments might need a rework. Currently I can collapse each individually, and if all are collapsed (or all open), the box on the gray line opens (or closes) all threads. However, if only some of the threads are collapsed, the gray box toggles between the set of open threads and the threads which were collapsed. It never collapses all threads to return to code, and requires each remaining thread to be collapsed individually. Originally reported in Live Share issue
As I was just about to file the same thing, here is the screencast I created for illustration: !
I agree the current behavior is a bit confusing. Clicking in the gutter is a common way to collapse open comments. However, the workflow fails when multiple comments are on the same line. This forces the user to think and use the alternative workflow (top-right icon). Suggested behavior: if at least one comment is expanded, collapse all comments on the line otherwise, expand all the comments The condition could also be reversed (expand if the line has both expanded and collapsed comments).
Since we just came across the relevant code again in another context: clicks on the gutter icon currently toggle the collapsible states for all threads on that line independently here: already exists as a private property, if there was a public getter for it, behavior like the one suggested by above could probably be implemented very locally in the location I linked to above. let us know if that sounds reasonable and we can make a PR.
yes, this sounds reasonable to me. l would accept a PR!
I opened .
Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.2 OS Version: Windows 10 It seems that when refreshing () the in a short period, the second refresh is not actually performed. I have provided an example repo and a video demonstrating the issue. Basically we have a that shadows the active editor so whenever a user changes the active editor we update the read only document. However, if the user changes the editors quickly enough then the second change is dropped... Steps to Reproduce: the extension the command "Open Read Only Document" tabs quickly and see how it falls behind even though the content is up to date https://user- The content is actually set but it seems the second is dropped. Because if you refresh the document manually it shows the correct content (see the video above). The issue seems to happen more frequently if the content of the file(s) is large.
I found out why it happens and attempted a fix (with explanation) in
Pinging so it does not get lost
Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-
Issue Type: <bBug</bclick folder some chars and drag to the left to release GIF ! VS Code version: Code 1.41.1 (, 2019-12-18T14:58:56.166Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (29)</summaryExtensionVersion ------ vscode-css-formatter1.0.1 markdown-preview-github-styles0.1.6 vscode-intelephense-client1.3.9 vscode-markdownlint0.34.0 vscode-html-css0.2.3 php-debug1.13.0 auto-js-vscodeext0.2.3 composer0.7.1 markdown-shortcuts0.12.0 hex-rgba-converter1.0.4 php-namespace-resolver1.1.8 code-beautifier2.3.3 vscode-language-pack-zh-hans1.41.2 remote-ssh0.48.0 remote-ssh-edit0.49.0 remote-ssh-explorer0.49.0 cpptools0.26.3 Go0.13.0 php-docblocker2.1.0 vetur0.23.0 vscode-php-getters-setters1.2.3 minapp-vscode2.2.2 java0.55.1 vscode-xml0.10.1 datetime1.0.5 code-settings-sync3.4.3 vscode-java-pack0.8.1 vscode-preview-server1.3.0 html-css-class-completion1.19.0 </details<!-- generated by issue reporter --
I can not reproduce this. Thanks for filling this issue. Can you reproduce using Visual Studio Code Insiders
reproduce too !
I can not reproduce this both on macOS and Windows and I am doing the same thing as you. Let's leave this open as see if more users hit this. If you are interested in providing a PR which fixes this, here's a code poitner
reproduced as well, make sure you release the drag on the arrow icon.
pushed a fix for this. Please try it out in VS Code insiders from Wednesday and let us know if you still see the issue. Thanks
Thanks, but have a new problem: Input is cleared !
VSCode Version: code-insiders-1.8.0-.el7.x86_64 OS Version: CentOS Linux release 7.2.1511 (Core) Steps to Reproduce: code rpm from insiders build on CentOS minimal to launch it from cli Installing GConf2 fixes it ( yum install GConf2 ). maybe should be a dep in the rpm spec file.
hello would love more information on the minimal install aspect for your use case. To clarify, are you starting with a "minimal installation" and then installing x11 after the fact ? !
Yes, and after that I just install the basic fonts and xorg xauth because I ssh into the devel box and use the editor via X11 forwarding. I've done this with other editors and is pretty handy, so I can avoid copying/checking out code from the workstation to the devel box (I write stuff meant to run over CentOS 7)
The exact same problem occurs on Elementary OS (based on Ubuntu). Running fixes the issue. It's most likely the same missing dependency problem in the .Deb file.
this should be fixed in 1.9
Hello, I had the same problem on openSUSE 42.1, when I ran the problem was solved. Btw I downloaded the .rpm file.
On ArchLinux pacman -S gconf
Issue Type: <bBug</bOpen a Webview (for example: Help -Release Note) and start the search (Ctrl+F) and write the search term (for example: "Update") Only "u" (first letter) is selected on the view and not the current tipped search term. ! Notice: If i pressed "enter" then the full term is selected on the view. This behavier was other in the previous version (1.52.1) VS Code version: Code 1.54.3 (, 2021-03-15T10:55:45.459Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (31)</summaryExtensionVersion ------ mock-debug0.45.4 cortex-vsc2.1.0 npm-intellisense1.3.1 vscode-markdownlint0.40.1 jshint0.11.0 vscode-eslint2.1.19 vscode-npm-script0.3.18 vscode-firefox-debug2.9.2 auto-close-tag0.5.10 code-runner0.11.3 vscode-test-explorer2.19.6 code-coverage1.2.3 vscode-docker1.11.0 csharp1.23.9 python2021.3. vscode-pylance2021.3.3 jupyter2021.3. cpptools1.2.2 powershell2021.2.2 debugger-for-chrome4.12.12 vetur0.33.1 java0.76.0 vscode-xml0.15.0 vscode-yaml0.17.0 markdown-preview-enhanced0.5.17 vscodeintellicode1.2.12 vscode-java-debug0.32.1 vscode-java-dependency0.18.2 vscode-java-pack0.13.0 vscode-java-test0.28.1 vscode-maven0.28.0 </details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.526 --<!-- potentialduplicatescomment --
The search behaviour changed between Electron 9.3.5 and Electron 11.4.1. The parameter should now be whenever we're doing a search for the first time.
[X] Notebooks (.ipynb files) [ ] Interactive Window and/or Cell Scripts (.py files with #%% markers) Hello. As the title says, I can't make a internal link in a jupyter notebook in vscode if the cell's title starts with a capital letter, contains an underscore or contains a space, as you can see on the images. Also, on the sole option that it works, non-capital letter header, when clicked it brings me to the bottom of the notebook, and the focus is not brought on the right header itself. Initial tests: ! The test headers: ! 64.5 v2022.2. Python v3.8.5 Python Extension: v2022.2. No response Local
This is actually handled by VS code core (and not the extension). I've included a demo notebook that repros the problem .
In the demo notebook, the href jumps all work ! But none of the header jumps do unless you rewrite them to be only lowercase. All of the links work fine when running in 'jupyter'.
Vscode this notebook is still with all the bugs. Even on the links that work, they jump me to the very bottom of the notebook, not to cell 2, cell 3 or cell 4. Also Section jump and Section with space jump still doesn't work at all. I'm using portable Vscode btw, but I think this doesn't make any difference since when I was using the regular one this bug still existed. Even now, about 2 years later (that I recall) it still goes on on notebooks in Vscode. I can record a GIF if you need. I assure no weird magic was done on my vscode, just regular installation and all... and I can confirm that this issue still occurred years ago on my other PC too.
Does this reproduce in the ?
It did for me.
Will this issue be addressed on any new version of Vscode? I've headed to version 1.67 and to "April+2022+Recovery+2"+is%3Aclosed and found no mentions of this issue. Perhaps on the next, if it would be implemented/fixed at all? Thanks anyway! :)
This issue was fixed in 1.68 (the May 2022 milestone)
got a look at and pull request ( ) doesn't appear there.
Will it be ? Thanks :)
Did you test it?
Yes! everything was fixed. Capital letters, underscore and space headers now work like a charm. I was just asking if this specific commit ( ) will be listed on the update website. I don't know how it works, if minor fixes won't get listed or something like that. I just wanted to show to some friends that somehow I've contributed to Vscode with my bug report Anyway, everything buggy was fixed. This issue may be closed anytime.
Testing So I was testing the terminal sticky scroll and I noticed that the sticky code block disappears in an abrupt manner when the beginning (not the end) of the multiline terminal command, reaches the end of the scope. To give more context about what I mean, I the GIF below. I was sort of expecting the code block to start disappearing when the line reached the end of the output for that command. I noticed that the code block disappeared however when the line reached the end of the output for that run. I don't think this is a problem per say, it's a different manner of animating sticky scroll. I was just wondering if this is intended? I think the potential issue with this approach is that the sticky scroll block is hiding the next terminal command and its output while you are scrolling until it disappears. In the editor, sticky scroll starts disappearing progressively when the bottom of the last block/line touches the end of the scope. Perhaps we could explore something similar?
This is actually a bug, it's meant to scroll up as in the editor and was doing that at some point. Note that it's not as smooth as the editor since there's no "partial line scrolling" in the terminal
Repro that demonstrates more clearly what's happening: Run: Run: Run: when scrolling, sticky scroll from a command should never obscure the command below it like this: !
I see the prompt line sort of being obscured here
I try to add a keybinding with ${selectedText}. but it will resloved as a normal string. Steps to Reproduce: ! Version: 1.75.0 (user setup) Commit: OS: Windows_NT x64 10.0. Sandboxed: No
would you happen to know why the variable isn't resolving to a value here? Is there something that the command must contain to resolve variables?
The decision for whether variables should be resolved in a command needs to be made on a per command bases. If you want, you can run your commands arguments through the variable resolve when your command is called. For example, the terminal uses the variable resolver here:
From It would be great if more variable resolution was achieved in keybindings - I think it has been requested many times.
verif steps: a keybinding for : that the keybinding correctly sets to the current path.
When creating a breakpoint in an active debug session and this breakpoint cannot be verified, the resulting icon is almost invisible: ! The problem is that the icon's stroke is too thin. In previous versions the icon had a thicker stroke: ! I suggest that we restore the previous icon.
Agree that it is a bit too light. I do not just want to take the previous icon since the color and style are different. Thus it would be great if could tackle this Also fyi
Not quite as strong as in the 'before' above, but stronger. Marking verified. !
Type: <bFeature Request</bCC Just like other audio cues, please reduce aria alert when "" is used. VS Code version: Code - Insiders 1.84.0-insider (, 2023-10-17T05:34:42.128Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
also when is used
To verify, Enable Enable a screen reader Format a document Verify that the screen reader doesn't alert and you just hear the audio cue
Verified, but found this:
Open Set some breakpoints They show in the wrong place and cover a character, but seemingly get fixed when setting a breakpoint on the next line !
It is non-deterministic: ! Maybe that depends on the timing of the debugger. If I add to this statement (effectively removing the condition), I cannot reproduce anymore: Unfortunately that might cause performance problems. I think this is because needs to be called when injected text is inserted before it.
I am currently still reproing it here: <img width="445" alt="image" src="https://user-" btw make sure you add labels and a milestone to issues for verification and tracking
Any chance this could be looked at soon? It comes up pretty often <img width="1018" alt="image" src="https://user-"
Thanks
Following on from comments at , it would be good to have basic Dart language configuration as a built-in extension in VS Code, allowing things like syntax highlighting to in the case where the Dart extension is not installed (for example a Live Share client that hasn't installed it) or is disabled (for example in an Untrusted workspace). From : There is a Dart Team-owned grammar here that can be used - it's the (except for a small bug fix that I'll file an upstream PR for shortly): Great! Though what's the advantage of depending on the built-in extension? I try to support a few-versions-old VS Code where possible (so wouldn't do that for a few versions) but also the extension is published to open- for use by other clients so the dependency may complicate things (if they don't have the same built-in). I'd probably do some investigation into this before removing anything from Dart-Code then (it sounds like there's no downside to having the grammar/config provided by both for a period anyway). (fyi
It also works without a dependency, but only because the extension is built-in. No problem if the Dart extension keeps the grammar and language configurations for a while until it is all settled. Do you want to look into a PR or should I?
If it's easier/quicker for you to do, feel free. Otherwise I'm happy to do it but may need some pointers for how built-in extensions are set up.
I pushed the PR We have a new built-in language :-)
Super, thanks! For future reference - for changes to the language config I can send a PR to , and for grammar changes I can run (after the changes are landed in the upstream dart-lang repo)?
I just noticed in the it has the path but this doesn't seem to match the location of the file ?
Good catch, thanks. Pushed the fix:
For grammar changes, I'll pull them in about once per month so you can just rely on that if you want. If there's a change that needs to be picked up sooner than that, then feel free to make an issue an @ mention me and I'll pull in the change earlier.
Perfect, thanks!
is this support in the Code May Update (1.57) that just went out?
Yes, in microsoft/vscode you can tell what release an issue is in by looking at the Milestone. !
Yep!
An easy way to test it's working is to disable the Dart/Flutter extensions (accept the prompt to reload), then open a Dart file. You'll now still get syntax highlighting (note: you won't get analysis or much other editor functionality, that requires the Dart extension). <img width="650" alt="Screenshot 2021-06-14 at 15 52 25" src="https://user-"
Yeah I just did, and it works great :-)
The change for went in without a UX discussion. IMHO we should reconsider adding these two actions to all editor context menus. IMHO we need to be more critical with adding things there and have good reasons to do so. <img width="284" alt="image" src="https://user-"
I figured it wasn't a major change since they are already in the context menu during a debug session. Would a Debug submenu help? Or how about only showing them if the user has previously debugged in this workspace?
I see how it might not feel like a major change, but IMHO we should approach this with a different mindset. We have many useful commands, and we can add many of them to the context menu, but just because we have the ability to add them is not IMHO a good enough reason. Adding something to the context menu has two disadvantages: it makes our editor feel bloated (think typical IDE of the early 00s) it detracts from the value of the existing items, since there are so many of them. I think we need to have a good reason to decide to always show something in the context menu, like a very important feature that we feel will differentiate VS Code from other editors, a reaction to a lot of user feedback, an action which would make the product incomplete if it would be missing, etc.
We discussed this in standup and I will likely just remove them when not in a debug session.
From and Keeping the changes so that they will work and appear in the command palette when not in a debug session, but only appear in the editor context menu while debugging
When the content hover contains a color picker and it is resized too small, the text and the color picker box overflow. Perhaps the text should disappear when there is not enough space for the text.
At least the text does not wrap to the next line anymore, but imho the text should remain visible for as long as possible and could possibly also have text-overflow: ellipses? <img width="153" alt="image" src=""
Hi thanks for your comment. The following PR which was merged yesterday should set a minimum width on the content hover when a color picker is embedded and resolve the issue. The fix should appear in today's insiders with commit number
Indeed, thanks!