jiebi/CodeConvo huggingface dataset:
Code change:
Testing The should be a plain property and not a method
I was thinking about this guideline when I switched it to a method as it's creating a new object every call: Can switch it back, is it worth a discussion in the API sync?
I don't think it does create a new object but that's also not the point here. Your data is never sync with an async iterable but the point is the consumer should just have which is still an async iterable (and likely implemented as lazy getter)
I might be doing something wrong as I don't think I've used an async iterable before, but doesn't this need to return a separate iterable per call in order to support multiple extensions? Currently the is a multiplexer for multiple iterators:
Oh, I missed the invocation inside .
Maybe a better name for a method would be or .

Related discussion:
text: get cwd(): URI | undefined { return that.cwd; }, <del> createDataStream(): AsyncIterable<string> { </del> <ins> readData(): AsyncIterable<string> { </ins> return that._createDataStream(); } };
Code change:
Testing The should be a plain property and not a method
I was thinking about this guideline when I switched it to a method as it's creating a new object every call: Can switch it back, is it worth a discussion in the API sync?
I don't think it does create a new object but that's also not the point here. Your data is never sync with an async iterable but the point is the consumer should just have which is still an async iterable (and likely implemented as lazy getter)
I might be doing something wrong as I don't think I've used an async iterable before, but doesn't this need to return a separate iterable per call in order to support multiple extensions? Currently the is a multiplexer for multiple iterators:
Oh, I missed the invocation inside .
Maybe a better name for a method would be or .

Related discussion:
text: * @example * // Log all data written to the terminal for a command * const command = term.shellIntegration.executeCommand({ commandLine: 'echo "Hello world"' }); <del> * const stream = command.createDataStream(); </del> <ins> * const stream = command.readData(); </ins> * for await (const data of stream) { *   console.log(data); * } */ <del> createDataStream(): AsyncIterable<string>; </del> <ins> readData(): AsyncIterable<string>; </ins> } export interface Terminal {
Code change:
an extension with the following code: on the refactoring in the bulk edit pane opens the following multi diff editor: <img width="1093" alt="Screenshot 2024-03-27 at 17 23 56" src=""above is not correct because it looks like the file is . In fact it is deleted.

Related discussion:
text: // delete if (fileOperation.type & BulkFileOperationType.Delete) { return { <del> original: { resource: undefined }, modified: { resource: URI.revive(previewUri) } </del> <ins> original: { resource: URI.revive(previewUri) }, modified: { resource: undefined } </ins> }; }
Code change:
VS Code Version: Version: 1.87.2 OS Version: macOS 13.6.4 Steps to Reproduce: in the terminal happens in in , see that IWindowOptions is empty What should happen (works in iTerm2 and macOS Terminal): in the terminal should see a report printed to the screen The window size reporting functions are useful when connecting through tunnels that do not support TTY resize event forwarding. While many SSH and Telnet clients do support this, some tunnels do not (for example, a raw socket tunnel to a vt220-supporting application) and some programs may assume that the client supports this escape sequence. The information required to determine the terminal size in character is already available and is currently used to set the TTY's size. This function is fully implemented in , but not vscode. A small proof-of-concept where I use the debugger to enable this option appears to work as expected.

Related discussion:
text: overviewRulerWidth: 10, ignoreBracketedPasteMode: config.ignoreBracketedPasteMode, rescaleOverlappingGlyphs: config.rescaleOverlappingGlyphs, <ins> windowOptions: { getWinSizePixels: true, getCellSizePixels: true, getWinSizeChars: true, }, </ins> })); this._updateSmoothScrolling(); this._core = (this.raw as any)._core as IXtermCore;
Code change:
macOS, VS Code Insiders into explorer focus via keyboard hover does not show. There is no command to trigger the custom hover to show Like the activity bar, we have to make sure that the custom hover can be accessed in the tree/list only with the keyboard.
Would you suggest adding a keybinding to toggle the visibility of the custom hover of the html element which has focus?
Yeah, ideally it is . The same shortcut that we use in the editor for showing the hover. So it is consistent and easy for user to understand that there is one shortcut which does the right thing everywhere.
Isn't this a duplicate of ? Btw we seem to be having this support for extension provided trees at least:
I think it's good to have this one separate to .
Solving this for all trees/lists is pretty hard as the tree/list does not know anything about the underlying elements being rendered. For extension trees it is much easier as they all consist of a label which the creates and controls.
One option could be to utilize the to get the tooltip. Currently it already provides
After further discussions we came to the conclusion that we would use the DOM tree to figure out if there is any custom hovers available and trigger the hover by dispatching a mouse event on the HTMLElement. This might seem rather hacky but it ensures the consumers of the tree only have to support hover once and lets the tree handle keyboard triggers. Handling focus is still tricky and a open problem. Until this focus problem is properly fixed the treeview will keep it's own implementation which directly uses the hover service and moves the focus into the hover. The treeview implementation of this has it's own flaws but will b kept for the meantime to not cause regressions.

