jiebi/CodeConvo huggingface dataset:
Change:
constructor() { super({ <del> id: NotebookIndentUsingSpaces.ID, </del> <ins> id: NotebookIndentUsingTabs.ID, </ins> title: nls.localize('indentUsingTabs', "Indent Using Tabs"), precondition: undefined, });

Discussion:
to repro: click notebook indentations statusbar entry run "indent using spaces/tabs" and select a new number entry will not update, however indentations work correctly given the selection that the user made and the current settings.

No a "choose intentation type" entry in status bar when editing in a notebook. I have a notebook with tab indentation but it seems theres some global spaces setting that overrides it... even pasting a literal tab charachter inserts spaces :/ !
False alarm. The status bar entry just moved so much that I didn't see it right away, and it has a different name in the status bar entries context menu.
Actually, looks like the status bar is really slow to update. I saw it update eventually, but I'm not sure what caused it to finally show the correct thing. !
Change:
continue; } const isWrapped = buffer.getLine(i + 1)?.isWrapped; <del> this._bufferToEditorIndex.set(i, lines.length); </del> currentLine += line.translateToString(!isWrapped); if (currentLine && !isWrapped || i === end - 1) { lines.push(currentLine.replace(new RegExp(' ', 'g'), 'xA0'));

Discussion:
Using here, I cannot enter the accessible buffer https://user-
The issue is that here, the default tab behavior is to focus the terminal tabs element edit: hard to repro, that's not the cause
ok this happens when is not applied to . See here that the buffer editor does get focused here, but you cannot see it https://user-
Repro: run some commands - - - Try to wasn't applied to so the accessible buffer isn't visible
https://user-

Currently when you use navigate accessible buffer you get a quick pick with the options, I expected changing these to scroll to the position without accepting it, and escape to revert to the original scroll position.
As part of this, providing ~1/3 of the viewport of context above would also be good
We'd need to think about how we to communicate the preview information to a screen reader user, as a pre"view" is usually visual
I don't think making this available to the screen reader makes sense, it would just complicate navigating the list. It is useful for sighted users though.
Oh I understand now - you mean on change of the active quick pick item, reveal the line and on enter, focus that line (as it already does)
Yep
To verify, in a terminal with shell integration, run some commands. to enter the accessible buffer. to . Without pressing , use the arrow keys to go between the options. It should scroll to the command if it is outside of the viewport.
Works but I opened
Change:
{ "text": "}", "kind": "link" }, { "text": " b", "kind": "text" } ], noopToResource), <del> 'a [`husky`](file:///path/file.ts#L7%2C5) b'); </del> <ins> 'a [`husky`](command:_typescript.openJsDocLink?%5B%7B%22file%22%3A%7B%22path%22%3A%22%2Fpath%2Ffile.ts%22%2C%22scheme%22%3A%22file%22%7D%2C%22position%22%3A%7B%22line%22%3A6%2C%22character%22%3A4%7D%7D%5D) b'); </ins> }); });

