jiebi/CodeConvo huggingface dataset:
Change:
DOM.removeNode(this.overflowMenu.titleElement); DOM.removeNode(this.overflowMenu.buttonElement); <ins> this.overflowLayoutScheduled = dispose(this.overflowLayoutScheduled); </ins> } blur(): void {

Discussion:
There is signed of the explorer getting slower during the last days: <img width="387" alt="screenshot 2018-12-06 at 14 06 20" src="https://user-"
adding cos is busy and you probably know the explorer well... Not sure that promise adoption caused this - file operation have always been properly async...
One of my suspisions might be the changing of startup phases in addition to promise adoption. has the overall startup speed changed, or only the explorer got slower? Also can you see the change when you measure locally? If yes we can do some bisection to find the cause. Did all viewlets get slower? Also there has been no code changes in the explorer this milestone thus my reason for suspecting other things.
My =change touched a ton of promises, not just file service, so it could well be related. I saw a bit of places in the file service that were not truly async, e.g. where was used.
Blaming this on the promise-adoption is easy, but we all know by now they run on and it would require loads of them to get 50ms extra...
I am not worried about the time a takes, but rather the fact that our execution order of things on startup is changing by adopting because we have many places where code is now running on that previously was running sync in places where we wrapped a complete value into a promise under certain conditions.
Maybe I understood wrong but that shouldn't happen unless those things also run via , right? Ticks (multiple) are processes at the end of an event loop cycle and only then comes the next event.
yeah that might be true (hopefully is). I am running test now on Linux with a commit from 26th of November vs. today to see if there is something.
Bisecting on Linux I see a slowdown from to for the restoring of viewlet through:
Nice find, I will verify on Windows. I verifeid that on OS X there is no slowdown, which is correlated to the fact that menus are the cause (since we do not use custom menus on OS X)
To proove the theory: disabling custom title bar on Linux restores the good time for me on that commit.
does the overall startup time get 50ms slower too, or is it just reflected in the explorer?

I'd say that's because 99% of startups open the explorer when opening the editor. These are great findings.
it looks like the workbench ready time is actually worse when the native menu is enabled for me, so overall I see no total slowdown. Also the editor restore seems to be roughly the same with custom and native title.
this seems to be caused by  being called during startup which seems to access DOM properties that cause a forced layout. If I comment out that method, I see the normal times reported. I suggest you check if this method could be called after a delay, e.g. via
Change:
leftButton: this._mouseState.leftButton, middleButton: this._mouseState.middleButton, <ins> onInjectedText: position.type === MouseTargetType.CONTENT_TEXT && position.detail.injectedText !== null </ins> }); } }

Discussion:
have an inlay hint with command double click the hint to run the command the current word is selected too
I believe this needs some changes in the editor. Preventing default on the mouse event doesn't seem to fix it.
What should happen when the user clicks on an inlay hint for a single time?
Nothing, unless it's a cmd/ctrl-click on an active label part link
Change:
}; const preferredDarkThemeSettingSchema: IConfigurationPropertySchema = { type: 'string', // <del> markdownDescription: nls.localize({ key: 'preferredDarkColorTheme', comment: ['`#{0}#` will become a link to an other setting. Do not remove backtick or #'] }, 'Specifies the preferred color theme for dark OS appearance when `#{0}#` is enabled.', ThemeSettings.DETECT_COLOR_SCHEME), </del> <ins> markdownDescription: nls.localize({ key: 'preferredDarkColorTheme', comment: ['{0} will become a link to another setting.'] }, 'Specifies the preferred color theme for dark OS appearance when {0} is enabled.', formatSettingAsLink(ThemeSettings.DETECT_COLOR_SCHEME)), </ins> default: ThemeSettingDefaults.COLOR_THEME_DARK, enum: colorThemeSettingEnum, enumDescriptions: colorThemeSettingEnumDescriptions,

Discussion:
open the settings, in the filter box enter . Check the settings description. It should contain links. The links use a special syntax: that must not be changed. The translated string has a message mentioning that. !
Thank you for your feedback. We are currently reviewing it (reference ).
could you please lock the placeholders with these annotations? I'll fix the local translation meanwhile.
I've got a fix out ^^
Verified in code while the translation is in work.
Change:
assert.deepEqual(thisModel.getWordAtPosition(new Position(1, 27)), null); assert.deepEqual(thisModel.getWordAtPosition(new Position(1, 28)), null); }); <ins> test('getWordAtPosition at embedded language boundaries', () => { const outerMode = new OuterMode(); const innerMode = new InnerMode(); disposables.push(outerMode, innerMode); const model = TextModel.createFromString('ab<xx>ab<x>', undefined, outerMode.getLanguageIdentifier()); disposables.push(model); assert.deepEqual(model.getWordAtPosition(new Position(1, 1)), { word: 'ab', startColumn: 1, endColumn: 3 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 2)), { word: 'ab', startColumn: 1, endColumn: 3 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 3)), { word: 'ab', startColumn: 1, endColumn: 3 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 4)), { word: 'xx', startColumn: 4, endColumn: 6 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 5)), { word: 'xx', startColumn: 4, endColumn: 6 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 6)), { word: 'xx', startColumn: 4, endColumn: 6 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 7)), { word: 'ab', startColumn: 7, endColumn: 9 }); }); </ins> });