Related discussion:
text: hoverDelegate.onDidHideHover?.(); hoverWidget = undefined; } <ins> htmlElement.removeAttribute('custom-hover-active'); </ins> }; const triggerShowHover = (delay: number, focus?: boolean, target?: IHoverDelegateTarget) => {
Code change:
macOS, VS Code Insiders into explorer focus via keyboard hover does not show. There is no command to trigger the custom hover to show Like the activity bar, we have to make sure that the custom hover can be accessed in the tree/list only with the keyboard.
Would you suggest adding a keybinding to toggle the visibility of the custom hover of the html element which has focus?
Yeah, ideally it is . The same shortcut that we use in the editor for showing the hover. So it is consistent and easy for user to understand that there is one shortcut which does the right thing everywhere.
Isn't this a duplicate of ? Btw we seem to be having this support for extension provided trees at least:
I think it's good to have this one separate to .
Solving this for all trees/lists is pretty hard as the tree/list does not know anything about the underlying elements being rendered. For extension trees it is much easier as they all consist of a label which the creates and controls.
One option could be to utilize the to get the tooltip. Currently it already provides
After further discussions we came to the conclusion that we would use the DOM tree to figure out if there is any custom hovers available and trigger the hover by dispatching a mouse event on the HTMLElement. This might seem rather hacky but it ensures the consumers of the tree only have to support hover once and lets the tree handle keyboard triggers. Handling focus is still tricky and a open problem. Until this focus problem is properly fixed the treeview will keep it's own implementation which directly uses the hover service and moves the focus into the hover. The treeview implementation of this has it's own flaws but will b kept for the meantime to not cause regressions.

Related discussion:
text: if (!hoverWidget || hoverWidget.isDisposed) { hoverWidget = new UpdatableHoverWidget(hoverDelegate, target || htmlElement, delay > 0); await hoverWidget.update(typeof content === 'function' ? content() : content, focus, options); <ins> htmlElement.setAttribute('custom-hover-active', 'true'); </ins> } }, delay); };
Code change:
macOS, VS Code Insiders into explorer focus via keyboard hover does not show. There is no command to trigger the custom hover to show Like the activity bar, we have to make sure that the custom hover can be accessed in the tree/list only with the keyboard.
Would you suggest adding a keybinding to toggle the visibility of the custom hover of the html element which has focus?
Yeah, ideally it is . The same shortcut that we use in the editor for showing the hover. So it is consistent and easy for user to understand that there is one shortcut which does the right thing everywhere.
Isn't this a duplicate of ? Btw we seem to be having this support for extension provided trees at least:
I think it's good to have this one separate to .
Solving this for all trees/lists is pretty hard as the tree/list does not know anything about the underlying elements being rendered. For extension trees it is much easier as they all consist of a label which the creates and controls.
One option could be to utilize the to get the tooltip. Currently it already provides
After further discussions we came to the conclusion that we would use the DOM tree to figure out if there is any custom hovers available and trigger the hover by dispatching a mouse event on the HTMLElement. This might seem rather hacky but it ensures the consumers of the tree only have to support hover once and lets the tree handle keyboard triggers. Handling focus is still tricky and a open problem. Until this focus problem is properly fixed the treeview will keep it's own implementation which directly uses the hover service and moves the focus into the hover. The treeview implementation of this has it's own flaws but will b kept for the meantime to not cause regressions.

Related discussion:
text: this.handleAndRegisterCustomViewContainers(); this.handleAndRegisterCustomViews(); <ins> // Abstract tree has it's own implementation of triggering custom hover // TreeView uses it's own implementation due to setting focus inside the (markdown) </ins> let showTreeHoverCancellation = new CancellationTokenSource(); KeybindingsRegistry.registerCommandAndKeybindingRule({ id: 'workbench.action.showTreeHover',
Code change:
macOS, VS Code Insiders into explorer focus via keyboard hover does not show. There is no command to trigger the custom hover to show Like the activity bar, we have to make sure that the custom hover can be accessed in the tree/list only with the keyboard.
Would you suggest adding a keybinding to toggle the visibility of the custom hover of the html element which has focus?
Yeah, ideally it is . The same shortcut that we use in the editor for showing the hover. So it is consistent and easy for user to understand that there is one shortcut which does the right thing everywhere.
Isn't this a duplicate of ? Btw we seem to be having this support for extension provided trees at least:
I think it's good to have this one separate to .
Solving this for all trees/lists is pretty hard as the tree/list does not know anything about the underlying elements being rendered. For extension trees it is much easier as they all consist of a label which the creates and controls.
One option could be to utilize the to get the tooltip. Currently it already provides
After further discussions we came to the conclusion that we would use the DOM tree to figure out if there is any custom hovers available and trigger the hover by dispatching a mouse event on the HTMLElement. This might seem rather hacky but it ensures the consumers of the tree only have to support hover once and lets the tree handle keyboard triggers. Handling focus is still tricky and a open problem. Until this focus problem is properly fixed the treeview will keep it's own implementation which directly uses the hover service and moves the focus into the hover. The treeview implementation of this has it's own flaws but will b kept for the meantime to not cause regressions.