Discussion:
<!-- 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: see below, pulled from the "Help About" dialog. Also confirmed in 1.71.2. OS Version: see below, pulled from the "Help About" dialog. Steps to Reproduce: above VSCode Insiders build. (Instructions don't require system path to be updated.) a directory in WSL, say . , where is the distro of your choice. the WSL extension as prompted and reload. the editor and run , where is the distro of your choice. (Steps 2-4 were just to initialize some VSCode state.) a new file in that directory with the following contents: restart editor. (Works either way.) over above. tooltip will appear with "some thing linking Foo" where is hyperlinked. Click the hyperlink in the tooltip. attempts to open a file at the path in the parent Windows OS, outside of any WSL distro. Note that this reproduces both with the WSL extension enabled the whole time (skipping step 5) and with it disabled at step 5.
Did this get missed?
I have the same issue with VSCode running in WSL2 (Ubuntu)
Same issue here, using a remote connection to a VM running on Hyper-V. Host OS is Windows, guest OS is Ubuntu 22.04. It only happens when clicking the link in the tooltip. Using directly in the editor works as expected.
Still seeing this issue. Looking forward to this getting resolved soon.

<!-- 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!
Change:
import { IThemeService } from 'vs/platform/theme/common/themeService'; import { Event, Emitter } from 'vs/base/common/event'; import { ILabelService } from 'vs/platform/label/common/label'; <del> import { getIconClasses, getConfiguredLangId } from 'vs/editor/common/services/getIconClasses'; </del> <ins> import { getIconClasses, detectModeId } from 'vs/editor/common/services/getIconClasses'; </ins> import { Disposable, dispose, IDisposable } from 'vs/base/common/lifecycle'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { withNullAsUndefined } from 'vs/base/common/types';

Discussion:
Issue Type: <bBug</bto something like . a new tab. The tab should have the Markdown icon, but it has the Plain Text icon. If you move to another tab then back, the icon will be updated. This only started happening when I updated to 1.3, and it's still happening in Insiders. I've got no extensions or settings (other than ) set. VS Code version: Code - Insiders 1.31.0-insider (, 2018-12-21T06:14:53.023Z) OS version: Darwin x64 18.2.0 <!-- generated by issue reporter --
This is a consequence of adopting : When the tab opens we immediately render the icon, but the resource only gets the mode associated after a on the end of the tick.
via
Change:
child.stdin.end(options.input, 'utf8'); } <del> const bufferResult = await exec(child, options.cancellationToken); </del> <ins> const bufferResult = await exec(child, options.cancellationToken, options.progress); </ins> if (options.log !== false && bufferResult.stderr.length > 0) { this.log(`${bufferResult.stderr}n`);

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --When downloading a GIT repository should indicate the percentage of download. <!-- Describe the feature you'd like. --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.484 --<!-- potentialduplicatescomment --
I would like to take this.
Change:
"name": "punctuation.definition.string.end.html" }, "1": { <del> "name": "source.css-ignored-vscode" </del> <ins> "name": "source.css" </ins> } }, "name": "string.quoted.double.html",

Discussion:
<!-- 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. --<!-- 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.71.0 Commit: Date: 2022-09-01T07:25:10.472Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Linux x64 5.10.7-arch1-1 Sandboxed: No Steps to Reproduce: a file with the contents: a SvelteKit project and open any file. as shown in the video. https://user- Result: Without a space - it doesn't work. With space - it works. Cause: When the cursor is in front of the character, it thinks it is already AFTER , although this is not true. PS The same problem is in the last character, before , in the file.
This also happens in the HTML with where being cursor position. The problem seems to be because the position of the cursor is on the border of the embedded language. Maybe it could be changed to using the previous character, when possible, instead of the next?
Thanks - I can reproduce what you are saying. I don't really know what svelte kit is nor what extension you are using. So, I am focusing on html. Using "F1 Inspect Editor Tokens and Scopes" shows me that the language at position is classified as html, not JavaScript. <img width="728" alt="Screenshot 2022-12-05 at 16 22 35" src="https://user-"Because of that no JS snippets are shown. Passing this on to who maintains the TextMate grammars for this.

An easy workaround on your end would be to configure the snippet to also work for the "outer" language
SvelteKit: SvelteJS is the 4th most popular framework (behind ReactJS Vue Angular), and considered to have the best DX of all frameworks. Extension for SvelteJS: But I hope that solving the problem in html/js, will also solve the problem in SvelteJS.
Related to
what do you think of modifying the solution to so that we don't ignore strings? PR
Change:
description: 'test', before: { content: 'bz' <del> } </del> <ins> }, showIfCollapsed: true </ins> } }, ]);

Discussion:
<!-- 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. --Currently, the inlay hints will clean and shows again as scheduler's strategy. It's might not friendly if you are editing some line who has many hints. I have an idea: Clean all hints where the cursor’s line when we are editing the code and append new hints by the scheduler. I think It's might improve the experience about inlay hints.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.494 --<!-- potentialduplicatescomment --
/gifPlease
!
I think inlay hints should disappear immediately if the surrounding text is deleted. Afaik, currently, when text gets deleted, decorations inside of that text get collapsed but are not deleted.
Yes, I agree that hints should disappear immediately when their "anchor" position is removed. Maybe it's not so easy to know what remove actually means in this case. Arguably this is an editor bug as I was expecting this to work?
I wouldn't call this a bug - decorations are never removed automatically. Alex suggests (I asked him before his vacation): I also suggest to extend the inlay hints API so that a hint refers to a range. The hint itself then can either be after or before the range. The range allows to better predict what should happen with the hint if the text changes. With injected text, we now have two cursor stops around inlay hints - both refer to the same model position. Maybe the move behavior of inlay text should depend on the view position where the text change was caused from? I suggest to think about how we can better predict synchronously how a text change affects inlay hints.
This is how we started, mostly to optionally support overlay hints, and everyone was confused about ranges for inlay hints. Using a range with before/after screams "position" and I don't want to leak an implementation detail into the API. We would also still have the case of empty ranges... I'd rather create "fake ranges" from positions so that I can use the notion of collapsed ranges.
I have pushed a change () to use the range of touching words of inlay positions (when possible).