Discussion:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?
Change:
{ dark: '#ffea0047', light: '#ffea0047', hcDark: '#ffea0047', hcLight: '#ffea0047', }, localize('mergeEditor.conflictingLines.background', 'The background of the "Conflicting Lines" text.') ); <ins> const contentTransparency = 0.4; export const conflictInput1Background = registerColor( 'mergeEditor.conflict.input1.background', { dark: transparent(mergeCurrentHeaderBackground, contentTransparency), light: transparent(mergeCurrentHeaderBackground, contentTransparency), hcDark: transparent(mergeCurrentHeaderBackground, contentTransparency), hcLight: transparent(mergeCurrentHeaderBackground, contentTransparency) }, localize('mergeEditor.conflict.input1.background', 'The background color of decorations in input 1.') ); export const conflictInput2Background = registerColor( 'mergeEditor.conflict.input2.background', { dark: transparent(mergeIncomingHeaderBackground, contentTransparency), light: transparent(mergeIncomingHeaderBackground, contentTransparency), hcDark: transparent(mergeIncomingHeaderBackground, contentTransparency), hcLight: transparent(mergeIncomingHeaderBackground, contentTransparency) }, localize('mergeEditor.conflict.input2.background', 'The background color of decorations in input 2.') ); </ins>

Discussion:
Note all three lines highlighted with background color <img width="262" alt="CleanShot 2022-09-08 at 16 01 57 src="https://user-"We only highlight the changed line and specific word. <img width="184" alt="CleanShot 2022-09-08 at 16 02 04 src="https://user-"If we followed the inline style and still rendered a word diff, wouldn't we be able to get away without using the borders to indicate the region? cc
The inline style does this because it has no clue about the actual conflict, it just sees the conflict markers. We do this to show the actual change in that side.
I a hidden setting (default false) so we can play with idea. Personally, I think it hides many important decorations, but I'm open to exploring it. Enabled: ! Disabled: ! The background color disappears when the conflict is handled.
Change:
private _throwIfStrict(msg: string, printWarning: boolean): void { if (printWarning) { <del> console.warn(printWarning); </del> <ins> console.warn(msg); </ins> } if (this._strict) { throw new Error(msg);

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/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: from commit to the latest version OS Version: win 10 Steps to Reproduce: Actually I'm not sure if it's been designed to be so but the logic is unresonable. In file srcvsplatforminstantiationcommon there's a code block as below ! It seems will always output but not detailed message. Not sure if you guys have already noticed this and if it's designed to be so.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Change:
// find it in our text file models. Currently, only textual editors // support embedded editors. const focusedCodeEditor = codeEditorService.getFocusedCodeEditor(); <del> if (focusedCodeEditor instanceof EmbeddedCodeEditorWidget) { </del> <ins> if (focusedCodeEditor instanceof EmbeddedCodeEditorWidget && !focusedCodeEditor.isSimpleWidget) { </ins> const resource = focusedCodeEditor.getModel()?.uri; // Check that the resource of the model was not saved already

Discussion:
We use in some places to get at the currently focused code editor. To my surprise, this method seems to be returning that are used for example as Copilot chat input. I would argue that in most if not all our usages, we only care about text editors that contain contents of a document, but not input fields like that. Can we add some kind of filter logic or a way for the caller to know if the returned editor is used as input field?
I don't know exactly what uses, but can be used to find out if this editor instance is an "input field".
Got it, I am not sure how big of an issue this is today for everyone using the API, but I will check for my usages.
Yeah, that's what I use too
Change:
return; } <del> if (matchesScheme(link, Schemas.command)) { const ret = /command:workbench.action.openLargeOutput?(.*)/.exec(link); if (ret && ret.length === 2) { const outputId = ret[1]; this.openerService.open(CellUri.generateCellOutputUri(this.documentUri, outputId)); return; } console.warn('Command links are deprecated and will be removed, use message passing instead: https://github.com/microsoft/vscode/issues/123601'); } if (matchesScheme(link, Schemas.command)) { if (this.workspaceTrustManagementService.isWorkspaceTrusted()) { this.openerService.open(link, { fromUserGesture: true, allowContributedOpeners: true, allowCommands: true }); } else { console.warn('Command links are disabled in untrusted workspaces'); } } else if (matchesSomeScheme(link, Schemas.vscodeNotebookCell, Schemas.http, Schemas.https, Schemas.mailto)) { this.openerService.open(link, { fromUserGesture: true, allowContributedOpeners: true, allowCommands: true }); </del> <ins> if (matchesSomeScheme(link, Schemas.vscodeNotebookCell, Schemas.http, Schemas.https, Schemas.mailto)) { this.openerService.open(link, { fromUserGesture: true, allowContributedOpeners: true, allowCommands: false }); </ins> } }));

