jiebi/CodeConvo huggingface dataset:
Change:
open editor inline chat press ESC nothing happens This is because unconditionally steals/overrides all commands from inline chat and likely others

Discussion:
constructor() { super( { <del> id: 'inlineChat.discard', </del> <ins> id: 'OFF.inlineChat.discard', </ins> title: localize('discard', 'Discard'), icon: Codicon.discard, menu: {
Change:
open editor inline chat press ESC nothing happens This is because unconditionally steals/overrides all commands from inline chat and likely others

Discussion:
constructor() { super( { <del> id: 'OFF.inlineChat.discard', </del> <ins> id: 'notebook.cell.chat.discard', </ins> title: localize('discard', 'Discard'), icon: Codicon.discard, menu: {
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. -- and I discovered that VSCode appears to automatically enable and when passing a string to githubnext/monaspace. <!-- 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: macOS 12.7.1 Steps to Reproduce: with an that supports ligatures Workarounds: Explicitly disable either ligature with or Screenshots of : <img width="1680" alt="empty" src=""<img width="1680" alt="'liga' on, 'calt' on" src=""<img width="1680" alt="'liga' off, 'calt' off" src=""
I'd appreciate a confirmation of whether this is a bug or intentional behavior, as it affects documentation for Monaspace.
Sorry for the delay, Nick. I noticed the following line and assigned Alex to this issue for further triaging.
I assume this is a bug then? And thanks, I did find that code, though I'm not sure why this is still happening:
Currently, is , we generate the CSS: is , we generate the CSS: is , we generate the CSS: is , we do not generate any CSS. The behavior of 4. then ends up being the default browser behavior.

Discussion:
return this.defaultValue; } if (typeof input === 'string') { <del> if (input === 'false') { </del> <ins> if (input === 'false' || input.length === 0) { </ins> return EditorFontLigatures.OFF; } if (input === 'true') {
Change:
As you can see, the positioning does not folding into account: ! This breaks the revert arrows in the diff editor, as I adopted glyph widgets for them.
We're deciding whether to render widgets based on and here but these are the viewport and not the model line numbers

Discussion:
for (const widget of Object.values(this._widgets)) { const range = widget.preference.range; <del> if (range.endLineNumber < visibleStartLineNumber || range.startLineNumber > visibleEndLineNumber) { </del> <ins> const { startLineNumber, endLineNumber } = this._context.viewModel.coordinatesConverter.convertModelRangeToViewRange(Range.lift(range)); if (!startLineNumber || !endLineNumber || endLineNumber < visibleStartLineNumber || startLineNumber > visibleEndLineNumber) { </ins> // The widget is not in the viewport continue; } // The widget is in the viewport, find a good line for it <del> const widgetLineNumber = Math.max(range.startLineNumber, visibleStartLineNumber); </del> <ins> const widgetLineNumber = Math.max(startLineNumber, visibleStartLineNumber); </ins> const lane = Math.min(widget.preference.lane, this._glyphMarginDecorationLaneCount); requests.push(new WidgetBasedGlyphRenderRequest(widgetLineNumber, lane, widget.preference.zIndex, widget)); }

return true; } <ins> public modelRangeIsVisible(modelRange: Range): boolean { const lineCount = this._lines.model.getLineCount(); if (modelRange.startLineNumber < 1 || modelRange.startLineNumber > lineCount) { // invalid arguments return false; } if (modelRange.endLineNumber < 1 || modelRange.endLineNumber > lineCount) { // invalid arguments return false; } return true; } </ins> public getModelLineViewLineCount(modelLineNumber: number): number { return 1; }
Change:
!
If this is in an aux window, then I don't think there's access to GitLens? Verified that I couldn't repro in a normal window.

Discussion:
import { Disposable, IDisposable, toDisposable } from 'vs/base/common/lifecycle'; import { ILayoutService } from 'vs/platform/layout/browser/layoutService'; import { IContextViewDelegate, IContextViewService } from './contextView'; <ins> import { getWindow } from 'vs/base/browser/dom'; </ins> export class ContextViewService extends Disposable implements IContextViewService {

showContextView(delegate: IContextViewDelegate, container?: HTMLElement, shadowRoot?: boolean): IDisposable { let domPosition: ContextViewDOMPosition; if (container) { <del> domPosition = shadowRoot ? ContextViewDOMPosition.FIXED_SHADOW : ContextViewDOMPosition.FIXED; </del> <ins> if (container === this.layoutService.getContainer(getWindow(container))) { domPosition = ContextViewDOMPosition.ABSOLUTE; } else if (shadowRoot) { domPosition = ContextViewDOMPosition.FIXED_SHADOW; } else { domPosition = ContextViewDOMPosition.FIXED; } </ins> } else { domPosition = ContextViewDOMPosition.ABSOLUTE; }
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/No 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: macOS Sonoma 14.1 M1/arm64 Steps to Reproduce: VSC with extensions disabled settings panel 'a' or 'ai' or 'smart ai' in search field hangs and throws below error Logs:

Discussion:
import { IAiRelatedInformationService, RelatedInformationType, SettingInformationResult } from 'vs/workbench/services/aiRelatedInformation/common/aiRelatedInformation'; import { TfIdfCalculator, TfIdfDocument } from 'vs/base/common/tfIdf'; import { IStringDictionary } from 'vs/base/common/collections'; <ins> import { nullRange } from 'vs/workbench/services/preferences/common/preferencesModels'; </ins> export interface IEndpointDetails { urlBase?: string;

} private toDescriptionRange(setting: ISetting, match: IMatch, lineIndex: number): IRange { <ins> const descriptionRange = setting.descriptionRanges[lineIndex]; if (!descriptionRange) { // This case occurs with added settings such as the // manage extension setting. return nullRange; } </ins> return { <del> startLineNumber: setting.descriptionRanges[lineIndex].startLineNumber, startColumn: setting.descriptionRanges[lineIndex].startColumn + match.start, endLineNumber: setting.descriptionRanges[lineIndex].endLineNumber, endColumn: setting.descriptionRanges[lineIndex].startColumn + match.end </del> <ins> startLineNumber: descriptionRange.startLineNumber, startColumn: descriptionRange.startColumn + match.start, endLineNumber: descriptionRange.endLineNumber, endColumn: descriptionRange.startColumn + match.end </ins> }; }
Change:
Type: <bBug</bTree sticky scroll is not showing properly in test explorer Looks like it doesn't have this background color property set to it which is there in Explorer but then I wonder if this is applicable to extensions contributed lists then wouldn't it break the UI for extension list after enabling the tree sticky scroll setting which don't have this property set. ! settings enabled. "": true, "testExplorer.useNativeTesting": true, ! VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-22T05:35:23.085Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ ng-template17.0.2 multi-cursor-case-preserve1.0.5 codeium1.4.20 codium0.7.17 svg-gallery2.1.0 console-log0.6.2 gitlens2023.11.2204 vscode-test-explorer2.21.1 angular2-switcher0.4.0 vscode-jest-test-adapter0.8.1 template-string-converter0.6.1 test-adapter-converter0.1.8 gitpatch0.2.1 material-icon-theme4.32.0 pretty-ts-errors0.5.2 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Testing tree is not providing it's background which it actually should. Created a temporary solution to ensure sticky scroll works in all trees. Currently working on a long term solution to ensure each tree will have the right background color

Discussion:
width: 100%; height: 0; z-index: 13; /* Settings editor uses z-index: 12 */ <ins> /* TODO@benibenj temporary solution, all lists should provide their background */ background-color: var(--vscode-sideBar-background); </ins> } .monaco-list .monaco-scrollable-element .monaco-tree-sticky-container .monaco-tree-sticky-row.monaco-list-row{

width: 100%; opacity: 1 !important; /* Settings editor uses opacity < 1 */ overflow: hidden; <ins> /* TODO@benibenj temporary solution, all lists should provide their background */ background-color: var(--vscode-sideBar-background); </ins> } .monaco-list .monaco-scrollable-element .monaco-tree-sticky-container .monaco-tree-sticky-row:hover{
Change:
See how layout controls are nice and large when zoomed in once: ! Now compare with editor actions. ! I think the issue is that some assumptions in the title bar are still being made based on layout controls showing or not but this should be more generalised to toolbar showing or not:

Discussion:
const noMenubar = this.currentMenubarVisibility === 'hidden' || (!isWeb && isMacintosh); const noCommandCenter = !this.isCommandCenterVisible; <del> const noLayoutControls = !this.layoutControlEnabled; </del> <ins> const noToolBarActions = !this.layoutControlEnabled && !this.editorActionsEnabled && !this.activityActionsEnabled; </ins> <del> return zoomFactor < 1 || (noMenubar && noCommandCenter && noLayoutControls); </del> <ins> return zoomFactor < 1 || (noMenubar && noCommandCenter && noToolBarActions); </ins> } override layout(width: number, height: number): void {
Change:
When the notebook diff editor is open, there's no action, but instead the is shown (which does nothing): ! Compare it to the regular diff editor: !

Discussion:
registerAction2(class extends Action2 { constructor() { super({ <ins> id: 'notebook.diff.openFile', icon: Codicon.goToFile, title: localize2('notebook.diff.openFile', 'Open File'), precondition: ContextKeyExpr.or(ActiveEditorContext.isEqualTo(NotebookTextDiffEditor.ID), ActiveEditorContext.isEqualTo(NotebookMultiTextDiffEditor.ID)), menu: [{ id: MenuId.EditorTitle, group: 'navigation', when: ContextKeyExpr.or(ActiveEditorContext.isEqualTo(NotebookTextDiffEditor.ID), ActiveEditorContext.isEqualTo(NotebookMultiTextDiffEditor.ID)), }] }); } async run(accessor: ServicesAccessor): Promise<void> { const editorService = accessor.get(IEditorService); const activeEditor = editorService.activeEditorPane; if (!activeEditor) { return; } if (activeEditor instanceof NotebookTextDiffEditor || activeEditor instanceof NotebookMultiTextDiffEditor) { const diffEditorInput = activeEditor.input as NotebookDiffEditorInput; const resource = diffEditorInput.modified.resource; await editorService.openEditor({ resource }); } } }); registerAction2(class extends Action2 { constructor() { super({ </ins> id: 'notebook.diff.switchToText', icon: openAsTextIcon, title: localize2('notebook.diff.switchToText', 'Open Text Diff Editor'),
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.84.1 OS Version: Windows 11 Steps to Reproduce: a hotkey mapped to pressing it until the last panel is displayed once more and it should wrap back around to the first panel of wrapping, it clamps to the last panel In previous versions of vscode (i.e. just a couple months ago) it wrapped around, and this was really useful.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.84.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I reloaded with 1.84.2 and the issue is still there.
Regressed here: Probably:
Thanks!
Yeah, thanks very much for this!

Discussion:
override async run(accessor: ServicesAccessor, offset: number): Promise<void> { const paneCompositeService = accessor.get(IPaneCompositePartService); <del> const pinnedPanels = paneCompositeService.getPinnedPaneCompositeIds(ViewContainerLocation.Panel); </del> <ins> const pinnedPanels = paneCompositeService.getVisiblePaneCompositeIds(ViewContainerLocation.Panel); </ins> const activePanel = paneCompositeService.getActivePaneComposite(ViewContainerLocation.Panel); if (!activePanel) { return;
Change:
a cell with the code the input field in the cell's output :bug: the cell output container will sometimes steal output from the input field !

Discussion:
readonly revealBehavior?: ScrollToRevealBehavior | undefined; readonly outputId?: string; readonly altOutputId?: string; <ins> readonly outputWebviewFocused?: boolean; </ins> } //#endregion

} const focusElementId = options?.outputId ?? cell.id; <del> this._webview.focusOutput(focusElementId, options?.altOutputId, this._webviewFocused); </del> <ins> this._webview.focusOutput(focusElementId, options?.altOutputId, options?.outputWebviewFocused || this._webviewFocused); </ins> cell.updateEditState(CellEditState.Preview, 'focusNotebookCell'); cell.focusMode = CellFocusMode.Output;

const latestCell = this.notebookEditor.getCellByInfo(resolvedResult.cellInfo); if (latestCell) { latestCell.outputIsFocused = true; <del> this.notebookEditor.focusNotebookCell(latestCell, 'output', { skipReveal: true }); </del> <ins> this.notebookEditor.focusNotebookCell(latestCell, 'output', { skipReveal: true, outputWebviewFocused: true }); </ins> } } break;
Change:
Version: 1.85.0-insider (user setup) Commit: Date: 2023-11-27T05:35:23.734Z Electron: 25.9.4 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0. At first I thought this was a bug in the C/C++ Extension's support for document/reference highlighting. I noticed that when I move my cursor to within in a variable, it would actually very quickly highlight the correct content in the document before immediately clearing the highlight. I managed to narrow down the repro to only occurring if the Output pane tab is selected and when there is output occurring to it as (after?) the highlight occurs. Perhaps something related to drawing content to the Output pane is inadvertently de-selecting the doc-highlight.

Discussion:
import { IContextKey, IContextKeyService, RawContextKey } from 'vs/platform/contextkey/common/contextkey'; import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; <del> import { Schemas } from 'vs/base/common/network'; </del> <ins> import { matchesScheme, Schemas } from 'vs/base/common/network'; </ins> import { ResourceMap } from 'vs/base/common/map'; import { score } from 'vs/editor/common/languageSelector'; import { isEqual } from 'vs/base/common/resources';

} })); this.toUnhook.add(editor.onDidChangeModelContent((e) => { <del> this._stopAll(); </del> <ins> if (!matchesScheme(this.model.uri, 'output')) { this._stopAll(); } </ins> })); this.toUnhook.add(editor.onDidChangeModel((e) => { if (!e.newModelUrl && e.oldModelUrl) {
Change:
Testing I think I can only reproduce when the "problems" pane is in the SCM view. Note that there is no badge: ! I don't know what exactly triggered it to finally update: !
I can repro using the following steps: a folder/workspace that contains a git repository sure that you do not have any pending changes the problems view into the Source Control view container a change to a file, and save the file No badge is being shown the Problems view out of the Source Control view container Badge appears any idea what is going on here?

Discussion:
private updateBadge(): void { const { errors, warnings, infos } = this.markerService.getStatistics(); const total = errors + warnings + infos; <del> const message = localize('totalProblems', 'Total {0} Problems', total); this.activity.value = this.activityService.showViewActivity(Markers.MARKERS_VIEW_ID, { badge: new NumberBadge(total, () => message) }); </del> <ins> if (total > 0) { const message = localize('totalProblems', 'Total {0} Problems', total); this.activity.value = this.activityService.showViewActivity(Markers.MARKERS_VIEW_ID, { badge: new NumberBadge(total, () => message) }); } else { this.activity.value = undefined; } </ins> } }
Change:
Testing a specific commit, not a branch, to go to a detached state Notice the SCM button still lets you (among others). None of the "sync" actions make sense in detached state. One can only commit. And an idea for a default button when there are no changes: . <img width="506" alt="image" src=""
Created to track the action button.

Discussion:
}; } <ins> // Not a branch (tag, detached) if (this.state.HEAD?.type === RefType.Tag || !this.state.HEAD?.name) { return { command: 'git.commit', title: l10n.t('{0} Commit', '$(check)'), tooltip: this.state.isCommitInProgress ? l10n.t('Committing Changes...') : l10n.t('Commit Changes'), arguments: [this.repository.sourceControl, ''] }; } </ins> // Commit return this.postCommitCommandCenter.getPrimaryCommand(); }

return []; } <ins> // Not a branch (tag, detached) if (this.state.HEAD?.type === RefType.Tag || !this.state.HEAD?.name) { return []; } </ins> // Commit const commandGroups: Command[][] = []; for (const commands of this.postCommitCommandCenter.getSecondaryCommands()) {
Change:
keyboard focus to SCM generate commit message button the nice blue outline being rendered hover over the button. The outline is no longer visible
Is the button enabled or disabled? I am asking as from what I can tell the pattern is that for enabled buttons the focus outline is not persisted when the button is hovered over. Disabled buttons persist the focus outline as they do not have a hover.
Reopening as I implemented the wrong fix.
The button is enabled. I noticed that in the Find Widget for example the focus outline is persisted on hover. Which imho is the natural thing to do.
With the PR linked above, the behaviour will be consistent with the rest of the actions. We can start a separate conversation whether we want to update all actions to keep the focus border on hover.

Discussion:
.scm-view .scm-input .scm-editor .scm-editor-toolbar.disabled .action-item { cursor: default; <del> opacity: 0.6; } .scm-view .scm-input .scm-editor .scm-editor-toolbar.disabled .action-label:hover { outline: unset; outline-offset: unset; background-color: unset; </del> } <ins> .scm-view .scm-input .scm-editor .scm-editor-toolbar.disabled .action-label:hover, </ins> .scm-view .scm-input .scm-editor .scm-editor-toolbar.disabled .action-item.monaco-dropdown-with-primary:hover { background-color: unset; }
Change:
keyboard focus to SCM generate commit message button the nice blue outline being rendered hover over the button. The outline is no longer visible
Is the button enabled or disabled? I am asking as from what I can tell the pattern is that for enabled buttons the focus outline is not persisted when the button is hovered over. Disabled buttons persist the focus outline as they do not have a hover.
Reopening as I implemented the wrong fix.
The button is enabled. I noticed that in the Find Widget for example the focus outline is persisted on hover. Which imho is the natural thing to do.
With the PR linked above, the behaviour will be consistent with the rest of the actions. We can start a separate conversation whether we want to update all actions to keep the focus border on hover.

Discussion:
display: none; } <del> .scm-view .scm-input .scm-editor .scm-editor-toolbar.disabled .action-item { cursor: default; } .scm-view .scm-input .scm-editor .scm-editor-toolbar.disabled .action-label:hover, .scm-view .scm-input .scm-editor .scm-editor-toolbar.disabled .action-item.monaco-dropdown-with-primary:hover { background-color: unset; } </del> .scm-view .scm-input .scm-editor .scm-editor-toolbar.scroll-decoration { box-shadow: var(--vscode-scrollbar-shadow) 0 6px 6px -6px inset; }

primaryAction = actions.find(a => a.id === lastActionId) ?? actions[0]; } <ins> if (primaryAction && primaryAction.id !== SCMInputCommandId.CancelAction && contextKeyService.getContextKeyValue(SCMInputContextKeys.ActionIsEnabled.key) === false) { primaryAction.enabled = false; } </ins> this._ctxActionCount.set(actions.length); this._dropdownActions = actions.length === 1 ? [] : actions; container.classList.toggle('has-no-actions', actions.length === 0); <del> container.classList.toggle('disabled', contextKeyService.getContextKeyValue(SCMInputContextKeys.ActionIsEnabled.key) !== true); </del> super.setActions(primaryAction ? [primaryAction] : [], []); };
Change:
Testing In the setting definition all minimum/maximum in order to get input validation in the settings editor. <img width="896" alt="image" src=""
Good catch. Will set a min value. Don't think a max value is needed though.

Discussion:
}, [treeStickyScrollMaxElements]: { type: 'number', <ins> minimum: 1, </ins> default: 5, markdownDescription: localize('sticky scroll maximum items', "Controls the number of sticky elements displayed in the tree when `#workbench.tree.enableStickyScroll#` is enabled."), },