In that case will be and my expectation was that decorations hide/disappear when removing all their text.. is that a bug in decorations land or am I using this wrong? Should I listen to decoration changes and "manually" remove them?
I think so, decorations are not removed automatically.
But what does mean then?
Ah, maybe I forgot to consider that flag for injected text, I'll look into it tomorrow.
Change:
"foreground": "#800080" } } <del> ] </del> <ins> ], "colors": { "actionBar.toggledBackground": "#dddddd" } </ins> }

Discussion:
Testing <img width="273" alt="image" src=""Should use a toggle state instead, or a new icon. You can see it looks the same as the other disabled action
I agree, but then this also applies to the "toggle whitespace" button. I think we need some pressed state for toolbar buttons. What are your thoughts ?
I'd prefer to have an icon per state. That's how we have done it in other toolbars (like output scroll lock).
<img width="584" alt="image" src=""Mockup with a toggled state. Having an icon per state makes sense for the lock icon, because the reverse icon metaphors make intuitive sense. This is not the case for the whitespace and fold icon here though. cc
We do use toggles elsewhere. One easy example: <img width="472" alt="CleanShot 2023-07-07 at 09 13 11 src=""But I think it depends what you're trying to do. Many boolean settings make sense as a sort of enabled/disabled toggle, while others are more specific metaphors (lock/unlock as Hylke mentioned above).
I'm still in favor of a toggle border as we already use this concept in the find widget and it is a universally understood concept, but has to agree. Alternatively, we can explore other icons. Or we leave it as is.
No, I don't need to agree (but also not to like it). If you wanna explore or something similar go ahead but we should be aware that this is also open to extensions, so we need to deal with every (contributed) button looking like this in the future
I think this approach looks good to me It is more aligned with the vs code current design and should be replaced the current find widget toggle ui
Verification steps: Notice that in the diff editor buttons have a background now to indicate their toggled state: !
Change:
import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { IConfigurationEditingService, ConfigurationTarget } from 'vs/workbench/services/configuration/common/configurationEditing'; import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; <del> import * as fs from 'fs'; </del> <ins> import * as pfs from 'vs/base/node/pfs'; import * as os from 'os'; </ins> import { flatten, distinct } from 'vs/base/common/arrays'; interface IExtensionsContent {

Discussion:
In the renderer we want to stay away from sync fs API calls to because each call will stop the VM from doing anything. We should try to use the async fs APIs. The code in question is:
What about ?
yes, I reported those at the same time I reported this one via
There about 20 files that I need to run the checks on (this will definitely grow). Assuming there are about 20 paths in the PATH env variable, that is about 400 file checks to make in the worst case scenario If I do all of this async, thats about 400 async calls made at the same time. This can have an adverse affect as well correct? Or it doesnt matter at all?
anything is better than doing it sync, especially if you are stat'ing 400 files which probably means that the user cannot do anything for a couple of 100ms. We have  that allows to batch resolve. my 2 cents: having to stat 400 files for a feature seems wrong to me, especially if this blocks a piece of UI from working properly. At the very minimum this should run in the background, maybe buffered and not block any UI from showing up.
Change:
// already removed removedKeys.push(key); // remove element from DOM <del> this.templateData?.outputContainer?.removeChild(value); </del> <ins> this.templateData?.outputContainer?.removeChild(value.element); </ins> this.notebookEditor.removeInset(key); } });

Discussion:
Notice the cell goes beyond the right margin. Seems to happen for all cells
is it related to the indentation change?
I don't think there's an issue here anymore? I did push a change to ensure that a line of text with no whitespace will break and not overflow. But I don't see any other issues with overflowing horizontally. I do see plain text outputs overflowing if I resize the editor to be narrower...
Change:
{ "command": "github.copyVscodeDevLink", "title": "Copy vscode.dev Link" <ins> }, { "command": "github.copyVscodeDevLinkFile", "title": "Copy vscode.dev Link" </ins> } ], "menus": {

Discussion:
Testing Of course, there may have been discussions and reasons for the current behavior, but I was surprised that the share action in the File menu linked to the line number of the currently opened editor. I was expecting a link to the workspace/repository only.
would you expect the same command from the editor context menu to use file+line number?
yes, my expectation would be the context menu has the "context" and therefore does have the file/line associated with it.
Change:
color: var(--vscode-activityBar-foreground); } <ins> .monaco-workbench .activitybar .menubar.compact > .menubar-menu-button:focus { background-color: var(--vscode-menubar-selectionBackground); } </ins> .monaco-workbench .menubar.inactive:not(.compact) > .menubar-menu-button, .monaco-workbench .menubar.inactive:not(.compact) > .menubar-menu-button .toolbar-toggle-more  { color: var(--vscode-titleBar-inactiveForeground);

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.88.1 OS Version: Windows 10 Enterprise 22H2 Steps to Reproduce: to to to location to which should switch to the (Hamburger menu) in the don't do so now, possibly due to the switching of the position of to the item and you'll see that the context menu opened is misaligned with the current position of the , this doesn't seem to be an issue when the location is to the only on the . Image: !
Hello! This has been bugging me for a while now (I use the sidebar to the right and the activity bar on top), so I decided to go ahead and try and fix this. I realized the underlying issue is that when the is to the left and you hide the , the hamburger button is placed to the left regardless of the position of the , but when the is to the right, its inconsistent (top right when both bars are to the right, but not when is right and is top), so my proposed fix is to move the hamburger button to the far right in the latter case, so its position is more consistent. ! ! ! ! Let me know what you think and I'll create the PR.
I fixed to position of the menu bar when the side bar is to the right. I check regarding alt moving focus to the compact menu and saw it does work, but we just don't show any indication that focus is there. Which we need to fix
Change:
<del> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16" enable-background="new 0 0 16 16" height="16" width="16"><path fill="#F6F6F6" d="M13 13h-10v-10h10v10z"/><path fill="#C5C5C5" d="M12 12h-8v-8h8v8z"/></svg> </del>  No newline at end of file <ins> <svg width="14" height="14" viewBox="0 0 14 14" fill="none" xmlns="http://www.w3.org/2000/svg"> <path d="M11 11H3V3H11V11Z" fill="#C5C5C5"/> </svg> </ins>  No newline at end of file

Discussion:
Start a long running search, notice the ugly stop icon I feel like somebody took the debug stop and stripped it of its color. Notice how it is too bright compared to the other icons. Also it feels a bit too large / too strong !
Should we use the exact same icon as the "Debug" stop icon maybe?
The Debug stop icon is red though, which aligns with the rest of the debug buttons that are multi-colored. Not sure if red would make sense here though: !
It goes with the redish clear. But still looks too strong and distracting for me. Why do we need a button for that in the end, why doesn't esc simply cancel the search?
I think ESC is not really discoverable and the button only shows up when search is taking a long time (as far as I remember). I don't mind the button there, but I am also not a big fan of the icon we have at the moment.
Typically you see an to cancel/stop progress, but we use that icon for closing items so it feels a bit out of place. Here's a few variations: ! I think an interesting idea is using the loading spinner and placing the stop icon on hover. Though we already have the viewlet progress indicator so it might be a duplication but the icon and interaction feels a little more natural: !
This is right, we used to get a lot of complaints about not being able to cancel a search.
I am not sure I would agree that X is used to stop a running operation, it feels to me the stop button makes more sense. I associate X more with closing something then stopping something.
here's a few examples where X is used to stop a running operation: <img width="50%" src="https://user-"<img width="50%" src="https://user-"<img width="30%" src="https://user-"If we want to keep using the "Stop" icon, we can either make the current one smaller and match the correct color or use an alternate stop icon: !
that icon might work in other apps, but in VSCode every usage of the "X" is for closing something, not stopping something.
agreed, I was just pointing out that other apps also use the X in other ways. What are your thoughts on either stop button?
how did the stop button change in the first screenshot?

It's subtle, I made it smaller by 2px, removed the white border, and used the same gray color as the other icons.
yeah let's try it out in insiders
Yeah without the border it at least looks better. We shuold try it out