jiebi/CodeConvo huggingface dataset:
VSCode Version: 1.36.0 OS Version: Windows 10 / Mac OS Steps to Reproduce: any c++ code inside of a .cpp/h/hpp etc file. "/" at the begging of of a line that has already been written "/" gets automatically afterwards, but before the code, so nothing actually gets commented out Simple example, where "|" denotes the cursor position: "/*" shouldn't auto-add the end symbol of the comment block by default, should be setting controlled, and should be able to recognize when it's been entered at the start of a line. Does this issue occur when all extensions are disabled?: Yes Originally reported here: They forwarded me to you folks, so I'm assuming this was to the "C/C++ Language Basics" built-in extension without a setting to control it. Please for the love of god fix this. It's super annoying.
Found a temporary workaround: to: (User Folder)AppDataLocalProgramsMicrosoft VS Coderesourcesappextensions "cpp" to (User Folder).vscodeextensions it something like "cpp.language-basics-custom" to avoid any later confusion. "language-" & comment out (or remove) this line: the trailing comma in the previous line (might not be necessary) VS Code. The custom version should take precedence over the built-in version. Comment blocks will no longer auto-close.
Also, of note: Neither javascript nor typescript contains that in their language- files, but uses the same style of block comments. I think it's safe to say it should just be removed from the cpp language-
It looks like C# and json use the as an auto closing pair, but java, javascript, php, and typescript use the . For C languages we whould use since it is more consistent.
Fix will be available in next insiders if you want it ASAP. It installs side by side with stable, so you can have both:
the C/C++ extension already registers a custom , including for . Please don't add autoClosingPairs for comments since there is no way to disable them in vscode. There are only settings for and . I seem to recall these all being controlled by a single setting at some point, but now there are only 2 out of 3 available.
Visual Studio Code lacks support for automatic comment-block ending in C and C++. If you were to start a comment-block with , an automatic will not be as it would be in the traditional Visual Studio. When I type , it should automatically be turned into and the text cursor should be between the two ``. It isn't that big of a deal but it would be really nice to have this feature in Visual Studio Code.
Ugh. I currently have the exact OPPOSITE problem: I want to DISABLE this feature. This is happening for me and I can't figure out how to turn it OFF. There are a large number of developers who just don't ever want their text editor to ever, under any circumstances, insert a character that did not correspond exactly 1:1 to a specific keystroke. I push "A", I get "A". And so on. "Surprises" break my flow worse than any other kind of interruption. Obviously, there are a lot of developers in the other camp. But the upshot is that the fact that both camps exist, and both camps are large, means that when features like this exist, it needs to be possible to disable them. I have encouraged many projects for years to consider adding a "dumb as a brick" switch that will just globally disable all of these. In the absence of a master switch, we at least need configuration switches that can shut these things off-- preferably arranged hierarchically, so that we can shut off entire branches. But the absolute lowest rung on the ladder is that individual switches must exist to disable these things.
Let's track in
Issue Type: <bBug</bmultiple brackets "" Expected: All cursors at brackets become selections starting where the original cursor was and and ending at its matching bracket. Actual: Only the first cursor becomes a selection, the rest dissapear. VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.3.0 </detailsReproduces without extensions <!-- 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.531 --- <!-- score: 0.527 --- <!-- score: 0.498 --- <!-- score: 0.498 --<!-- potentialduplicatescomment --
Issue Type: <bBug</bThe preview in the minimap slider is wrong when: The minimap is NOT overflown (doesn't need to scroll internally when the editor is scrolled) is (default value) When is set to , the preview is shown as expected. Reproducible without extensions: Yes ! The slider preview ends at the beginning of the block comment, while it should contain a portion of it. VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: Windows_NT x64 10.0. <details<summaryExtensions (15)</summaryExtensionVersion ------ gitstash2.1.0 bracket-pair-colorizer-20.0.28 vscode-eslint1.8.2 todo-tree0.0.129 svg0.1.4 tag-rename0.2.1 vscode-simple-icons1.11.4 dotenv1.0.1 vscode-docker0.6.1 vscode-javascript-booster0.10.2 code-settings-sync3.2.9 markdown-preview-enhanced0.3.13 code-spell-checker1.7.0 language-pde1.3.0 markdown-all-in-one2.2.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
A new observation: It's not about the state of the window (maximized/restored), it's about weather the minimap is overflown or not (needs to scroll internally when the editor is scrolled). I edited the issue accordingly.
Another observation: has no effect on the issue either. The problem is that the minimap height is not calculated correctly when is , the extra lines that this setting adds are not accordingly to the minimap height, only when it's NOT overflown (i.e. when ).
Testing <img width="348" alt="image" src="https://user-"
Extension fails to launch child_process during initialization Will check if the issue is isolated to this extension with a minimal example using module
Was able to isolate the issue, firstly as pointed above the extension makes an attempt to launch a child process via the helper which basically emulates options and passes them eventually into Since variant relies on when node executable path is not provided, this will default to use the Electron executable that is used to create the extension host. Now there are two problems with this usage, (i) execa module will not add the env variable, so the exectuable cannot be launched as intended. (ii) We also disable calling Electron executable as unless flag is provided in the call site. For the (ii) we automatically add the flag at both and callsites internally in the runtime, so this should not be a concern for the extension authors. As for (i), if the extension author used the vanilla then the env variable would be set internally by the runtime. But since the call is done via a 3rd party module, I think it is upto the extension authors to ensure the env variable is provided if they rely on the Electron executable. I feel like there is no action required from runtime/VSCode core for this issue, but we should loop in the extension author to fix this on their end. Thoughts ?
So what exactly is different in the utility process vs. child process today? I did not fully understand.
When extension host is created via , internally the runtime would launch the process with env variable set and we never remove this variable explicitly in the extension host after launch (i-e) , this would indirectly help above scenarios since the env gets inherited by extensions. This is not the case with utility process since there is no runtime induced env variable, the extensions have to explicitly add them if they rely on the electron executable. I would say the previous behavior was a hidden bug and is visible now with the utility process api.
Oh yeah understood! I think I somewhat agree that we need to just document this to extension authors.
btw, since this is a public issue, I've shared it with the dendron extension author directly to track
hey, dendron author here. thanks for looping us in on this. so as I understand, we have two options: either use vanilla or set when using the module.
is this an accurate understanding?
yup that is correct. To clarify, only when ends up using on the desktop extension host.
Got it. What's the timeline for us patching this? Is this already live in insider?
The change is not default in insiders yet, it is currently behind an environment variable , can give more context on the timeline.
after discussing with the team, we have decided to push a workaround in core to avoid breaking the extension community with the new process type for extension host. You don't need to make the adjustments outlined in
see gif have the debug hover above the cursor expand some objects the hover grows over the current line/cursor !
Yeah, this is a consequence of the change to not make it jump. Since in this scenario it does not have enough space above to grow, it can only grow over the line and below. Alternative would be to show it down, which would cause a jump. Or to limit the size, that it does not grow over the current line. That I think makes sense. However will not tackle during endgame.
How about not growing and use the scrollbar sooner? Just measure the max size above the cursor and don't go over that
I think this makes sense. My current max height is 70% of the editor height. Idealy as you suggest the max height should be the size above the cursor if I am placed above, or max size below the cursor if I am placed below. However I am not aware of editor API that gives me height above or below the cursor. Are you already using something like this for the suggest?
I am using and some math:
<!-- 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.85.2 OS Version: Windows 11 Enterprise (Windows_NT x64 10.0..3007) Description During an accessibility test, we found the contrast ratio between the highlight color of the focused button in "More Actions..." in notification popup and its background is not high enough under "Default Dark Modern" theme. Highlight Color: Background Color: Contrast Ratio: 1.346:1 Required Contrast Ratio: 3:1 !
I think this refers to the background color of the gear icon in the toolbar of a notification relative to the background color of the notification.
The bug reported on my side particularly specified the "Manage Extension" button highlight color and the background color of that actions popup under settings icon in the notification.
Looks like it's about the blue on black bg, in that case this applies to all the web menus in VS Code.
yes, it's about the blue highlight and black background.
A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Win32; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Aug2023; #WCAG1.4.11; #Non-text Contrast;
Hi, is there any update on the plan of fixing this accessibility bug?
putting this on the March plan.
Hi, may I check if the fix is included in v1.88.0?
Hi, I have checked v1.88.0 but it seems the active color is still not the one you changed to in your PR. Did I miss something?
<!-- 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.73.1 OS Version: macOS Ventura 13.0.1 Steps to Reproduce: VoiceOver a command that uses a Quick Pick List where the items have a as well as a title or description (demoed with Azure Extension "Create Resource") list a command that uses a Quick Pick List where the items have no detail, e.g. "Select Display Language" or even command palette reader will read the title of the new item with the detail of the item in the previously displayed quick pick list https://user- Same bug with the command palette reading details for items: https://user-
This issue is caused by the item still containing the values from the previous list.
Verification steps: the issue steps are good. If you want a non-Azure extension command that shows a quick pick with details, use
Issue Type: <bBug</bCompared to input boxes in other viewlets, the search box in the extensions viewlets looks slightly different with a little padding of a different color inside the box. VS Code version: Code - Insiders 1.27.0-insider (, 2018-08-15T05:19:24.200Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<!-- generated by issue reporter --
This appears to be because the sets the background color to a transparent color (), if that is changed to , the look is the same but without the border. This seems like incorrect behavior of the renderer, as the type of color shouldn't affect what gets colored.
Actually, looks like the transparency is showing up differently on the different backgrounds. If you increase the alpha, it starts to look like this: ! I'll look in to making the transparency affect both equally
<!-- 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.81.1 OS Version: win10 Steps to Reproduce: new version vscode after 1.78.2 remote connection before vscode 1.78.2 in win 10 right click win10 taskbar show remote connect like ! but recently I update my vscode to 1.81.1, the information for remote node disapear. ! This bug is quite inconvenience when I have many projects with the same name in different remote nodes.
Same Issue Here
Do you own this part of the label service Aware of any changes?
Not much padding between it and the word: ! !
Passing to as this is a file icon but in the icon we actually have it designed at 14px scale (and offset to avoid pixelation) and i know the file icons use different scaling styles <img width="568" alt="CleanShot 2022-06-17 at 12 33 56 src="https://user-"
The trust editor uses a product icon (codicon) as editor icon here: I think this needs to be adjusted there.
I've had a couple of people report debug adapter crashes recently. One of them I'm unable to reproduce which means I need to get more information from the user. Currently, when a debug adapter crashes, the error information that appears in the console is very vague: ! The actual exception that was thrown is not shown. Since I can't repro this, the only ways I can think of to debug are: try/catch around all debugger methods that handles errors and passes them back nicely (and remember to do this for all future methods) the user to run my project from source and debug the debug adapter to catch the error (whilst not the hardest thing in the world, it's a bit involved for an end user) Is it possible to get better information from the error back into the console without having a debugger attached to debug adapter?
I don't know if the text "ERR" in the console was actually supposed to be my error; but it isn't. My error was "AAAAAARGH".
this request makes sense. Not sure though if I am getting your error when your process crashes. Can you be so kind and set a breakpoint make your server crash and check if your message is coming through as a or as something else. Thanks
Do you mean the text? I also don't get that now when trying to repro, only the "terminated unexpectedly" message. If you still want me to try that breakpoint, can you explain how to add a breakpoint there. I did try breaking in my adapter and navigating the callstack (that file wasn't in there anywhere) and also checking the filenames of the files that were (they showed ).
I mean let's try to see if your error "AAAAARGH" surfaces on our side. You should be able to just run regular vscode, F1 open developer tools, wait some time and put a breakpoint by openning a . Also try to put a breakpoint and check if the error stream spits up something.
The breakpoint is not hit, which is perfectly normal since the exception occurs before the socket connection is created. You should be able to reproduce by adding require('unknown_module') to the top of any debugger extension .js file
Ok, I got breakpoints in both and . First wasn't called and the second was called but is and is . So seems like the message isn't there.
For testing, all I've done is put inside my debug adapter. Though now I think about it; the error isn't occurring in code that's been executed directly by Code - it's during the response from my debugger. In my debug adapter I spawn a process and I add a handler for . When something comes over and my callback runs, that's where the crash is occurring. I don't know if this changes things (for example, I don't know if this is on another thread?).
That one (in ) didn't seem to be hit either.
Actually, I think I can repro this really easily by just putting in the constructor of the ? Also gets .
This issue has the needs-more-info tag though I think it's easily reproducible with my last comment. Let me know if that's not the case!
I have removed tha tag and plan to look into this issue this week. Thanks
Investigated and the issue here is that I am not getting any exception data from the spawned process. I simply get the code while all the other error chanels are blank. I am not sure what would be the proper solution here. Suggestions are very welcome. Also are all your debug adapters launched using node? If yes then it might be that our  launch is somehow eating up the error if it happens on startup. If this also happens for adapters which are not realying on node to be launched then is not to blame.
please try to disable the launch for node () and see whether this makes a difference. DAs should work independent from . But make sure that the node version used is roughly the same as Electron's version (i.e. 7.9.0).
Yes, using stdfork is the cause here. If I do not use it, I nicely get the error popping up in the extensions output channel. My weekend is starting if someone is feeling smart code review and let me know if you find something fishy about stderr not being wired through.
Then you might want to involve/assign
I am going on a vacation tomorrow evening, and this is like this since forever so pushing to April to investigate with Alex what is going on behind the curatans here.
Because both colors are blue they become hard to read and fail the color contrast ratio. Would expect for the highlighted text in these selected states to become white. Outline Breadcrumb cc
can you also attach the look for quick open after this change? and would this change be for the light theme only or all themes?
I can't find an example that uses selection for quick open, do you know of one? And this change would be the new default for the breadcrumb/outline view, so it would affect all themes that use the "light theme" defaults in those two views. It's currently broken and was hard to see in our previous color as well: !
yeah, none of the pickers use selection color, I was more referring to how quick open would look like if you change highlight color to white. My understanding is that this would have an impact pretty much everywhere where highlighting is being used (independent from the tree or not)
To clarify: this would affect all light themes, even the ones in the market place? or only our light theme
sorry if I wasn't clear, my intention is to only change the highlight color when it's on a selection row. So I'm not intending to change the default highlight color. In the example below, the highlight color remains the same except when it's selected: ! I still need to investigate how to do this, but my suspicion is that we already make the text lighter on a selected row, so I'd explore doing something like while it's selected. yes, this would affect all light themes.
but there is only , we do not distinguish the highlight color based on the type of selection currently. that sounds like it could break many themes because the change from our current blue to white is quite a different color. if this was an issue for any of the themes in the marketplace, they would have fixed this already I suppose.
me do some investigation to figure this one out.
I think the point is the we don't have (and want) a highlighted-and-selected-foregournd-color but that the selection color always wins.
The highlight color on the dark theme also fails the color contrast ratio (3.2:1): !
<!-- 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. --Version: 1.58.0-insider (user setup) Commit: Date: 2021-07-01T09:30:57.217Z Electron: 12.0.13 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: error I think only occurs using Workspaces. A single project, the terminals seem to work fine. However, with multiple projects, the environment gets confused. Terminal (ctrl+shift+) Terminal I get this error message: 'The termial process failed to launch: Starting directory (cwd) "homeusernamemyproject"'. The first terminal works, but it's the second or subsequent terminal that creates the error. This is using the VSCode for Windows using WSL Remote. This error has now existed for at least a week in the Insiders edition. I am surprised this has not already been brought up. I think the error is indicating that its confusing a windows path for a linux path. Because this is using WSL-Remote, the path should be using forward slashes not backslashes for windows. This happens when "terminal.integrated.splitCwd" is inherited or initial. The workaround is to set this to workspaceRoot, then it works. However, it's annoying not to have inherited or initial working. Also, nowhere in my settings is "cwd" assigned anywhere.