jiebi/CodeConvo huggingface dataset:
<!-- 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. --There is Title Case, Snake Case, Lowercase, Uppercase, but no Camel Case. It would be nice to transform: -
It would be a great feature. You could use that extension: until then. I also think that they should work on the to exclude articles and even custom words. instead of which is not accaptable in many academic organizations.
<!-- -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!
<!-- -a7ce-58b9-b1f9- --This feature request has not yet received the 20 community it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our . Happy Coding!
Up for a PR anyone?
I to do this. I have more details in the PR description about how different use cases should be handled. I don't really have a strong opinion on it. I wrote a personal extension long ago that has it's own set of rules, so I probably will keep using that over the one I implemented in 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. --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.85.1 OS Version: macOS Sonoma 14.2.1 Steps to Reproduce: a python file or other file with a debugging extension installed Debug view and see the welcome view showing Run and Debug Actions. a diff Editor for the same file debug view now shows an Expected: Debug view shows the same welcome state as when not in diff view as this language has debug extension installed. <img width="694" alt="image" src=""Actual: !
<!-- 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: N/A OS Version: N/A Steps to Reproduce: presence of in the example above means it should apply only to documents, not "all" as the text suggests
Type: <bBug</bFuzzy search icon is visible in Go to Symbol view (Shift + CMD + O) which on press opens terminal recent search with fuzzy search. I think that button should be excluded from Go to Symbol view and be visible only in terminal recent search view. VS Code version: Code 1.73.1 (, 2022-11-09T02:22:48.959Z) OS version: Darwin arm64 22.1.0 <img width="607" alt="image" src="https://user-"<img width="597" alt="image" src="https://user-"<!-- generated by issue reporter --
Seems like after the icon is not cleared and shows up in any command palette entry
STR: VS Code with locale set for language prompt and close it VS Code and repeat 1st step Language prompt shows again. has logic for storing an ignore key after a prompt was shown, but is using the wrong key (language instead of locale). The same variable mixup has caused prior breakage of the feature.
Forwarding to since he owns localization.
I partly own localizations support in VS Code especially recommending. It seems you come up with a fix. Do you mind opening a PR?
Ignore above comment, I see the PR now.
I'm still seeing this in insiders I clicked the on the notification and then restarted. After a few seconds, the prompt came up again
Found it. Only "Don't show again" triggers that logic, but just canceling doesn't. I wonder what the right behavior should be. Other prompts also depend on "Don't show again" (using the option, ) for a similar logic and otherwise pop up again on next launch. cc for guidance.
Clicking is never meant to be not to show again and user has to explicitly select action. I think this is general behavior for all prompts. I would recommend to discuss this UX change separately and mark this as verified otherwise.
Marking as verified based on comments above
A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Visual Studio Code Client; #BM-VisualStudioCode-Win32-Nov2021; #Win32; #Narrator; #NVDA; #ScreenReader; #WCAG4.2.5 #AINotInScope; #FTP; #STP; Application Name: Visual Studio Code Client Windows Version: Windows 11 1)Turn on Narrator/NVDA. 2)Open Visual studio code editor. 3)Open the command Pallet by pressing "F1" key and type "Theme" 4)Using Down arrow key select "Preference color Theme" and press enter key to select. 5)Using "Up/Down" arrow key select different available theme. 6)verify that screen reader is announcing the associated label for the 'recently used' and 'Other commands' or not. Screen reader does not announce associated label for the 'recently used' and 'Other commands'.. Screen reader should announce the associated label for the 'recently used' and 'Other commands'. Screen Reader users will not get the complete information about the controls. !
The issue here is that the group label "recently used" does not get read. I suggest to append the group name to the aria label of the first element in the quick pick that belongs to that group. I think it should be a low hanging fix.
VSCode Version: Code 1.12.2 (, 2017-05-10T13:20:36.315Z) OS Version: Windows_NT ia32 10.0. Steps to Reproduce: "JSON" file Expected outcome styled as (invalid) content token. Actual outcome styled as comment. Still properly marked as invalid, though. Remarks is OK. Same steps in JavaScript file is OK. ! Ad "JSON" in quotation marks: .
I am writing a debugger adapter. I use ProgressStartEvent/ProgressUpdateEvent/ProgressEndEvent to report some debug opertions' progress information. In previous versions, the progress information was shown in right-bottom corner, however, in 1.86.0, the progress information is shown in status bar instead. I think this is not a good idea, as user might not be able to notice the progress information. If there is a workaround if I still want to show progress information in right-bottom corner of VS code? Thanks! Bill Zhang
I haven't yet found a 1.86 commit that specifically changes this behaviour. Have you perhaps been trying out this new 1.86 feature?
If this is a confirmed regression, it would help to know which change caused it. We maintain a based CLI tool  that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression. Steps: install (if not yet done) follow the instructions until you found the offending build (its fine to leave the commit empty) report back the commit range in this issue Thanks!
The progress information was shown in status bar, not a pop-up window as before versions, so I have no way to enable/disable notification. In addition, notification was shown as before in right-bottom corner.
85 does not have this issue.
If you cannot find the actual commit causing this using , then you need to provide a minimal repro for us to try out.
I have tried the vscode-bisect, but it failed: PS C:gitBIOSDBGV4srcextensionnpx --yes --reset [build] deleting cache directory C:UserszhiqzhanAppDataLocalTempvscode-bisect √ Commit of released insiders build that reproduces the issue (leave empty to pick the latest build) ... √ Commit of released insiders build that does not reproduce the issue (leave empty to pick the oldest build) ... [build] fetching all builds from [build] total 171 builds with roughly 7 steps [build] downloading build from [build] unzipping build to C:UserszhiqzhanAppDataLocalTempvscode-bisect.buildsVSCode-win32-x64-1.85.0-insider... [build] starting desktop build ... √ Is good or bad? » Good [build] downloading build from [build] unzipping build to C:UserszhiqzhanAppDataLocalTempvscode-bisect.buildsVSCode-win32-x64-1.86.0-insider... [build] starting desktop build ... √ Is good or bad? » Bad [build] downloading build from [error] Error: read ECONNRESET You can run vscode-bisect --verbose for more detailed output and vscode-bisect --reset for a fresh start without caches.
At first, it is quick in downloading vscode-insider, but later it takes a long time to download it. I am not sure why. !
thanks a lot for trying it though, maybe some connection trouble. I can try it if you tell me how to reproduce.
I create a simple debugger for testing. code: vsix: I am not sure whether you know how to start a debugger or not: 1) install test-debugger- 2) open a empty folder and then create a ! 3) select Debugger For Test ! 4) Start Testing debugger ! 5) You will see progress information in status bar !
If run in 1.85.2, it is as below: !
thanks! Is it possible that you have snoozed notifications either globally or for the extension?
You effectively see the same notification but when it appears in the status bar, it means the notification is hiding because of the "Do not disturb mode". When you click the status bar entry you can see how it changes to the notification toast.
Yes, you are right. But even in below setting (BIOSDBG V4 is my extension): ! The notification is hidden unless you click the right-bottom icon. ! I think it makes me confused and it is not easy for user to notice this. Thanks!
There is indeed a change that happened as part of our latest release, but I think for the better: debug had always decided to show notifications for debug progress in the status bar via this directive: A change I did last milestone actually made to support it now: So I am deferring to debug component to further triage, but I think this is actually expected behaviour.
I think we should revert to the old behavior for consistency as that's what users have historically seen
<!-- 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.79.0-insider OS Version: macOS 13.3.1 Steps to Reproduce: VSCode in a computer with a relatively old version of Git (2.16.2 does it). a project under version control. control fails silently and only shows the Publish button. Trying to publish causes an error. This seems to be related to a change that makes use of the option in , which doesn't seem to be supported by old-ish Git.
sorry about this. I will try to get this fixed this week.
I am also experiencing the same issue. VS Code Version: 1.79.0-insider OS: Windows_NT x64 10.0. git version 2.17.1
It looks like the option was in git 2.18.0. Ideally you would want to keep your git installation up to date to keep up with the security fixes. Having said that I do understand that there are scenarios in which one cannot install the latest git release, so I have pushed a fix for this issue. The fix will be included in the next Insiders release.
Thanks a lot! I agree with keeping git up to date. Unfortunately I use VSCode with the remote extension in many servers where I don't have control of what version of Git is installed, so having at least some basic Git functionality there is much appreciated.
Hi, I encountered the same issue with my VSCode + WSL1 (I haven't upgraded to WSL2 for some reason) git version: 2.11.0 VSCode Version: 1.79.0
could you please share the complete contents of the ? What version of git are you running inside WSL? This flag should only be in case you have a version of git that support it.
Same issue here
Affecting me too. This seems like a major breaking change. Is there a bugfix release planned? Thanks.
could you please share more about your environment? What version of git are you running (git --version). Are you also using WSL, or any other remote environments? Anything that helps me reproduce the issue would be extremely valuable (ex: the contents of ). Thanks!
Thanks Ladislau Using git 2.17. I don't want to upgrade to insiders build Get Outlook for iOS
could you please run and share the exact output. My current hypothesis is that for some reason we are unable to correctly detect the version number and that is why we incorrectly add the flag.
Let's continue the investigation in this issue Thanks!
<!-- 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.56.0-insider OS Version: MacOS Big Sur 11.2.3 Steps to Reproduce: Settings and and editor it manually. a rule: editors can't be edited anymore. <!-- 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. --
Request completions, commit on Expected: Regular completion, no method body OR completion that is otherwise identical to both settings being . Actual
I want to understand this better, since this kind of behavior is also present in other completions I think: how should interact with completions that can or cannot contain snippets? For instance, the class member completion can be a snippet, but it doesn't necessarily have to be, which is why it still shows up in the example above when is false, but the difference is that it's no longer a snippet (i.e. there's no tab stop in the body of the completed method). I guess this bug is saying that this completion should never be offered in its non-snippet form? Is this the case because not having the tab stop in the method's body degrades the user experience? Is it because of some other reason?
Ugh - okay, so there's plain completions completions with insert text completions with tab stops and for some reason, is the one that enables tab stops. Did I get that right?
I think so, yes. Not sure if this this is relevant, but note that while is a setting that is user-configurable in vscode, while is not. Andrew B once told me that's because is supposed to indicate whether an editor supports insert text in completions or not.
I believe it's controlled by setting
and say that this should never have been user-visible in the first place. The flag shouldn't have been passed in as-is to TypeScript. If anything, the editor should use a flag like to blanket enable/disable other snippet features.
I don't see the removed setting anymore so marking as verified.
I'm using to mount a remote Azure Blob storage container into my local file system with FUSE. Once I open up that mount point (say ) in VSCode, network traffic immediately goes up to around 100 kb/s. In the storage provider's API logs I can see many thousand operation requests per second to files located at any hierarchy level inside my storage container, but also files that do not exists (e.g. ). I was assuming this is related to VSCode attempting to watch these files for changes, but can't use inotify on the remote share, so falls back to polling the files with a crazy frequency. However, applying the following settings didn't have any effect: Same issue occurs with or AWS S3 + and I presume also for sshfs, davfs2_ and the like. When killing the sub-process, I can observe a short decline in network usage until the process almost immediately restarts.
In this case I wonder if we should simply not install the file watcher at all if a setting is configured to disable it. I see no other workaround other than maybe addressing this in our external file watcher where we pass on these exclude rules.
Verification: run with and filter dev tools console to to see only file watcher related output configure to have an entry open a folder verify that in the output for the watcher you see no indication that the folder is being watched compare this to how the output looks like when you not have such a setting
<!-- 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: --<!-- 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. --Steps to Reproduce: created this simple snippet: I expand the snippet, I get this: Expected this: It uses the first variable as a part of the placeholder of the second variable. The second occurrence of the second variable is not substituted properly. !
Confirmed... Looks like we capture the value of 1 "replication". For now you can workaround by "inlining" the second occurrence of $1, e.g have two times
Type: <bBug</bSimple Browser to visit a webpage that offers a download. the download. happens :bug: I plan to submit a PR. VS Code version: Code - Insiders 1.80.0-insider (, 2023-06-14T09:02:23.566Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
<!-- 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
Version: 1.94.0-insider Commit: Date: 2024-09-09T17:10:54.809Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce:
<!-- 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: --<!-- 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.62.3 OS Version: Chrome Version 96.0.4664.55 (Official Build) (arm64) macOS 12.0.1 Steps to Reproduce: vscode web version on localhost (use any build similar to ). Make sure the test repository has a jpg file such as the . Use a chromium based browser (not safari). on a .jpg file in the side pane explorer. Note that it takes 1s for the image to load, even when hosted from localhost. Click back and forth on other files and note that text files display immediately but any custom editor or image viewer that uses a webview always pauses for a second before loading Chrome/Edge service worker console and look for the service- version; note that the version increments each time the same webview is opened (and closed). It takes approximately 1050ms to load every image as shown in the following screenshot ! The service-worker for any webview is instantiated inside  with a query string that includes the unique id of the host frame. This is not actually needed or used by the webview code in but causes chromium based browsers to reinstall and reactivate the service worker even though the underlying service-worker code has the same code, eTag and content hash. For some reason Safari does not have the same delay. If the code is changed to only include the query parameter actually used by the script then the end to end browser time is reduced to 50ms on localhost, a 95% reduction The slow load time is experienced when navigating ordinary files in the editor with no extensions installed.