jiebi/CodeConvo huggingface dataset:
Change:
write('suggest.filteredTypes', undefined); } }); <ins> registerEditorSettingMigration('quickSuggestions', (input, read, write) => { if (typeof input === 'boolean') { const value = input ? 'on' : 'off'; const newValue = { comments: value, strings: value, other: value }; write('quickSuggestions', newValue); } }); </ins>

Discussion:
Currently, the setting doesn't render in the Settings editor, because the Settings editor cannot handle settings with types. The current accepted values are of the form Questions: is the difference between and or and for each field? just a shorthand for setting each field to ? If we can change the setting configuration so that it is just an object with fields "strings", "comments", and "other", and the value for each field is an enum of options , then the setting can render in the Settings editor UI. Along with changing the type over, we'll have to migrate the setting value for users still using the old setting value. I believe Emmet has example code for this process for the setting .
Yeah, there is a lot of history: it started with a simple boolean, become an object with booleans, and it now an object with enum values. When working on I tried to simplify the setting but without success, I couldn't get the editor to render this... I'll try to simplify the setting to be a simple object with just (string) enum values
I have started on this, the setting is now just an but the settings editor still doesn't show it. What is missing?
I don't believe we currently support anyOf bool string, still. Are you expecting it to render as an enum like true, false, "on", "inline", "off"? Also, needs to be set to .
Cool. Thanks! That did make the difference here <img width="562" alt="Screenshot 2022-05-05 at 09 22 08" src="https://user-"
Change:
import { IChatEditorOptions } from 'vs/workbench/contrib/chat/browser/chatEditor'; import { ChatEditorInput } from 'vs/workbench/contrib/chat/browser/chatEditorInput'; import { ChatViewPane } from 'vs/workbench/contrib/chat/browser/chatViewPane'; <del> import { CONTEXT_IN_CHAT_INPUT, CONTEXT_IN_CHAT_SESSION, CONTEXT_PROVIDER_EXISTS } from 'vs/workbench/contrib/chat/common/chatContextKeys'; </del> <ins> import { CONTEXT_IN_CHAT_INPUT, CONTEXT_IN_CHAT_SESSION, CONTEXT_PROVIDER_EXISTS, CONTEXT_REQUEST, CONTEXT_RESPONSE } from 'vs/workbench/contrib/chat/common/chatContextKeys'; </ins> import { IChatDetail, IChatService } from 'vs/workbench/contrib/chat/common/chatService'; import { IChatWidgetHistoryService } from 'vs/workbench/contrib/chat/common/chatWidgetHistoryService'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService';