Discussion:
A remote code execution vulnerability exists in VS Code 1.71 and earlier versions for malicious notebooks. These notebooks could use command uris to execute arbitrary commands, including potentially dangerous commands The fix is available starting with VS Code 1.71.1. The mitigates this attack by performing input validation on the URL pointing to the repository to be cloned. Do not open notebooks from untrusted sources. The patch for this can be found at An advisory for this can be found at MSRC details for this can be found at
the docs and advisories say it's fixed in 1.71.1, but it's only fixed in 1.72.1
Change:
import { NotificationsListDelegate, NotificationRenderer } from 'vs/workbench/browser/parts/notifications/notificationsViewer'; import { CopyNotificationMessageAction } from 'vs/workbench/browser/parts/notifications/notificationsActions'; import { IContextMenuService } from 'vs/platform/contextview/browser/contextView'; <del> import { assertIsDefined, assertAllDefined } from 'vs/base/common/types'; </del> <ins> import { assertAllDefined } from 'vs/base/common/types'; </ins> import { NotificationFocusedContext } from 'vs/workbench/common/contextkeys'; import { Disposable } from 'vs/base/common/lifecycle'; import { AriaRole } from 'vs/base/browser/ui/aria/aria';

Discussion:
Testing Repro: screen reader mode the editor the show notification command, :bug: the editor is still focused the show notification command, the notification center is now focused?
My notification was read once fully, then the screen reader started reading it a second time. Part way through that second time, the notification no longer seemed selected (didn't have a blue box around it), and the screen reader just stopped reading it.
the looks correct here, but I can repro the focus getting stuck in the editor any thoughts would be appreciated
Change:
this.logEvent(eventNameOrException, data); } else { // TODO @lramos15, implement cleaning for and logging for this case <del> this._appender.sendErrorData(eventNameOrException, data); </del> <ins> this._sender.sendErrorData(eventNameOrException, data); </ins> } }

Discussion:
This looks like we have telemetry loggers without appenders. Can we add a strict check or in the API impl?
Change:
return; } <del> this.isAnyRepositoryCollapsibleContextKey.set(this.scmViewService.visibleRepositories.some(r => this.tree.hasElement(r) && this.tree.isCollapsible(r))); this.areAllRepositoriesCollapsedContextKey.set(this.scmViewService.visibleRepositories.every(r => this.tree.hasElement(r) && (!this.tree.isCollapsible(r) || this.tree.isCollapsed(r)))); </del> <ins> this.isAnyRepositoryCollapsibleContextKey.set(this.scmViewService.visibleRepositories.some(r => this.tree.hasNode(r) && this.tree.isCollapsible(r))); this.areAllRepositoriesCollapsedContextKey.set(this.scmViewService.visibleRepositories.every(r => this.tree.hasNode(r) && (!this.tree.isCollapsible(r) || this.tree.isCollapsed(r)))); </ins> } collapseAllRepositories(): void {

Discussion:
/folder that contains multiple git repositories the 3rd repository from the list of repositories the window multiple times and you might see the following error in the console
Change:
display: flex; -mox-box-sizing: border-box; box-sizing: border-box; <del> padding: 0px 20px 0px 20px; </del> <ins> padding: 0px 26px 0px 26px; </ins> background-repeat: no-repeat; background-position: 2px 2px; white-space: nowrap;

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/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: OS Version: Type: Bug Using editor.experimental.useCustomCodeActionMenu, the menu doesn't match up with the colors of enabled/disabled options or the background of the other context menus

Type: <bBug</bmenu the window Bug The widget ends up being incorrectly positioned: <img width="672" alt="Screen Shot 2022-07-21 at 1 24 17 PM" src="https://user-"VS Code version: Code - Insiders 1.70.0-insider (Universal) (, 2022-07-21T05:17:20.056Z) OS version: Darwin x64 21.5.0 Modes: <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
// e.g.  * ...| or */| or *-----*/| "unIndentedLinePattern": { "pattern": "^(t|[ ])*[ ]*[^/]**/s*$|^(t|[ ])*[ ]*/s*$|^(t|[ ])**([ ]([^*]|*(?!/))*)?$" <ins> }, "indentNextLinePattern": { "pattern": "^.*=>s*$" </ins> } }, "onEnterRules": [

Discussion:
Type the following in a TS filePress Enter after the arrow. The cursor is not indented (here cursor is shown by | symbol):We should instead have:
Change:
return !!DOM.findParentWithClass(<HTMLElement>this.rootElement.ownerDocument.activeElement, 'context-view'); } <ins> private refreshSingleElement(element: SettingsTreeSettingElement): void { if (this.isVisible()) { this.settingsTree.rerender(element); } } </ins> private refreshTree(): void { if (this.isVisible()) { this.settingsTree.setChildren(null, createGroupIterator(this.currentSettingsModel.root));

Discussion:
Regression from I haven't identified when the issue started happening again. Repro steps: to the Settings editor down on a checkbox or edit an inputbox on an unmodified setting, and wait for the setting to become modified, or click another nearby setting. :bug: The Settings editor settings tree jumps.
I noticed the following: Not rendering the Settings indicator labels does not fix the issue After a setting value changes, is called. Then, when is called during , the setting tree elements are all smushed together. That behaviour is even more dramatic when a setting has a multi-line description. calls , which sets the top of the DOM node to an incorrect value. It looks like the value that is used is an estimate. I believe this estimation process is what causes the settings tree elements to shift upwards and smush together.
Note, the jittering is on the right side, not the tree on the left. Regardless, this looks good to me. I could only repro in Stable on checkboxes, other types of settings didn't show the "jump".
Change:
private fillDefaults(): void { this.add('msCompile', { <del> regexp: /^(?:s*d+>)?(S.*)((d+|d+,d+|d+,d+,d+,d+))s*:s+((fatal +)?error|warning|info)s+(w+d+)s*:s*(.*)$/, </del> <ins> regexp: /^(?:s*d+>)?(S.*)((d+|d+,d+|d+,d+,d+,d+))s*:s+((?:fatal +)?error|warning|info)s+(w+d+)s*:s*(.*)$/, </ins> kind: ProblemLocationKind.Location, file: 1, location: 2,

Discussion:
Type: <bBug</bIncluding a non-existent file in C++ causes an error that does not get matched. The problem is that the regex will match "error" but not "fatal error" (or "fatal error" with 2 spaces in the case of invoking msbuild instead of cl). VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-24T05:23:09.316Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I have a PR available for this:
I don't get a useful message about the problem in the problems view: <img width="317" alt="image" src=""Test task (for Windows at least):
I took a look at the PR for this to see if the problem matcher ever includes a message, and it does. The PR adds an optional group but doesn't increment the group numbers that each part of the problem is set as. I'm not sure how this would work for an optional group.
Please feel free to mark as verified if this is good enough.
pretty sure you found a bug. changing to will exclude the group from the result and not mess with the group indexes.
I do get a useful message now: <img width="1413" alt="image" src=""However when running Alex's provided task for the first time, I was prompted about which problem matcher I wanted to run on the output, and I don't think I should have to specify that again if my task already included a specific problem matcher
Change:
} } <del> class ShowCtrlHoverAction extends EditorAction { </del> <ins> class ShowDefinitionPreviewHoverAction extends EditorAction { </ins> constructor() { super({ <del> id: 'editor.action.showCtrlHover', </del> <ins> id: 'editor.action.showDefinitionPreviewHover', </ins> label: nls.localize({ <del> key: 'showCtrlHover', </del> <ins> key: 'showDefinitionPreviewHover', </ins> comment: [ <del> 'Label for action that will trigger the showing of a ctrl+hover in the editor.', 'This allows for users to show the ctrl+hover without using the mouse.' </del> <ins> 'Label for action that will trigger the showing of definition preview hover in the editor.', 'This allows for users to show the definition preview hover without using the mouse.' </ins> ] <del> }, "Show Control Hover"), alias: 'Show Control Hover', </del> <ins> }, "Show Definition Preview Hover"), alias: 'Show Definition Preview Hover', </ins> precondition: undefined }); }

Discussion:
IMHO using the keyboard modifier name in the action is not good, as IMHO the action name should describe what the action does, not one way in which the action is triggered. This gets very confusing when configuring . In this case, the definition preview is rendered in the editor hover with + hover. Perhaps a better name would be "Show Definition Preview Hover".
Thank you!
Release notes still use the old terminology: ! Version: 1.40.0-insider (user setup) Commit: Date: 2019-11-06T16:58:49.777Z Electron: 6.1.2 Chrome: 76.0.3809.146 12.4.0 V8: 7.6.303.31-electron.0 OS: Windows_NT x64 10.0.
stable release notes should have the updates, thanks for checking it out