Related discussion:
text: } }, true); }, <del> weight: KeybindingWeight.WorkbenchContrib, </del> <ins> weight: KeybindingWeight.WorkbenchContrib + 1, </ins> primary: KeyChord(KeyMod.CtrlCmd | KeyCode.KeyK, KeyMod.CtrlCmd | KeyCode.KeyI), when: ContextKeyExpr.and(RawCustomTreeViewContextKey, WorkbenchListFocusContextKey) });
Code change:
macOS, VS Code Insiders into explorer focus via keyboard hover does not show. There is no command to trigger the custom hover to show Like the activity bar, we have to make sure that the custom hover can be accessed in the tree/list only with the keyboard.
Would you suggest adding a keybinding to toggle the visibility of the custom hover of the html element which has focus?
Yeah, ideally it is . The same shortcut that we use in the editor for showing the hover. So it is consistent and easy for user to understand that there is one shortcut which does the right thing everywhere.
Isn't this a duplicate of ? Btw we seem to be having this support for extension provided trees at least:
I think it's good to have this one separate to .
Solving this for all trees/lists is pretty hard as the tree/list does not know anything about the underlying elements being rendered. For extension trees it is much easier as they all consist of a label which the creates and controls.
One option could be to utilize the to get the tooltip. Currently it already provides
After further discussions we came to the conclusion that we would use the DOM tree to figure out if there is any custom hovers available and trigger the hover by dispatching a mouse event on the HTMLElement. This might seem rather hacky but it ensures the consumers of the tree only have to support hover once and lets the tree handle keyboard triggers. Handling focus is still tricky and a open problem. Until this focus problem is properly fixed the treeview will keep it's own implementation which directly uses the hover service and moves the focus into the hover. The treeview implementation of this has it's own flaws but will b kept for the meantime to not cause regressions.