Discussion:
Refs: chat view. Ask some things keyboard focus on the request item (what you typed) -nothing happens This is inconsistent with the behaviour when the focus is on the response. Megan informed me that this behaviour is by design, but I do not see understand what is the benefit of this behaviour. What are we getting with this inconsistency?
cc and for feedback. The thought here was a user has typed the request - thus knows what it says generally and doesn't need to carefully inspect it. Also, the request is typically concise. Open to adding support for this though - we'd have to consider if we want the and to cycle through each list item. IMO, it would be a bit annoying to have to go through one's requests like this.
I discussed this with JooYoung and he agreed we should not do this unless it's requested
Change:
} async provideHistoryItemChanges(historyItemId: string): Promise<SourceControlHistoryItemChange[]> { <del> const [ref1, ref2] = historyItemId.includes('..') ? historyItemId.split('..') : [`${historyItemId}^`, historyItemId]; </del> <ins> // The "All Changes" history item uses a special id // which is a commit range instead of a single commit id let [originalRef, modifiedRef] = historyItemId.includes('..') ? historyItemId.split('..') : [undefined, historyItemId]; if (!originalRef) { const commit = await this.repository.getCommit(modifiedRef); originalRef = commit.parents.length > 0 ? commit.parents[0] : `${modifiedRef}^`; } </ins> const historyItemChangesUri: Uri[] = []; const historyItemChanges: SourceControlHistoryItemChange[] = []; <del> const changes = await this.repository.diffBetween(ref1, ref2); </del> <ins> const changes = await this.repository.diffBetween(originalRef, modifiedRef); </ins> for (const change of changes) { const historyItemUri = change.uri.with({

Discussion:
Testing Although technically correct, we should use the actual commit's short hash, not the syntax, for left side: !
Change:
this._modifiedWebview.dispose(); } <del> this._modifiedWebview = this.instantiationService.createInstance(BackLayerWebView, this, id, resource, this._notebookOptions.computeDiffWebviewOptions(), undefined) as BackLayerWebView<IDiffCellInfo>; </del> <ins> this._modifiedWebview = this.instantiationService.createInstance(BackLayerWebView, this, id, resource, { ...this._notebookOptions.computeDiffWebviewOptions(), fontFamily: this._generateFontFamily() }, undefined) as BackLayerWebView<IDiffCellInfo>; </ins> // attach the webview container to the DOM tree first this._list.rowsContainer.insertAdjacentElement('afterbegin', this._modifiedWebview.element); await this._modifiedWebview.createWebview(); this._modifiedWebview.element.style.width = `calc(50% - 16px)`; this._modifiedWebview.element.style.left = `calc(50%)`; } <ins> _generateFontFamily(): string { return this._fontInfo?.fontFamily ?? `"SF Mono", Monaco, Menlo, Consolas, "Ubuntu Mono", "Liberation Mono", "DejaVu Sans Mono", "Courier New", monospace`; } </ins> private async _createOriginalWebview(id: string, resource: URI): Promise<void> { if (this._originalWebview) { this._originalWebview.dispose(); } <del> this._originalWebview = this.instantiationService.createInstance(BackLayerWebView, this, id, resource, this._notebookOptions.computeDiffWebviewOptions(), undefined) as BackLayerWebView<IDiffCellInfo>; </del> <ins> this._originalWebview = this.instantiationService.createInstance(BackLayerWebView, this, id, resource, { ...this._notebookOptions.computeDiffWebviewOptions(), fontFamily: this._generateFontFamily() }, undefined) as BackLayerWebView<IDiffCellInfo>; </ins> // attach the webview container to the DOM tree first this._list.rowsContainer.insertAdjacentElement('afterbegin', this._originalWebview.element); await this._originalWebview.createWebview();

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: 1.65.0-insider (Universal) Commit: OS Version: Mac OS Monterey 12.2.1 Follow up issue to as this is a degradation in UX compared to the non-Insider version. Any input on that ? Current: ! Expected: Different columns should be aligned !
thank you for the bug report!
Change:
result.push(settingsGroup); } const configurationSettings: ISetting[] = []; <del> for (const setting of [...settingsGroup.sections[settingsGroup.sections.length - 1].settings, ...this.parseSettings(config.properties, config.extensionInfo)]) { </del> <ins> for (const setting of [...settingsGroup.sections[settingsGroup.sections.length - 1].settings, ...this.parseSettings(config)]) { </ins> if (!seenSettings[setting.key]) { configurationSettings.push(setting); seenSettings[setting.key] = true;

Discussion:
Tested on Insiders Build 1.65.0 and Build 1.64.2. If an extension's settings are viewed, the presentation order is respected, but _only if the "Search settings" bar is empty. If the search bar contains anything, including the name of the extension (matching all settings for that extension), the presentation order is alphabetical. Given that the presentation can still be controlled by the selected extension name in the left menu, it would seem logically possible to respect the sort ordering within an extension settings group. Examples: Following ordering (search area blank): ! Not following ordering: !
Verification steps: or write an extension with settings where the settings group and the individual settings use fields to determine the order. An example is at Also make the setting keys similar so that they can show up under the same search query. the extension, navigate to the Settings editor, and clear the search widget. that the settings for that extension are displayed in the expected order. a query to the search widget such that those extension settings still show up. that the filtered settings for that extension show up in the same order as in step 3.
Tested just now on LGTM
Change:
} export default class LinkProvider implements vscode.DocumentLinkProvider { <del> private readonly linkPattern = /([((![[^]]*?](s*)([^s()]+?)s*)]|[^]]*])(s*)(([^s()]|(S*?))+)s*(".*?")?)/g; private readonly referenceLinkPattern = /([([^]]+)][s*?)([^s]]*?)]/g; private readonly definitionPattern = /^([t ]*[([^]]+)]:s*)(S+)/gm; </del> <ins> private readonly linkPattern = /([((![[^]]*?](s*)([^s()]+?)s*)]|(?:]|[^]])*])(s*)(([^s()]|(S*?))+)s*(".*?")?)/g; private readonly referenceLinkPattern = /([((?:]|[^]])+)][s*?)([^s]]*?)]/g; private readonly definitionPattern = /^([t ]*[((?:]|[^]])+)]:s*)(S+)/gm; </ins> public provideDocumentLinks( document: vscode.TextDocument,

Discussion:
From In a markdown file: Does not detect as a link
Did you mean auto]save?
Added a merge request with some tweaks to the regex that is used to detect links. With the fix it should now correctly detect links with "]" in their names.
Change:
} filterMatches.sort((a, b) => { <del> // Sort by match type if the match types are not equal. // The priority of the match type is given by the SettingMatchType enum. // If they're equal, fall back to the "stable sort" counter score. </del> if (a.matchType !== b.matchType) { <ins> // Sort by match type if the match types are not the same. // The priority of the match type is given by the SettingMatchType enum. </ins> return b.matchType - a.matchType; } else { <ins> // The match types are the same. if (a.setting.extensionInfo && b.setting.extensionInfo && a.setting.extensionInfo.id === b.setting.extensionInfo.id) { // These settings belong to the same extension. if (a.setting.categoryLabel !== b.setting.categoryLabel && (a.setting.categoryOrder !== undefined || b.setting.categoryOrder !== undefined) && a.setting.categoryOrder !== b.setting.categoryOrder) { // These two settings don't belong to the same category and have different category orders. return this.compareTwoNullableNumbers(a.setting.categoryOrder, b.setting.categoryOrder); } else if (a.setting.categoryLabel === b.setting.categoryLabel && (a.setting.order !== undefined || b.setting.order !== undefined) && a.setting.order !== b.setting.order) { // These two settings belong to the same category, but have different orders. return this.compareTwoNullableNumbers(a.setting.order, b.setting.order); } } // In the worst case, go back to lexicographical order. </ins> return b.score - a.score; } });

Discussion:
Tested on Insiders Build 1.65.0 and Build 1.64.2. If an extension's settings are viewed, the presentation order is respected, but _only if the "Search settings" bar is empty. If the search bar contains anything, including the name of the extension (matching all settings for that extension), the presentation order is alphabetical. Given that the presentation can still be controlled by the selected extension name in the left menu, it would seem logically possible to respect the sort ordering within an extension settings group. Examples: Following ordering (search area blank): ! Not following ordering: !
Verification steps: or write an extension with settings where the settings group and the individual settings use fields to determine the order. An example is at Also make the setting keys similar so that they can show up under the same search query. the extension, navigate to the Settings editor, and clear the search widget. that the settings for that extension are displayed in the expected order. a query to the search widget such that those extension settings still show up. that the filtered settings for that extension show up in the same order as in step 3.
Tested just now on LGTM
Change:
this._button = dom.append(container, document.createElement('button')); this._button.classList.add('insert-button'); this._button.textContent = 'Insert'; <del> this._button.onclick = e => { </del> <ins> this._register(dom.addDisposableListener(this._button, dom.EventType.CLICK, () => { </ins> this._onClicked.fire(); <del> }; </del> <ins> })); </ins> } public get button(): HTMLElement {

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: 1.84.2 OS Version: Ubuntu 23.04 a text editor the command palette the command the color picker is visible, press to hide the color picker that two click event listeners have been , but not been removed:
Good catch, thanks a lot for the PR
Change:
return WinJS.Promise.join(promises); } <ins> public collapseDeepestExpandedLevel(): WinJS.Promise { var levelToCollapse = this.findDeepestExpandedLevel(this.input, 0); var items = [this.input]; for (var i = 0; i < levelToCollapse; i++) { items = arrays.flatten(items.map(node => node.getChildren())); } var promises = items.map(child => this.collapse(child, false)); return WinJS.Promise.join(promises); } private findDeepestExpandedLevel(item: Item, currentLevel: number): number { var expandedChildren = item.getChildren().filter(child => child.isExpanded()); if (!expandedChildren.length) { return currentLevel; } return Math.max(...expandedChildren.map(child => this.findDeepestExpandedLevel(child, currentLevel + 1))); } </ins> public toggleExpansion(element: any, recursive: boolean = false): WinJS.Promise { return this.isExpanded(element) ? this.collapse(element, recursive) : this.expand(element); }

Discussion:
One pattern I am seeing myself doing a lot is invoking the "Collapse" action on the search viewlet and now that I have multi root results, I see no results until I expand a root: ! Could we maybe collapse all but leave the roots expanded? Or, upon first collapse call we do that and upon the second we collapse also the roots?
hmmm...
This still annoys me a lot, especially if the results are only coming from one folder: !
Agreed, and there should be an external PR incoming for this. If not I'll fix it...
this behaves very nice now, thanks!
Change:
this.setYCoordinate(y ?? this.yDefault); } <del> private setYCoordinate(y = this.yCoordinate): void { </del> <ins> private setYCoordinate(y: number): void { </ins> const [yMin, yMax] = this.yRange; y = Math.max(yMin, Math.min(y, yMax)); this.$el.style.top = `${y}px`; <del> this.yCoordinate = y; </del> } private get yDefault() {

Discussion:
a breakpoint or log here or copy a file into a new floating window between them a few times. The event fires a couple times but then stops firing
does it reproduce without having devtools opened in any of the windows?
this one takes me by surprise: in the main process I keep track of auxiliary windows and so far I have been using as identifier, assuming it would always match . But as it turns out, that is actually not always the case: if I open devtools and restart or reload, I see how suddenly of does not match the of anymore. In other words, I see an id of for example for the of the floating window, while its has an of . So I do think that I am doing something wrong and I need a different way how to figure out the window ID of a floating window... I track the creation of floating windows here from the :
Ah, that's the repro. Yes, you must have devtools open when you open the aux window. Opening them after the aux window is already open doesn't cause an issue, but once you do open them then the event won't fire properly until vs code is restarted
That is not the intended contract in the runtime, a BrowserWindow can have multiple WebContents at any point and their ids are independent. WebContent ids are incremental within the same process, so it purely depends on the creation order. You can use to get the owner window and that should give you the right id.
I tried that, but at the time fires, returns . In other words, the web content is being created before the window is there... So essentially, I have no way to find the window for the web contents so early.
I think maintaining a would suit this scenario, you can access the webContents a BrowserWindow owns via and this will be valid even at . Should be reliable than id.
Yeah, an alternative would be to pro-long aux-window handshake between main and renderer until the is there but I think thats overkill. I will see to keep aux windows identified by . Its a bit inconsistent because both aux and main window share the same base class and the one will use and the other ...
<!-- 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:
e.preventDefault(); this.viewHelper.focusTextArea(); } <ins> }; if (shouldHandle && (targetIsContent || (targetIsLineNumbers && selectOnLineNumbers))) { focus(); </ins> this._mouseDownOperation.start(t.type, e); } else if (targetIsGutter) {

Discussion:
VSCode Version: Version 1.3.0-insider (1.3.0-insider) OS Version: OS X El Capitan 10.11.5 Steps to Reproduce: on the non-link area of a code lens line that nothing at all happens Would really like it to at a minimum to focus the editor (if not already focused), but we really love it if it move the cursor to the previous line. I find myself VERY often clicking on that area to start typing above it and nothing happens.
I'm assuming (maybe) that this wouldn't be a difficult change -- so if someone had the time to point me in the vague direction, I would be happy to attempt to open a PR for this. :)
PR welcome! :) It is in I would extract the code that does the focus: to a closure called inside the method. Then, at you can call and then : The reason focusing is complicated is because IE has some weirdness around redirecting focus when coming from the URL bar and doing a mouse down. And the already is a good indicator that the view zone does not want to handle mouse events.
Change:
icon: ThemeIcon; iconClasses: string[]; label: string; <ins> values: HelpItemValue[]; </ins> handleClick(): Promise<void>; }

Discussion:
Steps to Reproduce: remote explorer and view help links ( etc) under the viewlet for existing remote extensions. additional remote extensions and view the help link options again. Expected: links for the newer extensions show up in the lists. Actual: does not change. and reopening updates the list.
Change:
} override get capabilities(): EditorInputCapabilities { <del> return EditorInputCapabilities.Readonly | EditorInputCapabilities.Singleton; </del> <ins> return EditorInputCapabilities.Readonly | EditorInputCapabilities.Singleton | EditorInputCapabilities.CanDropIntoEditor; </ins> } setTerminalInstance(instance: ITerminalInstance): void {

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: 1.69.2 OS Version: MacOS BigSur and Monterey Steps to Reproduce: Open a terminal editor. a file from Finder into the terminal. This tries to open the file (unlike when the terminal is in the panel, which will paste the path).
I found that if I prevent the following code from executing, it works. So it seems like prevents the following code to handle pasting the file path. I did find that if you hold Shift before starting to drag the file, it will paste due to this code: I'm guessing there's some way to get that to realize it's a terminal editor and return as well.
I submitted PR for this.
File is still opened
did you hold shift? That's the method of passing the file through to the editor
works correctly with shift held