Related discussion:
text: *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { KeyMod, KeyCode } from 'vs/base/common/keyCodes'; </del> <ins> import { KeyMod, KeyCode, KeyChord } from 'vs/base/common/keyCodes'; </ins> import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; import { KeybindingsRegistry, KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { List } from 'vs/base/browser/ui/list/listWidget';
Code change:
macOS, VS Code Insiders into explorer focus via keyboard hover does not show. There is no command to trigger the custom hover to show Like the activity bar, we have to make sure that the custom hover can be accessed in the tree/list only with the keyboard.
Would you suggest adding a keybinding to toggle the visibility of the custom hover of the html element which has focus?
Yeah, ideally it is . The same shortcut that we use in the editor for showing the hover. So it is consistent and easy for user to understand that there is one shortcut which does the right thing everywhere.
Isn't this a duplicate of ? Btw we seem to be having this support for extension provided trees at least:
I think it's good to have this one separate to .
Solving this for all trees/lists is pretty hard as the tree/list does not know anything about the underlying elements being rendered. For extension trees it is much easier as they all consist of a label which the creates and controls.
One option could be to utilize the to get the tooltip. Currently it already provides
After further discussions we came to the conclusion that we would use the DOM tree to figure out if there is any custom hovers available and trigger the hover by dispatching a mouse event on the HTMLElement. This might seem rather hacky but it ensures the consumers of the tree only have to support hover once and lets the tree handle keyboard triggers. Handling focus is still tricky and a open problem. Until this focus problem is properly fixed the treeview will keep it's own implementation which directly uses the hover service and moves the focus into the hover. The treeview implementation of this has it's own flaws but will b kept for the meantime to not cause regressions.

Related discussion:
text: import { CommandsRegistry } from 'vs/platform/commands/common/commands'; import { Table } from 'vs/base/browser/ui/table/tableWidget'; import { AbstractTree, TreeFindMatchType, TreeFindMode } from 'vs/base/browser/ui/tree/abstractTree'; <del> import { isActiveElement } from 'vs/base/browser/dom'; </del> <ins> import { EventType, getActiveWindow, isActiveElement } from 'vs/base/browser/dom'; </ins> import { Action2, registerAction2 } from 'vs/platform/actions/common/actions'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { localize, localize2 } from 'vs/nls'; <ins> import { IDisposable } from 'vs/base/common/lifecycle'; </ins> function ensureDOMFocus(widget: ListWidget | undefined): void { // it can happen that one of the commands is executed while
Code change:
macOS, VS Code Insiders into explorer focus via keyboard hover does not show. There is no command to trigger the custom hover to show Like the activity bar, we have to make sure that the custom hover can be accessed in the tree/list only with the keyboard.
Would you suggest adding a keybinding to toggle the visibility of the custom hover of the html element which has focus?
Yeah, ideally it is . The same shortcut that we use in the editor for showing the hover. So it is consistent and easy for user to understand that there is one shortcut which does the right thing everywhere.
Isn't this a duplicate of ? Btw we seem to be having this support for extension provided trees at least:
I think it's good to have this one separate to .
Solving this for all trees/lists is pretty hard as the tree/list does not know anything about the underlying elements being rendered. For extension trees it is much easier as they all consist of a label which the creates and controls.
One option could be to utilize the to get the tooltip. Currently it already provides
After further discussions we came to the conclusion that we would use the DOM tree to figure out if there is any custom hovers available and trigger the hover by dispatching a mouse event on the HTMLElement. This might seem rather hacky but it ensures the consumers of the tree only have to support hover once and lets the tree handle keyboard triggers. Handling focus is still tricky and a open problem. Until this focus problem is properly fixed the treeview will keep it's own implementation which directly uses the hover service and moves the focus into the hover. The treeview implementation of this has it's own flaws but will b kept for the meantime to not cause regressions.

Related discussion:
text: return; } <ins> if (activeHover) { toggleCustomHover(activeHover, widget); } </ins> await updateFocus(widget, updateFocusFn); const listFocus = widget.getFocus();
Code change:
<!-- 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.88.1 (Latest) + GitHub Codespaces OS Version: All? (Tested on Linux + MacOS) Steps to Reproduce: a folder or workspace (create if necessary): all the content from the above file and save it the command palette 'Tasks: Run Task' '+ Configure a Task' 'Open file' any provided task template notification error: "Unable to write to Folder Settings because no resource is provided." Expected behaviour: Empty is populated with the contents of the selected task template <img width="898" alt="Screenshot 2024-04-18 at 16 50 01" src=""

Related discussion:
text: return result[0].resource; }); } else if (fileExists && (tasksExistInFile || content)) { <del> if (content) { this._configurationService.updateValue('tasks', json.parse(content), target); </del> <ins> const statResource = stat?.resource; if (content && statResource) { this._configurationService.updateValue('tasks', json.parse(content), { resource: statResource }, target); </ins> } <del> return stat?.resource; </del> <ins> return statResource; </ins> } return undefined; }).then((resource) => {
Code change:
Under some circumstances, the Code Action button won't go away and will still run its assign command (incorrectly) Steps to Reproduce: an error with 'Quick Fix' available ! the cursor on the same line and press to bring up the quickfix ! to cancel ! the code action button ! the button again ! again ! ! at step 4. the button should disappear, but it does not I found this bug while adding Code Actions to my personal extension VS Code Version: 1.88.1 OS Version: Windows 11

Related discussion:
text: // Do not trigger state if current state is manual and incoming state is automatic if (!isManualToAutoTransition) { this.setState(newState); <ins> } else { // Reset the new state after getting code actions back. setTimeout(() => { this.setState(newState); }, 500); </ins> } }, undefined); this._codeActionOracle.value.trigger({ type: CodeActionTriggerType.Auto, triggerAction: CodeActionTriggerSource.Default });
Code change:
Testing "Note: Using this setting will disable Window: Auto Detect Color Scheme" should finish with a period.

Related discussion:
text: localize('window.systemColorTheme.light', "Enforce a light system color theme."), localize('window.systemColorTheme.dark', "Enforce a dark system color theme."), ], <del> markdownDescription: localize({ key: 'window.systemColorTheme', comment: ['{0} and {1} will become links to other settings.'] }, "Overrides the system color theme that is used for native UI elements such as native dialogs, menus and title bar. Even if your OS is configured in light appearance mode, you can select a dark system color theme for the window. You can also configure to automatically adjust based on the {0} setting. Note: Using this setting will disable {1}", formatSettingAsLink(ThemeSettings.COLOR_THEME), formatSettingAsLink(ThemeSettings.DETECT_COLOR_SCHEME)), </del> <ins> markdownDescription: localize({ key: 'window.systemColorTheme', comment: ['{0} and {1} will become links to other settings.'] }, "Overrides the system color theme that is used for native UI elements such as native dialogs, menus and title bar. Even if your OS is configured in light appearance mode, you can select a dark system color theme for the window. You can also configure to automatically adjust based on the {0} setting. Note: Using this setting will disable {1}.", formatSettingAsLink(ThemeSettings.COLOR_THEME), formatSettingAsLink(ThemeSettings.DETECT_COLOR_SCHEME)), </ins> default: 'default', included: ENABLE_SYSTEM_COLOR_SCHEME_SETTING, scope: ConfigurationScope.APPLICATION,