Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

import { Connection, TextDocuments, InitializeParams, InitializeResult, NotificationType, RequestType, <del> DocumentRangeFormattingRequest, Disposable, ServerCapabilities, TextDocumentSyncKind, TextEdit, DocumentFormattingRequest, TextDocumentIdentifier, FormattingOptions, Diagnostic </del> <ins> DocumentRangeFormattingRequest, Disposable, ServerCapabilities, TextDocumentSyncKind, TextEdit, DocumentFormattingRequest, TextDocumentIdentifier, FormattingOptions, Diagnostic, CodeAction, CodeActionKind </ins> } from 'vscode-languageserver'; import { runSafe, runSafeAsync } from './utils/runner';


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

import { TextDocument, JSONDocument, JSONSchema, getLanguageService, DocumentLanguageSettings, SchemaConfiguration, ClientCapabilities, Range, Position, SortOptions } from 'vscode-json-languageservice'; import { getLanguageModelCache } from './languageModelCache'; import { Utils, URI } from 'vscode-uri'; <ins> import * as l10n from '@vscode/l10n'; </ins> type ISchemaAssociations = Record<string, string[]>;


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

documentSelector: null, interFileDependencies: false, workspaceDiagnostics: false <del> } </del> <ins> }, codeActionProvider: true </ins> }; return { capabilities };


Question:
Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!

}, [], `Error while computing document symbols for ${documentSymbolParams.textDocument.uri}`, token); }); <ins> connection.onCodeAction((codeActionParams, token) => { return runSafeAsync(runtime, async () => { const document = documents.get(codeActionParams.textDocument.uri); if (document) { const sortCodeAction = CodeAction.create('Sort JSON', CodeActionKind.Source.concat('.sort', '.json')); sortCodeAction.command = { command: 'json.sort', title: l10n.t('Sort JSON') }; return [sortCodeAction]; } return []; }, [], `Error while computing code actions for ${codeActionParams.textDocument.uri}`, token); }); </ins> function onFormat(textDocument: TextDocumentIdentifier, range: Range | undefined, options: FormattingOptions): TextEdit[] { options.keepLines = keepLinesEnabled;


Question:
Type: <bBug</bI am developing a VS code debugger extension by inheriting from DebugSession class. I implement disassembleRequest method to support disassembly view. But now there is a strange bug which I am not sure whether it is the bug of VS code or not. When disassembly view is firstly open, it shows wrong addresses and instructions. But after I scroll mouse up and down to manually refresh disassembly view, it shows correct addresses and instructions. So it seems it is a refresh issue. I have inspected the returned data to VS code and I am sure data is correct. BTW, if the returned data deos not contain source information, then the address and data is correct. I also post a question in stackoverflow: The question contains two picutures which should be able to describe my issue. Thanks! VS Code version: Code 1.82.0 (, 2023-09-06T22:07:07.438Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (9)</summaryExtensionVersion ------ biosdbgv44.1.2 vscode-eslint2.4.2 workspace-storage-cleanup1.1.5 isort2023.10.1 python2023.16.0 vscode-pylance2023.9.10 cpptools1.17.5 hexeditor1.9.12 memory-viewer0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Could you try this in the latest VS Code Insiders build? A bunch of disassembly view fixes just went in
I test on the latest VS code insiders 1.83.0, and the issue still exists. Please see below pictures When disassembly view is firstly open: ! After scroll mouse up and down to refresh disassembly view: !
Can you please either share your extension/a reproduction, or share a log of the DAP messages sent and received by your debugger?
Hi Connor, I have sent disassembly message to your email Thanks! Bill Zhang
Hi Connor, below is the implementation of disassembleRequest: protected async disassembleRequest(response: DebugProtocol.DisassembleResponse, args: DebugProtocol.DisassembleArguments) { try { const baseAddress = args.memoryReference; const offset = 0; const instructionOffset = args.instructionOffset 0; const instructionCount = args.instructionCount; const input = { baseAddress: baseAddress, offset: offset, instructionOffset: instructionOffset, instructionCount: instructionCount }; const instructionList: BIOSDBGInstruction[] = []; const output = await callRpcMethod("Disassemble", input); for (const item of output) { const addressHex = '0x' + item.address; const instruction = new BIOSDBGInstruction(addressHex, item.instruction, item.instructionBytes); if (item.sourcePath !== "" && item.lineNumber 0) { instruction.location = this.createSource(item.sourcePath); = item.lineNumber; } (instruction); } = { instructions: instructionList }; } finally { this.sendResponse(response); } }
Yep, got it, thanks. My plate is full right now but I'll look into this within the next couple weeks.
<!-- 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!
Tested with 1.84.0-insiders, it seems that this issue is fixed. Thanks!

const startN = binarySearch2(da.length, i => Number(da.row(i).address - firstAddr)); const start = startN < 0 ? ~startN : startN; const endN = binarySearch2(da.length, i => Number(da.row(i).address - lastAddr)); <del> const end = endN < 0 ? ~endN : endN; </del> <ins> const end = endN < 0 ? ~endN : endN + 1; </ins> const toDelete = end - start; // Go through everything we're about to add, and only show the source


Question:
Type: <bBug</bI am developing a VS code debugger extension by inheriting from DebugSession class. I implement disassembleRequest method to support disassembly view. But now there is a strange bug which I am not sure whether it is the bug of VS code or not. When disassembly view is firstly open, it shows wrong addresses and instructions. But after I scroll mouse up and down to manually refresh disassembly view, it shows correct addresses and instructions. So it seems it is a refresh issue. I have inspected the returned data to VS code and I am sure data is correct. BTW, if the returned data deos not contain source information, then the address and data is correct. I also post a question in stackoverflow: The question contains two picutures which should be able to describe my issue. Thanks! VS Code version: Code 1.82.0 (, 2023-09-06T22:07:07.438Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (9)</summaryExtensionVersion ------ biosdbgv44.1.2 vscode-eslint2.4.2 workspace-storage-cleanup1.1.5 isort2023.10.1 python2023.16.0 vscode-pylance2023.9.10 cpptools1.17.5 hexeditor1.9.12 memory-viewer0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Could you try this in the latest VS Code Insiders build? A bunch of disassembly view fixes just went in
I test on the latest VS code insiders 1.83.0, and the issue still exists. Please see below pictures When disassembly view is firstly open: ! After scroll mouse up and down to refresh disassembly view: !
Can you please either share your extension/a reproduction, or share a log of the DAP messages sent and received by your debugger?
Hi Connor, I have sent disassembly message to your email Thanks! Bill Zhang
Hi Connor, below is the implementation of disassembleRequest: protected async disassembleRequest(response: DebugProtocol.DisassembleResponse, args: DebugProtocol.DisassembleArguments) { try { const baseAddress = args.memoryReference; const offset = 0; const instructionOffset = args.instructionOffset 0; const instructionCount = args.instructionCount; const input = { baseAddress: baseAddress, offset: offset, instructionOffset: instructionOffset, instructionCount: instructionCount }; const instructionList: BIOSDBGInstruction[] = []; const output = await callRpcMethod("Disassemble", input); for (const item of output) { const addressHex = '0x' + item.address; const instruction = new BIOSDBGInstruction(addressHex, item.instruction, item.instructionBytes); if (item.sourcePath !== "" && item.lineNumber 0) { instruction.location = this.createSource(item.sourcePath); = item.lineNumber; } (instruction); } = { instructions: instructionList }; } finally { this.sendResponse(response); } }
Yep, got it, thanks. My plate is full right now but I'll look into this within the next couple weeks.
<!-- 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!
Tested with 1.84.0-insiders, it seems that this issue is fixed. Thanks!

let textModel: ITextModel | undefined = undefined; const sourceSB = new StringBuilder(10000); const ref = await this.textModelService.createModelReference(sourceURI); <ins> if (templateData.currentElement.element !== element) { return; // avoid a race, #192831 } </ins> textModel = ref.object.textEditorModel; templateData.cellDisposable.push(ref);


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

rename(title?: string): Promise<void>; /** <del> * Triggers a quick pick to change the icon of this terminal. </del> <ins> * Sets or triggers a quick pick to change the icon of this terminal. </ins> */ <del> changeIcon(): Promise<void>; </del> <ins> changeIcon(icon?: TerminalIcon): Promise<TerminalIcon | undefined>; </ins> /** <del> * Triggers a quick pick to change the color of the associated terminal tab icon. </del> <ins> * Sets or triggers a quick pick to change the color of the associated terminal tab icon. </ins> */ <del> changeColor(): Promise<void>; </del> <ins> changeColor(color?: string): Promise<string | undefined>; </ins> /** * Triggers a quick pick that displays recent commands or cwds. Selecting one will


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

import { INotificationService, Severity } from 'vs/platform/notification/common/notification'; import { IOpenerService } from 'vs/platform/opener/common/opener'; import { IPickOptions, IQuickInputService, IQuickPickItem } from 'vs/platform/quickinput/common/quickInput'; <del> import { ITerminalProfile, TerminalExitReason, TerminalLocation, TerminalSettingId } from 'vs/platform/terminal/common/terminal'; </del> <ins> import { ITerminalProfile, TerminalExitReason, TerminalIcon, TerminalLocation, TerminalSettingId } from 'vs/platform/terminal/common/terminal'; </ins> import { IWorkspaceContextService, IWorkspaceFolder } from 'vs/platform/workspace/common/workspace'; import { PICK_WORKSPACE_FOLDER_COMMAND_ID } from 'vs/workbench/browser/actions/workspaceCommands'; import { CLOSE_EDITOR_COMMAND_ID } from 'vs/workbench/browser/parts/editor/editorCommands';


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

title: terminalStrings.changeIcon, f1: false, precondition: ContextKeyExpr.and(ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated), TerminalContextKeys.tabsSingularSelection), <del> run: (c, accessor) => getSelectedInstances(accessor)?.[0].changeIcon() </del> <ins> run: async (c, accessor) => { let icon: TerminalIcon | undefined; for (const terminal of getSelectedInstances(accessor) ?? []) { icon = await terminal.changeIcon(icon); } } </ins> }); registerTerminalAction({


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

title: terminalStrings.changeColor, f1: false, precondition: ContextKeyExpr.and(ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated), TerminalContextKeys.tabsSingularSelection), <del> run: (c, accessor) => getSelectedInstances(accessor)?.[0].changeColor() </del> <ins> run: async (c, accessor) => { let color: string | undefined; for (const terminal of getSelectedInstances(accessor) ?? []) { color = await terminal.changeColor(color); } } </ins> }); registerTerminalAction({


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

run: (c, accessor) => accessor.get(ICommandService).executeCommand(CLOSE_EDITOR_COMMAND_ID) }); <del> registerContextualInstanceAction({ </del> <ins> registerTerminalAction({ </ins> id: TerminalCommandId.KillActiveTab, title: terminalStrings.kill, f1: false,


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

weight: KeybindingWeight.WorkbenchContrib, when: TerminalContextKeys.tabsFocus }, <del> run: (instance, c) => c.service.safeDisposeTerminal(instance), runAfter: (instances, c) => c.groupService.focusTabs() </del> <ins> run: async (c, accessor) => { for (const terminal of getSelectedInstances(accessor) ?? []) { c.service.safeDisposeTerminal(terminal); } c.groupService.focusTabs(); } </ins> }); registerTerminalAction({


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

} } <del> async changeIcon() { </del> <ins> async changeIcon(icon?: TerminalIcon): Promise<TerminalIcon | undefined> { if (icon) { this._icon = icon; this._onIconChanged.fire({ instance: this, userInitiated: true }); return icon; } </ins> type Item = IQuickPickItem & { icon: TerminalIcon }; const items: Item[] = []; for (const icon of getAllCodicons()) {


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

if (result) { this._icon = result.icon; this._onIconChanged.fire({ instance: this, userInitiated: true }); <ins> return this._icon; </ins> } <ins> return; </ins> } <del> async changeColor() { </del> <ins> async changeColor(color?: string): Promise<string | undefined> { if (color) { this.shellLaunchConfig.color = color; this._onIconChanged.fire({ instance: this, userInitiated: true }); return color; } </ins> const icon = this._getIcon(); if (!icon) { return;


Question:
Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.

quickPick.hide(); colorStyleDisposable.dispose(); <ins> return result?.id; </ins> } selectPreviousSuggestion(): void {


Question:
Testing ! Option + Down/Up arrow in terminal is not navigating between commands. These are working only in accessibility view. In terminal the keybindings are cmd + Down/Up arrow.
I'm experiencing the same issue testing on Windows 11.
This text should say in the accessible view - the keybinding is meant to work there, not in the terminal.
same issue! All the other commands work fine, arrows/screen reader work fine in the quick pick after command is run. I am wondering though if the keybinding for prev/next commands might be too generic?
Everyone, the prev/next commands must be run in the terminal's accessible view - not the terminal. Can you pls test that? I plan to make that clear by tweaking the dialog's text.
Yes, it worked in the terminal accessible view for me (as it sounds like it did for too).
Worked fine for me too! Sorry for the mixup
Thanks definitely see why you were confused though, so will fix that
to verify, open the accessibility help dialog by focusing a terminal and using . verify that the specify that they're to be applied in the terminal accessible view.

const keys = ['audioCues.diffLineDeleted', 'audioCues.diffLineInserted', 'audioCues.diffLineModified']; const content = [ localize('msg1', "You are in a diff editor."), <del> localize('msg2', "View the next {0} or previous {1} diff in diff review mode that is optimized for screen readers.", next, previous), </del> <ins> localize('msg2', "View the next ({0}) or previous ({1}) diff in diff review mode that is optimized for screen readers.", next, previous), </ins> localize('msg3', "To control which audio cues should be played, the following settings can be configured: {0}.", keys.join(', ')), ]; const commentCommandInfo = getCommentCommandInfo(keybindingService, contextKeyService, codeEditor);


Question:
Testing ! Option + Down/Up arrow in terminal is not navigating between commands. These are working only in accessibility view. In terminal the keybindings are cmd + Down/Up arrow.
I'm experiencing the same issue testing on Windows 11.
This text should say in the accessible view - the keybinding is meant to work there, not in the terminal.
same issue! All the other commands work fine, arrows/screen reader work fine in the quick pick after command is run. I am wondering though if the keybinding for prev/next commands might be too generic?
Everyone, the prev/next commands must be run in the terminal's accessible view - not the terminal. Can you pls test that? I plan to make that clear by tweaking the dialog's text.
Yes, it worked in the terminal accessible view for me (as it sounds like it did for too).
Worked fine for me too! Sorry for the mixup
Thanks definitely see why you were confused though, so will fix that
to verify, open the accessibility help dialog by focusing a terminal and using . verify that the specify that they're to be applied in the terminal accessible view.

import { killTerminalIcon, newTerminalIcon } from 'vs/workbench/contrib/terminal/browser/terminalIcons'; import { IEditorGroupsService } from 'vs/workbench/services/editor/common/editorGroupsService'; import { Iterable } from 'vs/base/common/iterator'; <del> import { AccessibleViewProviderId, accessibleViewCurrentProviderId, accessibleViewOnLastLine } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; </del> <ins> import { AccessibleViewProviderId, accessibleViewCurrentProviderId, accessibleViewIsShown, accessibleViewOnLastLine } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; </ins> export const switchTerminalActionViewItemSeparator = 'u2500u2500u2500u2500u2500u2500u2500u2500u2500'; export const switchTerminalShowTabsTitle = localize('showTerminalTabs', "Show Tabs");


Question:
Testing ! Option + Down/Up arrow in terminal is not navigating between commands. These are working only in accessibility view. In terminal the keybindings are cmd + Down/Up arrow.
I'm experiencing the same issue testing on Windows 11.
This text should say in the accessible view - the keybinding is meant to work there, not in the terminal.
same issue! All the other commands work fine, arrows/screen reader work fine in the quick pick after command is run. I am wondering though if the keybinding for prev/next commands might be too generic?
Everyone, the prev/next commands must be run in the terminal's accessible view - not the terminal. Can you pls test that? I plan to make that clear by tweaking the dialog's text.
Yes, it worked in the terminal accessible view for me (as it sounds like it did for too).
Worked fine for me too! Sorry for the mixup
Thanks definitely see why you were confused though, so will fix that
to verify, open the accessibility help dialog by focusing a terminal and using . verify that the specify that they're to be applied in the terminal accessible view.

keybinding: [ { primary: KeyMod.CtrlCmd | KeyCode.KeyR, <del> when: ContextKeyExpr.and(TerminalContextKeys.focus, CONTEXT_ACCESSIBILITY_MODE_ENABLED), </del> <ins> when: ContextKeyExpr.and(CONTEXT_ACCESSIBILITY_MODE_ENABLED, ContextKeyExpr.or(TerminalContextKeys.focus, ContextKeyExpr.and(accessibleViewIsShown, accessibleViewCurrentProviderId.isEqualTo(AccessibleViewProviderId.Terminal)))), </ins> weight: KeybindingWeight.WorkbenchContrib }, {


Question:
Testing ! Option + Down/Up arrow in terminal is not navigating between commands. These are working only in accessibility view. In terminal the keybindings are cmd + Down/Up arrow.
I'm experiencing the same issue testing on Windows 11.
This text should say in the accessible view - the keybinding is meant to work there, not in the terminal.
same issue! All the other commands work fine, arrows/screen reader work fine in the quick pick after command is run. I am wondering though if the keybinding for prev/next commands might be too generic?
Everyone, the prev/next commands must be run in the terminal's accessible view - not the terminal. Can you pls test that? I plan to make that clear by tweaking the dialog's text.
Yes, it worked in the terminal accessible view for me (as it sounds like it did for too).
Worked fine for me too! Sorry for the mixup
Thanks definitely see why you were confused though, so will fix that
to verify, open the accessibility help dialog by focusing a terminal and using . verify that the specify that they're to be applied in the terminal accessible view.

if (this._hasShellIntegration) { const shellIntegrationCommandList = []; shellIntegrationCommandList.push(localize('shellIntegration', "The terminal has a feature called shell integration that offers an enhanced experience and provides useful commands for screen readers such as:")); <del> shellIntegrationCommandList.push('- ' + this._descriptionForCommand(TerminalCommandId.AccessibleBufferGoToNextCommand, localize('goToNextCommand', 'Go to Next Command ({0})'), localize('goToNextCommandNoKb', 'Go to Next Command is currently not triggerable by a keybinding.'))); shellIntegrationCommandList.push('- ' + this._descriptionForCommand(TerminalCommandId.AccessibleBufferGoToPreviousCommand, localize('goToPreviousCommand', 'Go to Previous Command ({0})'), localize('goToPreviousCommandNoKb', 'Go to Previous Command is currently not triggerable by a keybinding.'))); </del> <ins> shellIntegrationCommandList.push('- ' + this._descriptionForCommand(TerminalCommandId.AccessibleBufferGoToNextCommand, localize('goToNextCommand', 'Go to Next Command ({0}) in the accessible view'), localize('goToNextCommandNoKb', 'Go to Next Command in the accessible view is currently not triggerable by a keybinding.'))); shellIntegrationCommandList.push('- ' + this._descriptionForCommand(TerminalCommandId.AccessibleBufferGoToPreviousCommand, localize('goToPreviousCommand', 'Go to Previous Command ({0}) in the accessible view'), localize('goToPreviousCommandNoKb', 'Go to Previous Command in the accessible view is currently not triggerable by a keybinding.'))); </ins> shellIntegrationCommandList.push('- ' + this._descriptionForCommand(AccessibilityCommandId.GoToSymbol, localize('goToSymbol', 'Go to Symbol ({0})'), localize('goToSymbolNoKb', 'Go to symbol is currently not triggerable by a keybinding.'))); shellIntegrationCommandList.push('- ' + this._descriptionForCommand(TerminalCommandId.RunRecentCommand, localize('runRecentCommand', 'Run Recent Command ({0})'), localize('runRecentCommandNoKb', 'Run Recent Command is currently not triggerable by a keybinding.'))); shellIntegrationCommandList.push('- ' + this._descriptionForCommand(TerminalCommandId.GoToRecentDirectory, localize('goToRecentDirectory', 'Go to Recent Directory ({0})'), localize('goToRecentDirectoryNoKb', 'Go to Recent Directory is currently not triggerable by a keybinding.')));


Question:
Testing Start from , on a repo: The git extension will associate as the most likely candidate for 's base. But since does have an upstream, , which, at the point was created, was pointing to the same commit as itself... wouldn't be a better base candidate instead?
I think that this makes sense to me however would you favour the remote branch (origin/foo) just because it points to the same commit as when was created or should it be a general rule that if a remote is present, we would favour it?
Will mark this and look out for additional feedback.
Though more about this and since we are adding and actions to the incoming node, it does make sense for it to be an upstream branch. Marking the issue as "bug" so that it gets verified during endgame.

async getBranchBase(ref: string): Promise<Branch | undefined> { const branch = await this.getBranch(ref); <del> const branchMergeBaseConfigKey = `branch.${branch.name}.vscode-merge-base`; </del> <ins> const branchUpstream = await this.getUpstreamBranch(branch); </ins> <del> // Upstream if (branch.upstream) { return await this.getBranch(`refs/remotes/${branch.upstream.remote}/${branch.upstream.name}`); </del> <ins> if (branchUpstream) { return branchUpstream; </ins> } // Git config <ins> const mergeBaseConfigKey = `branch.${branch.name}.vscode-merge-base`; </ins> try { <del> const mergeBase = await this.getConfig(branchMergeBaseConfigKey); if (mergeBase !== '') { const mergeBaseBranch = await this.getBranch(mergeBase); return mergeBaseBranch; </del> <ins> const mergeBase = await this.getConfig(mergeBaseConfigKey); const branchFromConfig = mergeBase !== '' ? await this.getBranch(mergeBase) : undefined; if (branchFromConfig) { return branchFromConfig; </ins> } } catch (err) { } // Reflog const branchFromReflog = await this.getBranchBaseFromReflog(ref); <del> if (branchFromReflog) { await this.setConfig(branchMergeBaseConfigKey, branchFromReflog.name!); return branchFromReflog; </del> <ins> const branchFromReflogUpstream = branchFromReflog ? await this.getUpstreamBranch(branchFromReflog) : undefined; if (branchFromReflogUpstream) { await this.setConfig(mergeBaseConfigKey, `${branchFromReflogUpstream.remote}/${branchFromReflogUpstream.name}`); return branchFromReflogUpstream; </ins> } // Default branch const defaultBranch = await this.getDefaultBranch(); if (defaultBranch) { <del> await this.setConfig(branchMergeBaseConfigKey, defaultBranch.name!); </del> <ins> await this.setConfig(mergeBaseConfigKey, `${defaultBranch.remote}/${defaultBranch.name}`); </ins> return defaultBranch; }


Question:
Testing Start from , on a repo: The git extension will associate as the most likely candidate for 's base. But since does have an upstream, , which, at the point was created, was pointing to the same commit as itself... wouldn't be a better base candidate instead?
I think that this makes sense to me however would you favour the remote branch (origin/foo) just because it points to the same commit as when was created or should it be a general rule that if a remote is present, we would favour it?
Will mark this and look out for additional feedback.
Though more about this and since we are adding and actions to the incoming node, it does make sense for it to be an upstream branch. Marking the issue as "bug" so that it gets verified during endgame.

return undefined; } <ins> private async getUpstreamBranch(branch: Branch): Promise<Branch | undefined> { if (!branch.upstream) { return undefined; } try { const upstreamBranch = await this.getBranch(`refs/remotes/${branch.upstream.remote}/${branch.upstream.name}`); return upstreamBranch; } catch (err) { this.logger.warn(`Failed to get branch details for 'refs/remotes/${branch.upstream.remote}/${branch.upstream.name}': ${err.message}.`); return undefined; } } </ins> async getRefs(query: RefQuery = {}, cancellationToken?: CancellationToken): Promise<Ref[]> { const config = workspace.getConfiguration('git'); let defaultSort = config.get<'alphabetically' | 'committerdate'>('branchSortOrder');


Question:
Testing Testing on Windows 11. opens terminal accessibility help dialog correctly: ! Explore options, decide I want to try Run Recent Command () to open terminal accessible view, opens correctly: ! Try I don't observe anything happen - but maybe I'm misunderstanding what should happen or how I should set this command up?
Sorry this was not clear. Perhaps I should specify which commands only apply when focus is in the terminal? Perhaps that should also work when the focus is in the accessible view... I will think about that.
To verify, focus a terminal in screen reader mode. open the terminal accessibility help dialog with and check which keybinding to use for . open the terminal accessible view by focusing the terminal and using use that key binding. make sure it runs whichever command you select.
I think I'm still missing something in my understanding. Steps I took: Open VS Code repo in latest VS Code Insiders Toggle screen reader mode so that I'm Screen Reader Optimized Open and focus terminal , the terminal accessibility help dialog opens I note that will run recent command, and will get me to previous commands Open terminal accessible view by focusing terminal and using to get to a previous command (this worked well) Once I've gotten to a previous command I'd like to run, I try but again don't observe anything happened: !
Apologies, Brigit, it appears there's an old bug resurfacing in which the keybinding is not listed correctly in this dialog. On windows, run recent command is invoked with when in screen reader mode. On mac, with screen reader mode, it's .
Reopening to fix that
Ah yay, worked well for me, thank you! I'll hold off on labeling as if you'd also like to use this issue to track fixing the keybinding bug.
Actually, I think I'll reopen that other issue. Since the issue was the command not working, it would be great if you'd verify this and I'll link the other . Thanks
here's the issue where we're tracking that


Question:
Testing Testing on Windows 11. opens terminal accessibility help dialog correctly: ! Explore options, decide I want to try Run Recent Command () to open terminal accessible view, opens correctly: ! Try I don't observe anything happen - but maybe I'm misunderstanding what should happen or how I should set this command up?
Sorry this was not clear. Perhaps I should specify which commands only apply when focus is in the terminal? Perhaps that should also work when the focus is in the accessible view... I will think about that.
To verify, focus a terminal in screen reader mode. open the terminal accessibility help dialog with and check which keybinding to use for . open the terminal accessible view by focusing the terminal and using use that key binding. make sure it runs whichever command you select.
I think I'm still missing something in my understanding. Steps I took: Open VS Code repo in latest VS Code Insiders Toggle screen reader mode so that I'm Screen Reader Optimized Open and focus terminal , the terminal accessibility help dialog opens I note that will run recent command, and will get me to previous commands Open terminal accessible view by focusing terminal and using to get to a previous command (this worked well) Once I've gotten to a previous command I'd like to run, I try but again don't observe anything happened: !
Apologies, Brigit, it appears there's an old bug resurfacing in which the keybinding is not listed correctly in this dialog. On windows, run recent command is invoked with when in screen reader mode. On mac, with screen reader mode, it's .
Reopening to fix that
Ah yay, worked well for me, thank you! I'll hold off on labeling as if you'd also like to use this issue to track fixing the keybinding bug.
Actually, I think I'll reopen that other issue. Since the issue was the command not working, it would be great if you'd verify this and I'll link the other . Thanks
here's the issue where we're tracking that


Question:
Testing Testing on Windows 11. opens terminal accessibility help dialog correctly: ! Explore options, decide I want to try Run Recent Command () to open terminal accessible view, opens correctly: ! Try I don't observe anything happen - but maybe I'm misunderstanding what should happen or how I should set this command up?
Sorry this was not clear. Perhaps I should specify which commands only apply when focus is in the terminal? Perhaps that should also work when the focus is in the accessible view... I will think about that.
To verify, focus a terminal in screen reader mode. open the terminal accessibility help dialog with and check which keybinding to use for . open the terminal accessible view by focusing the terminal and using use that key binding. make sure it runs whichever command you select.
I think I'm still missing something in my understanding. Steps I took: Open VS Code repo in latest VS Code Insiders Toggle screen reader mode so that I'm Screen Reader Optimized Open and focus terminal , the terminal accessibility help dialog opens I note that will run recent command, and will get me to previous commands Open terminal accessible view by focusing terminal and using to get to a previous command (this worked well) Once I've gotten to a previous command I'd like to run, I try but again don't observe anything happened: !
Apologies, Brigit, it appears there's an old bug resurfacing in which the keybinding is not listed correctly in this dialog. On windows, run recent command is invoked with when in screen reader mode. On mac, with screen reader mode, it's .
Reopening to fix that
Ah yay, worked well for me, thank you! I'll hold off on labeling as if you'd also like to use this issue to track fixing the keybinding bug.
Actually, I think I'll reopen that other issue. Since the issue was the command not working, it would be great if you'd verify this and I'll link the other . Thanks
here's the issue where we're tracking that


Question:
Testing Testing on Windows 11. opens terminal accessibility help dialog correctly: ! Explore options, decide I want to try Run Recent Command () to open terminal accessible view, opens correctly: ! Try I don't observe anything happen - but maybe I'm misunderstanding what should happen or how I should set this command up?
Sorry this was not clear. Perhaps I should specify which commands only apply when focus is in the terminal? Perhaps that should also work when the focus is in the accessible view... I will think about that.
To verify, focus a terminal in screen reader mode. open the terminal accessibility help dialog with and check which keybinding to use for . open the terminal accessible view by focusing the terminal and using use that key binding. make sure it runs whichever command you select.
I think I'm still missing something in my understanding. Steps I took: Open VS Code repo in latest VS Code Insiders Toggle screen reader mode so that I'm Screen Reader Optimized Open and focus terminal , the terminal accessibility help dialog opens I note that will run recent command, and will get me to previous commands Open terminal accessible view by focusing terminal and using to get to a previous command (this worked well) Once I've gotten to a previous command I'd like to run, I try but again don't observe anything happened: !
Apologies, Brigit, it appears there's an old bug resurfacing in which the keybinding is not listed correctly in this dialog. On windows, run recent command is invoked with when in screen reader mode. On mac, with screen reader mode, it's .
Reopening to fix that
Ah yay, worked well for me, thank you! I'll hold off on labeling as if you'd also like to use this issue to track fixing the keybinding bug.
Actually, I think I'll reopen that other issue. Since the issue was the command not working, it would be great if you'd verify this and I'll link the other . Thanks
here's the issue where we're tracking that


Question:
When there are multiple debug sessions, the dropdown action item shows in the debug toolbar here as a button that doesn't do anything. You can see it in the gif in We could just hide that item when this setting is set
I believe it focuses the Call Stack view but only when paused and when having the view active. Tho, I do agree that we shouldn't have it there to begin with.

@IKeybindingService private _keybindingService: IKeybindingService, @IInstantiationService private _instaService: IInstantiationService, ) { <del> super(undefined, _submenu.actions[0], options); </del> <ins> super(undefined, _submenu.actions.find(action => action.id === 'workbench.action.quickOpenWithModes') ?? _submenu.actions[0], options); </ins> } override render(container: HTMLElement): void {


Question:
When there are multiple debug sessions, the dropdown action item shows in the debug toolbar here as a button that doesn't do anything. You can see it in the gif in We could just hide that item when this setting is set
I believe it focuses the Call Stack view but only when paused and when having the view active. Tho, I do agree that we shouldn't have it there to begin with.

}); <ins> const CONTEXT_TOOLBAR_COMMAND_CENTER = ContextKeyExpr.equals('config.debug.toolBarLocation', 'commandCenter'); </ins> MenuRegistry.appendMenuItem(MenuId.CommandCenterCenter, { submenu: MenuId.DebugToolBar, title: 'Debug', icon: Codicon.debug, order: 1, <del> when: ContextKeyExpr.and(CONTEXT_IN_DEBUG_MODE, ContextKeyExpr.equals('config.debug.toolBarLocation', 'commandCenter')) </del> <ins> when: ContextKeyExpr.and(CONTEXT_IN_DEBUG_MODE, CONTEXT_TOOLBAR_COMMAND_CENTER) </ins> }); registerDebugToolBarItem(CONTINUE_ID, CONTINUE_LABEL, 10, icons.debugContinue, CONTEXT_DEBUG_STATE.isEqualTo('stopped'));


Question:
When there are multiple debug sessions, the dropdown action item shows in the debug toolbar here as a button that doesn't do anything. You can see it in the gif in We could just hide that item when this setting is set
I believe it focuses the Call Stack view but only when paused and when having the view active. Tho, I do agree that we shouldn't have it there to begin with.

registerDebugToolBarItem(RESTART_SESSION_ID, RESTART_LABEL, 60, icons.debugRestart); registerDebugToolBarItem(STEP_BACK_ID, localize('stepBackDebug', "Step Back"), 50, icons.debugStepBack, CONTEXT_STEP_BACK_SUPPORTED, CONTEXT_DEBUG_STATE.isEqualTo('stopped')); registerDebugToolBarItem(REVERSE_CONTINUE_ID, localize('reverseContinue', "Reverse"), 55, icons.debugReverseContinue, CONTEXT_STEP_BACK_SUPPORTED, CONTEXT_DEBUG_STATE.isEqualTo('stopped')); <del> registerDebugToolBarItem(FOCUS_SESSION_ID, FOCUS_SESSION_LABEL, 100, Codicon.listTree, CONTEXT_MULTI_SESSION_DEBUG); </del> <ins> registerDebugToolBarItem(FOCUS_SESSION_ID, FOCUS_SESSION_LABEL, 100, Codicon.listTree, ContextKeyExpr.and(CONTEXT_MULTI_SESSION_DEBUG, CONTEXT_TOOLBAR_COMMAND_CENTER.negate())); </ins> MenuRegistry.appendMenuItem(MenuId.DebugToolBarStop, { group: 'navigation',


Question:
Type: <bBug</bclone repro from and open project folder run the repro extension from vscode open two folders in the workspace (these will not be touched by the repro code, the problem was encounterd in multi-folder workspace and this just reproduces that environment) run command after some time popup with error will appear Expected beahvior: the loop running the dummy task will keep running indefinitely This seems to be caused by using in combination with changes of the workspace folders. When the loop in the repro is changed to only keep writing the file and running the tasks the problem never appears VS Code version: Code - Insiders 1.82.0-insider (, 2023-09-01T11:05:38.381Z) OS version: Linux x64 4.19.0-18-amd64 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (0)</summaryExtensionVersion ------ </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I'm not seeing the task you said to run in that folder !
The repro steps say to run command , not a task. The command runs the task itself via the API. Here is the command in the command pallette ! And here is the error it produces ! Please try the repro steps again and let me know if you still can't see what I show in the screenshots
I get this error, which is interesting because the workspace contains two folders. !
From the screenshot it seems like you have one workspace folder containing two file system folders - that still means the workspace is a single root workspace You need to have a multi-root workspace by calling I hope the terminology I use is correct, it is taken from this doc
PR fixing it

} public async $OnDidEndTask(execution: tasks.ITaskExecutionDTO): Promise<void> { <ins> if (!this._taskExecutionPromises.has(execution.id)) { // Event already fired by the main thread // See https://github.com/microsoft/vscode/commit/aaf73920aeae171096d205efb2c58804a32b6846 return; } </ins> const _execution = await this.getTaskExecution(execution); this._taskExecutionPromises.delete(execution.id); this._taskExecutions.delete(execution.id);


Question:
Type: <bBug</bclone repro from and open project folder run the repro extension from vscode open two folders in the workspace (these will not be touched by the repro code, the problem was encounterd in multi-folder workspace and this just reproduces that environment) run command after some time popup with error will appear Expected beahvior: the loop running the dummy task will keep running indefinitely This seems to be caused by using in combination with changes of the workspace folders. When the loop in the repro is changed to only keep writing the file and running the tasks the problem never appears VS Code version: Code - Insiders 1.82.0-insider (, 2023-09-01T11:05:38.381Z) OS version: Linux x64 4.19.0-18-amd64 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (0)</summaryExtensionVersion ------ </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I'm not seeing the task you said to run in that folder !
The repro steps say to run command , not a task. The command runs the task itself via the API. Here is the command in the command pallette ! And here is the error it produces ! Please try the repro steps again and let me know if you still can't see what I show in the screenshots
I get this error, which is interesting because the workspace contains two folders. !
From the screenshot it seems like you have one workspace folder containing two file system folders - that still means the workspace is a single root workspace You need to have a multi-root workspace by calling I hope the terminology I use is correct, it is taken from this doc
PR fixing it

if (result) { return result; } <del> const createdResult: Promise<TaskExecutionImpl> = new Promise((resolve, reject) => { function resolvePromiseWithCreatedTask(that: ExtHostTaskBase, execution: tasks.ITaskExecutionDTO, taskToCreate: vscode.Task | types.Task | undefined) { if (!taskToCreate) { reject('Unexpected: Task does not exist.'); } else { resolve(new TaskExecutionImpl(that, execution.id, taskToCreate)); } } if (task) { resolvePromiseWithCreatedTask(this, execution, task); } else { TaskDTO.to(execution.task, this._workspaceProvider, this._providedCustomExecutions2) .then(task => resolvePromiseWithCreatedTask(this, execution, task)); } }); this._taskExecutionPromises.set(execution.id, createdResult); return createdResult.then(executionCreatedResult => { this._taskExecutions.set(execution.id, executionCreatedResult); return executionCreatedResult; }, rejected => { return Promise.reject(rejected); </del> <ins> let executionPromise: Promise<TaskExecutionImpl>; if (!task) { executionPromise = TaskDTO.to(execution.task, this._workspaceProvider, this._providedCustomExecutions2).then(t => { if (!t) { throw new ErrorNoTelemetry('Unexpected: Task does not exist.'); } return new TaskExecutionImpl(this, execution.id, t); }); } else { executionPromise = Promise.resolve(new TaskExecutionImpl(this, execution.id, task)); } this._taskExecutionPromises.set(execution.id, executionPromise); return executionPromise.then(taskExecution => { this._taskExecutions.set(execution.id, taskExecution); return taskExecution; </ins> }); }


Question:
I have a setting in my settings. Everytime I reload, I see a setting being . This keeps on happening, the old setting is never removed. ! Not sure if this should be a candidate. does this code look right to you? Or does migration also need to remove the old setting?
If you want to remove the old setting you should explicitly mention that in the migration like below
Can the migration function be made in a way that people do not forget this?

key: 'workbench.editor.untitled.hint', migrateFn: (value, _accessor) => ([ [emptyTextEditorHintSetting, { value }], <ins> ['workbench.editor.untitled.hint', { value: undefined }] </ins> ]) }, { key: 'accessibility.verbosity.untitledHint', migrateFn: (value, _accessor) => ([ [AccessibilityVerbositySettingId.EmptyEditorHint, { value }], <ins> ['accessibility.verbosity.untitledHint', { value: undefined }] </ins> ]) }]);


Question: I'm pretty sure some of these keybindings aren't ever enabled with their context key requirements, e.g. I don't think the inline chat can be focused in a markdown cell that isn't in edit mode. Nor will cursor navigation mode be true while edit mode is false.

import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { Registry } from 'vs/platform/registry/common/platform'; import { InlineChatController } from 'vs/workbench/contrib/inlineChat/browser/inlineChatController'; <del> import { CTX_INLINE_CHAT_FOCUSED, CTX_INLINE_CHAT_INNER_CURSOR_LAST } from 'vs/workbench/contrib/inlineChat/common/inlineChat'; </del> import { INotebookActionContext, INotebookCellActionContext, NotebookAction, NotebookCellAction, NOTEBOOK_EDITOR_WIDGET_ACTION_WEIGHT, findTargetCellEditor } from 'vs/workbench/contrib/notebook/browser/controller/coreActions'; import { CellEditState } from 'vs/workbench/contrib/notebook/browser/notebookBrowser'; import { CellKind, NOTEBOOK_EDITOR_CURSOR_BOUNDARY } from 'vs/workbench/contrib/notebook/common/notebookCommon';


Question: I'm pretty sure some of these keybindings aren't ever enabled with their context key requirements, e.g. I don't think the inline chat can be focused in a markdown cell that isn't in edit mode. Nor will cursor navigation mode be true while edit mode is false.

weight: KeybindingWeight.WorkbenchContrib }, { <del> when: ContextKeyExpr.and( NOTEBOOK_EDITOR_FOCUSED, CONTEXT_ACCESSIBILITY_MODE_ENABLED.negate(), ContextKeyExpr.equals('config.notebook.navigation.allowNavigateToSurroundingCells', true), ContextKeyExpr.and( ContextKeyExpr.has(InputFocusedContextKey), NOTEBOOK_EDITOR_CURSOR_BOUNDARY.notEqualsTo('top'), NOTEBOOK_EDITOR_CURSOR_BOUNDARY.notEqualsTo('none'), ), CTX_INLINE_CHAT_FOCUSED, CTX_INLINE_CHAT_INNER_CURSOR_LAST, EditorContextKeys.isEmbeddedDiffEditor.negate() ), primary: KeyCode.DownArrow, weight: KeybindingWeight.EditorCore }, { when: ContextKeyExpr.and( NOTEBOOK_EDITOR_FOCUSED, CONTEXT_ACCESSIBILITY_MODE_ENABLED.negate(), ContextKeyExpr.equals('config.notebook.navigation.allowNavigateToSurroundingCells', true), ContextKeyExpr.and( NOTEBOOK_CELL_TYPE.isEqualTo('markup'), NOTEBOOK_CELL_MARKDOWN_EDIT_MODE.isEqualTo(false), NOTEBOOK_CURSOR_NAVIGATION_MODE), CTX_INLINE_CHAT_FOCUSED, CTX_INLINE_CHAT_INNER_CURSOR_LAST, EditorContextKeys.isEmbeddedDiffEditor.negate() ), primary: KeyCode.DownArrow, weight: KeybindingWeight.EditorCore }, { </del> when: NOTEBOOK_EDITOR_FOCUSED, primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.PageDown, mac: { primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.PageDown, },


Question: I'm pretty sure some of these keybindings aren't ever enabled with their context key requirements, e.g. I don't think the inline chat can be focused in a markdown cell that isn't in edit mode. Nor will cursor navigation mode be true while edit mode is false.

super({ id: NOTEBOOK_FOCUS_PREVIOUS_EDITOR, title: localize('cursorMoveUp', 'Focus Previous Cell Editor'), <del> precondition: CONTEXT_ACCESSIBILITY_MODE_ENABLED.negate(), </del> keybinding: [ { when: ContextKeyExpr.and(


Question:
Type: <bBug</bCC Copilot inline suggestion Accessible View (alt+F2) for the suggestion : this opens a side-by-side copilot suggestion panel instead of accepting the suggestion. I think we need to go back to the original keybindings: for accepting suggestion; for submitting a request. VS Code version: Code - Insiders 1.84.0-insider (, 2023-10-12T05:37:35.298Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (92)</summaryExtensionVersion ------ android-dev-ext1.3.2 aiprm-lang0.0.2 Bookmarks13.4.2 openscad1.2.2 spellright3.0.118 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.52.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.26.0 gitlens14.3.0 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.15.4 copilot1.126.0 copilot-chat0.9. remotehub0.62.0 vscode-github-actions0.26.2 vscode-pull-request-github0.74.0 overleaf-workshop0.3.0 cslpreview0.2.2 easy-snippet0.6.3 path-autocomplete1.25.0 latex-workshop9.14.1 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 vscode-bard0.0.10 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.1 black-formatter2023.4.1 flake82023.8.0 isort2023.11. python2023.18.0 vscode-pylance2023.10.20 jupyter2023.9. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.318.0 remote-ssh0.106.5 remote-ssh-edit0.86.0 remote-wsl0.81.8 vscode-remote-extensionpack0.24.0 azure-repos0.38.0 cmake-tools1.15.31 cpptools1.17.5 cpptools-extension-pack1.3.0 js-debug-nightly2023.10.1117 powershell2023.9.5 remote-repositories0.40.0 vscode-github-issue-notebooks0.0.130 vscode-selfhost-test-provider0.3.19 vscode-serial-monitor0.10.0 vsliveshare1.0.5883 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.5 shinyuieditor0.5.0 quarto1.103.0 r-debugger0.5.4 java1.23.0 vscode-xml0.26.1 r2.8.2 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.7.0 latex-utilities0.4.10 cmake0.0.17 errorlens3.14.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.54.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.14 vscode-java-test0.40.0 vscode-maven0.42.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Good catch. I couldn't test yesterday as inline completions weren't working for me. I think that we can just increase the weight of this keybinding rather than change it back.
That keybinding will still work when one is not in the accessible view. LMK if that sounds good to you.
-- We then reassign the default keybindings for the following: : This is currently . : This is currently .
We cannot change the extension contributed ones, so I was suggesting overriding it when in the accessible view. I cannot get inline completions to work in oss atm, so cannot test any of these changes until that works and am leaning toward just reverting the change.

id: AccessibilityCommandId.AccessibleViewAcceptInlineCompletion, precondition: ContextKeyExpr.and(accessibleViewIsShown, ContextKeyExpr.equals(accessibleViewCurrentProviderId.key, AccessibleViewProviderId.InlineCompletions)), keybinding: { <del> primary: KeyMod.CtrlCmd | KeyCode.Enter, mac: { primary: KeyMod.WinCtrl | KeyCode.Enter }, </del> <ins> primary: KeyMod.CtrlCmd | KeyCode.Slash, mac: { primary: KeyMod.WinCtrl | KeyCode.Slash }, </ins> weight: KeybindingWeight.WorkbenchContrib }, icon: Codicon.check,


Question: <!-- 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: 1.83.1 OS Version: 12.6.9 Steps to Reproduce: or the Python and Black Vscode extensions a new notebook and execute any cell or save it You'll a "Formatting with autopep8" message in the status bar even though that formatter extension isn't installed! However manually triggering "Format Cell" does use black.

return undefined; } <ins> export async function getDocumentFormattingEditsWithSelectedProvider( workerService: IEditorWorkerService, languageFeaturesService: ILanguageFeaturesService, editorOrModel: ITextModel | IActiveCodeEditor, mode: FormattingMode, token: CancellationToken, ): Promise<TextEdit[] | undefined> { const model = isCodeEditor(editorOrModel) ? editorOrModel.getModel() : editorOrModel; const provider = getRealAndSyntheticDocumentFormattersOrdered(languageFeaturesService.documentFormattingEditProvider, languageFeaturesService.documentRangeFormattingEditProvider, model); const selected = await FormattingConflicts.select(provider, model, mode, FormattingKind.File); if (selected) { const rawEdits = await Promise.resolve(selected.provideDocumentFormattingEdits(model, model.getOptions(), token)).catch(onUnexpectedExternalError); return await workerService.computeMoreMinimalEdits(model.uri, rawEdits); } return undefined; } </ins> export function getOnTypeFormattingEdits( workerService: IEditorWorkerService, languageFeaturesService: ILanguageFeaturesService,


Question: <!-- 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: 1.83.1 OS Version: 12.6.9 Steps to Reproduce: or the Python and Black Vscode extensions a new notebook and execute any cell or save it You'll a "Formatting with autopep8" message in the status bar even though that formatter extension isn't installed! However manually triggering "Format Cell" does use black.

import { IEditorWorkerService } from 'vs/editor/common/services/editorWorker'; import { ILanguageFeaturesService } from 'vs/editor/common/services/languageFeatures'; import { ITextModelService } from 'vs/editor/common/services/resolverService'; <del> import { FormattingMode, formatDocumentWithSelectedProvider, getDocumentFormattingEditsUntilResult } from 'vs/editor/contrib/format/browser/format'; </del> <ins> import { FormattingMode, formatDocumentWithSelectedProvider, getDocumentFormattingEditsWithSelectedProvider } from 'vs/editor/contrib/format/browser/format'; </ins> import { Action2, MenuId, registerAction2 } from 'vs/platform/actions/common/actions'; import { ContextKeyExpr } from 'vs/platform/contextkey/common/contextkey'; import { IInstantiationService, ServicesAccessor } from 'vs/platform/instantiation/common/instantiation';


Question: <!-- 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: 1.83.1 OS Version: 12.6.9 Steps to Reproduce: or the Python and Black Vscode extensions a new notebook and execute any cell or save it You'll a "Formatting with autopep8" message in the status bar even though that formatter extension isn't installed! However manually triggering "Format Cell" does use black.

const model = ref.object.textEditorModel; <del> const formatEdits = await getDocumentFormattingEditsUntilResult( </del> <ins> const formatEdits = await getDocumentFormattingEditsWithSelectedProvider( </ins> editorWorkerService, languageFeaturesService, model, <del> model.getOptions(), </del> <ins> FormattingMode.Explicit, </ins> CancellationToken.None );


Question: <!-- 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: 1.83.1 OS Version: 12.6.9 Steps to Reproduce: or the Python and Black Vscode extensions a new notebook and execute any cell or save it You'll a "Formatting with autopep8" message in the status bar even though that formatter extension isn't installed! However manually triggering "Format Cell" does use black.

const model = ref.object.textEditorModel; <del> // todo: eventually support cancellation. potential leak if cell deleted mid execution const formatEdits = await getDocumentFormattingEditsUntilResult( </del> <ins> const formatEdits = await getDocumentFormattingEditsWithSelectedProvider( </ins> this.editorWorkerService, this.languageFeaturesService, model, <del> model.getOptions(), </del> <ins> FormattingMode.Silent, </ins> CancellationToken.None );


Question: <!-- 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: 1.83.1 OS Version: 12.6.9 Steps to Reproduce: or the Python and Black Vscode extensions a new notebook and execute any cell or save it You'll a "Formatting with autopep8" message in the status bar even though that formatter extension isn't installed! However manually triggering "Format Cell" does use black.

import { ITextModelService } from 'vs/editor/common/services/resolverService'; import { ApplyCodeActionReason, applyCodeAction, getCodeActions } from 'vs/editor/contrib/codeAction/browser/codeAction'; import { CodeActionKind, CodeActionTriggerSource } from 'vs/editor/contrib/codeAction/common/types'; <del> import { getDocumentFormattingEditsUntilResult } from 'vs/editor/contrib/format/browser/format'; </del> <ins> import { FormattingMode, getDocumentFormattingEditsWithSelectedProvider } from 'vs/editor/contrib/format/browser/format'; </ins> import { SnippetController2 } from 'vs/editor/contrib/snippet/browser/snippetController2'; import { localize } from 'vs/nls'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration';


Question: <!-- 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: 1.83.1 OS Version: 12.6.9 Steps to Reproduce: or the Python and Black Vscode extensions a new notebook and execute any cell or save it You'll a "Formatting with autopep8" message in the status bar even though that formatter extension isn't installed! However manually triggering "Format Cell" does use black.

const model = ref.object.textEditorModel; <del> const formatEdits = await getDocumentFormattingEditsUntilResult( </del> <ins> const formatEdits = await getDocumentFormattingEditsWithSelectedProvider( </ins> this.editorWorkerService, this.languageFeaturesService, model, <del> model.getOptions(), </del> <ins> FormattingMode.Silent, </ins> token );


Question:
When using the new diff editor with enabled, I very rarely get to the right editor position whenever I click the top action, above the editor.
You mean go to reference is broken?
diff editors have an action to open the original file (I think contributed from SCM?). When clicking that, expectation is that the current view state of the diff editors right hand side applies to the opening editor so that you stay in exactly the same view state (for example: the selection and viewport). <img width="140" alt="image" src=""
I really like the collapsed diff editor but this is a very frustrating regression from it which makes me want to shut it off. The issue is 100% reproducible in my usual workflow and I encounter this issue many times per hour.
I can reproduce. The "Open File" command is a mystery to me. Debugging shows me that is called twice, but both times with unhelpful stack traces: ! ! The second invocation sets . However, there is no reveal mechanism.
Further investigation showed that the "Open File" action is actually implemented in the git extension (even when comparing two files on disk) :/ Which I think is very questionable design, as it should be a core diff editor feature.

const activeTextEditor = window.activeTextEditor; // Must extract these now because opening a new document will change the activeTextEditor reference <del> const previousVisibleRange = activeTextEditor?.visibleRanges[0]; </del> <ins> const previousVisibleRanges = activeTextEditor?.visibleRanges; </ins> const previousURI = activeTextEditor?.document.uri; const previousSelection = activeTextEditor?.selection;


Question:
When using the new diff editor with enabled, I very rarely get to the right editor position whenever I click the top action, above the editor.
You mean go to reference is broken?
diff editors have an action to open the original file (I think contributed from SCM?). When clicking that, expectation is that the current view state of the diff editors right hand side applies to the opening editor so that you stay in exactly the same view state (for example: the selection and viewport). <img width="140" alt="image" src=""
I really like the collapsed diff editor but this is a very frustrating regression from it which makes me want to shut it off. The issue is 100% reproducible in my usual workflow and I encounter this issue many times per hour.
I can reproduce. The "Open File" command is a mystery to me. Debugging shows me that is called twice, but both times with unhelpful stack traces: ! ! The second invocation sets . However, there is no reveal mechanism.
Further investigation showed that the "Open File" action is actually implemented in the git extension (even when comparing two files on disk) :/ Which I think is very questionable design, as it should be a core diff editor feature.

opts.selection = previousSelection; const editor = await window.showTextDocument(document, opts); // This should always be defined but just in case <del> if (previousVisibleRange) { editor.revealRange(previousVisibleRange); </del> <ins> if (previousVisibleRanges && previousVisibleRanges.length > 0) { let rangeToReveal = previousVisibleRanges[0]; if (previousSelection && previousVisibleRanges.length > 1) { // In case of multiple visible ranges, find the one that intersects with the selection rangeToReveal = previousVisibleRanges.find(r => r.intersection(previousSelection)) ?? rangeToReveal; } editor.revealRange(rangeToReveal); </ins> } } }


Question:
From We should fix block styling in Markdown previews in main as well, from discussing with we want to make the styling consistent across chat, settings UI, and extension webviews
The three greys look different to me. I'm unsure whether those are the colours I should be comparing. !
To verify this you just need to confirm that there is a background for blocks, since it used to just be a brownish foreground color.

<meta charset="UTF-8"> <meta http-equiv="Content-Security-Policy" <del> content="default-src 'none'; script-src 'sha256-QA1gXilHYAUFCvp7MpjgcmyBCFzSKV0SpiecMU8aUVc=' 'self'; frame-src 'self'; style-src 'unsafe-inline';"> </del> <ins> content="default-src 'none'; script-src 'sha256-Ne5nVg2ZDLxLh1eqzYd1sGbOz022xlokwv+X6+HR1hw=' 'self'; frame-src 'self'; style-src 'unsafe-inline';"> </ins> <!-- Disable pinch zooming --> <meta name="viewport"


Question:
From We should fix block styling in Markdown previews in main as well, from discussing with we want to make the styling consistent across chat, settings UI, and extension webviews
The three greys look different to me. I'm unsure whether those are the colours I should be comparing. !
To verify this you just need to confirm that there is a background for blocks, since it used to just be a brownish foreground color.

} code { <ins> font-family: var(--monaco-monospace-font); </ins> color: var(--vscode-textPreformat-foreground); <ins> font-size: 12px; background-color: var(--vscode-textPreformat-background); padding: 1px 3px; border-radius: 4px; </ins> } blockquote {


Question:
Type: <bBug</bWhat does this mean / do? ! VS Code version: Code 1.84.0 (, 2023-11-01T11:29:04.398Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
Apparently from by and present since 1.78.
this should only be showing up for the quick pick item hovers, not the actions which have a small amount of content.

) { } showHover(options: IHoverDelegateOptions, focus?: boolean): IHoverWidget | undefined { <ins> // Only show the hover hint if the content is of a decent size const showHoverHint = ( options.content instanceof HTMLElement ? options.content.textContent ?? '' : typeof options.content === 'string' ? options.content : options.content.value ).length > 20; </ins> return this.hoverService.showHover({ ...options, persistence: { hideOnKeyDown: false, }, appearance: { <del> showHoverHint: true, </del> <ins> showHoverHint, </ins> skipFadeInAnimation: true, }, }, focus);


Question:
<!-- 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. --<img src="" alt="drawing" width="600"/Currently, we can control when to show the inline suggestion toolbar by setting to "always" or "onHover", which are defined as follows: "always": show the inline suggestion toolbar whenever an inline suggestion is shown, and "onHover": show the inline suggestion toolbar when hovering over an inline suggestion. For the new feature, I suggest to add an option "never" as follows "never": do not show the inline suggestion toolbar.
I think this should be very easy to implement. Up for a PR?
I would like to take this.
Any ideas why this setting isn't in the Settings JSON file? .
Thank you so much for accepting the request and for the contribution!

*/ mode?: 'prefix' | 'subword' | 'subwordSmart'; <del> showToolbar?: 'always' | 'onHover'; </del> <ins> showToolbar?: 'always' | 'onHover' | 'never'; </ins> suppressSuggestions?: boolean;


Question:
<!-- 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. --<img src="" alt="drawing" width="600"/Currently, we can control when to show the inline suggestion toolbar by setting to "always" or "onHover", which are defined as follows: "always": show the inline suggestion toolbar whenever an inline suggestion is shown, and "onHover": show the inline suggestion toolbar when hovering over an inline suggestion. For the new feature, I suggest to add an option "never" as follows "never": do not show the inline suggestion toolbar.
I think this should be very easy to implement. Up for a PR?
I would like to take this.
Any ideas why this setting isn't in the Settings JSON file? .
Thank you so much for accepting the request and for the contribution!

'editor.inlineSuggest.showToolbar': { type: 'string', default: defaults.showToolbar, <del> enum: ['always', 'onHover'], </del> <ins> enum: ['always', 'onHover', 'never'], </ins> enumDescriptions: [ nls.localize('inlineSuggest.showToolbar.always', "Show the inline suggestion toolbar whenever an inline suggestion is shown."), nls.localize('inlineSuggest.showToolbar.onHover', "Show the inline suggestion toolbar when hovering over an inline suggestion."), <ins> nls.localize('inlineSuggest.showToolbar.never', "Never show the inline suggestion toolbar."), </ins> ], description: nls.localize('inlineSuggest.showToolbar', "Controls when to show the inline suggestion toolbar."), },


Question:
<!-- 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. --<img src="" alt="drawing" width="600"/Currently, we can control when to show the inline suggestion toolbar by setting to "always" or "onHover", which are defined as follows: "always": show the inline suggestion toolbar whenever an inline suggestion is shown, and "onHover": show the inline suggestion toolbar when hovering over an inline suggestion. For the new feature, I suggest to add an option "never" as follows "never": do not show the inline suggestion toolbar.
I think this should be very easy to implement. Up for a PR?
I would like to take this.
Any ideas why this setting isn't in the Settings JSON file? .
Thank you so much for accepting the request and for the contribution!

return { enabled: boolean(input.enabled, this.defaultValue.enabled), mode: stringSet(input.mode, this.defaultValue.mode, ['prefix', 'subword', 'subwordSmart']), <del> showToolbar: stringSet(input.showToolbar, this.defaultValue.showToolbar, ['always', 'onHover']), </del> <ins> showToolbar: stringSet(input.showToolbar, this.defaultValue.showToolbar, ['always', 'onHover', 'never']), </ins> suppressSuggestions: boolean(input.suppressSuggestions, this.defaultValue.suppressSuggestions), keepOnBlur: boolean(input.keepOnBlur, this.defaultValue.keepOnBlur), };


Question:
<!-- 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. --<img src="" alt="drawing" width="600"/Currently, we can control when to show the inline suggestion toolbar by setting to "always" or "onHover", which are defined as follows: "always": show the inline suggestion toolbar whenever an inline suggestion is shown, and "onHover": show the inline suggestion toolbar when hovering over an inline suggestion. For the new feature, I suggest to add an option "never" as follows "never": do not show the inline suggestion toolbar.
I think this should be very easy to implement. Up for a PR?
I would like to take this.
Any ideas why this setting isn't in the Settings JSON file? .
Thank you so much for accepting the request and for the contribution!

} computeSync(anchor: HoverAnchor, lineDecorations: IModelDecoration[]): InlineCompletionsHover[] { <del> if (this._editor.getOption(EditorOption.inlineSuggest).showToolbar === 'always') { </del> <ins> if (this._editor.getOption(EditorOption.inlineSuggest).showToolbar !== 'onHover') { </ins> return []; }


Question:
<!-- 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. --<img src="" alt="drawing" width="600"/Currently, we can control when to show the inline suggestion toolbar by setting to "always" or "onHover", which are defined as follows: "always": show the inline suggestion toolbar whenever an inline suggestion is shown, and "onHover": show the inline suggestion toolbar when hovering over an inline suggestion. For the new feature, I suggest to add an option "never" as follows "never": do not show the inline suggestion toolbar.
I think this should be very easy to implement. Up for a PR?
I would like to take this.
Any ideas why this setting isn't in the Settings JSON file? .
Thank you so much for accepting the request and for the contribution!

* Defaults to `prefix`. */ mode?: 'prefix' | 'subword' | 'subwordSmart'; <del> showToolbar?: 'always' | 'onHover'; </del> <ins> showToolbar?: 'always' | 'onHover' | 'never'; </ins> suppressSuggestions?: boolean; /** * Does not clear active inline suggestions when the editor loses focus.


Question:
<!-- 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. --extension is used to specify the syntax highlighting for popular languages, such as TypeScript: Currently, the workaround is to push the settings file to Git: In addition, extension is also . It would be nice if VSCode could support these aliases to YAML natively.
If you want to make a PR, that would be great!
I made a PR, I hope it's good, because I have no experience with the codebase:

".eyaml", ".eyml", ".yaml", <del> ".cff" </del> <ins> ".cff", ".yaml-tmlanguage", ".yaml-tmpreferences", ".yaml-tmtheme" </ins> ], "firstLine": "^#cloud-config", "configuration": "./language-configuration.json"


Question:
open test explorer notice that the input has the wrong background color, e.g it has two background colors <img width="455" alt="Screenshot 2023-11-15 at 14 29 05" src=""
What theme are you using? I can see the slight difference in your screenshot, but inspecting things I'm not seeing any backgrounds being applied to that action / menu bar
Like, any light theme?
Still confused on the latest Insiders for me in e.g. solarized light: <img width="725" alt="image" src=""Does it reproduce on a fresh user-data-dir for you? If so, are you able to do a quick devtools inspect and give a hint as to what styling is being applied that makes monaco input have a different background color?
I see. It doesn't show with an empty profile but I also don't have any setting that screams test explorer background color
Could you bisect your user settings or share them so I can play around?
This seems to be because I have the test explorer in the secondary sidebar. There is some settings that controls this but I have no clue which one it is <img width="2188" alt="Screenshot 2023-12-12 at 18 02 53" src=""
CSS is fun

.suggest-input-container .monaco-editor, .suggest-input-container .monaco-editor .lines-content { <del> background: none; </del> <ins> background: none !important; </ins> }


Question:
<!-- 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. --The direct symptom is in the site , but the investigation went through (which the site uses) and ends up here. Steps to Reproduce: to This shows the "LLVM Opt Pipeline Viewer" (1) which is a diff pane created by monaco's (2). It's contents change based on the user selection in from the 'passes' list (3). ! see normal operation in action: click in order the passes "SROAPass" (first one) and "Greedy Register Allocator". Diffs are shown properly: ! reproduce the bug, click in order the passes "SROAPass", then "Debug Variable Analysis" (one above Greedy) and finally "Greedy Register Allocator". First, text diffs are not being decorated despite being present: ! and second, a console shows the error: Preliminary investigation directs attention to these lines in 's : In the (not so rare) problematic scenario, and are non-empty but is, so the code enters the loop and crashes immediately. I suspect something broke in PR , but not sure.
A monaco-playground link with a small standalone repro for the problem: This creates a diffView and populates both sides with an offending text (specifically, one with non-empty "unchangedRegions"). After two seconds it sets the left pane to the same text as it currently has, but this time the decorations disappear and a console error message as above appears. Perhaps this tidbit would be helpful: It seems that upon entering , contains ids that were already invalidated - i.e., do not appear in : ! And so returns only nulls and the resulting array is empty. My current guess is these decoration-IDs invalidation is too early, and should be moved to after .
Thank you for the prompt fix!
Please, please, please, include inline diff view in your testing. I use inline view 99.9% of the time, side by side very rarely. Regardless, I hope this Thank you for your work.
I saw this problem again today.
Can you please share the output of the dev console? Thanks!

const lastUnchangedRegions = this._unchangedRegions.get(); const lastUnchangedRegionsOrigRanges = lastUnchangedRegions.originalDecorationIds .map(id => model.original.getDecorationRange(id)) <del> .filter(r => !!r) .map(r => LineRange.fromRange(r!)); </del> <ins> .map(r => r ? LineRange.fromRange(r) : undefined); </ins> const lastUnchangedRegionsModRanges = lastUnchangedRegions.modifiedDecorationIds .map(id => model.modified.getDecorationRange(id)) <del> .filter(r => !!r) .map(r => LineRange.fromRange(r!)); </del> <ins> .map(r => r ? LineRange.fromRange(r) : undefined); </ins> const originalDecorationIds = model.original.deltaDecorations( lastUnchangedRegions.originalDecorationIds,


Question:
<!-- 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. --The direct symptom is in the site , but the investigation went through (which the site uses) and ends up here. Steps to Reproduce: to This shows the "LLVM Opt Pipeline Viewer" (1) which is a diff pane created by monaco's (2). It's contents change based on the user selection in from the 'passes' list (3). ! see normal operation in action: click in order the passes "SROAPass" (first one) and "Greedy Register Allocator". Diffs are shown properly: ! reproduce the bug, click in order the passes "SROAPass", then "Debug Variable Analysis" (one above Greedy) and finally "Greedy Register Allocator". First, text diffs are not being decorated despite being present: ! and second, a console shows the error: Preliminary investigation directs attention to these lines in 's : In the (not so rare) problematic scenario, and are non-empty but is, so the code enters the loop and crashes immediately. I suspect something broke in PR , but not sure.
A monaco-playground link with a small standalone repro for the problem: This creates a diffView and populates both sides with an offending text (specifically, one with non-empty "unchangedRegions"). After two seconds it sets the left pane to the same text as it currently has, but this time the decorations disappear and a console error message as above appears. Perhaps this tidbit would be helpful: It seems that upon entering , contains ids that were already invalidated - i.e., do not appear in : ! And so returns only nulls and the resulting array is empty. My current guess is these decoration-IDs invalidation is too early, and should be moved to after .
Thank you for the prompt fix!
Please, please, please, include inline diff view in your testing. I use inline view 99.9% of the time, side by side very rarely. Regardless, I hope this Thank you for your work.
I saw this problem again today.
Can you please share the output of the dev console? Thanks!

for (const r of newUnchangedRegions) { for (let i = 0; i < lastUnchangedRegions.regions.length; i++) { <del> if (r.originalUnchangedRange.intersectsStrict(lastUnchangedRegionsOrigRanges[i]) && r.modifiedUnchangedRange.intersectsStrict(lastUnchangedRegionsModRanges[i])) { </del> <ins> if (lastUnchangedRegionsOrigRanges[i] && r.originalUnchangedRange.intersectsStrict(lastUnchangedRegionsOrigRanges[i]!) && lastUnchangedRegionsModRanges[i] && r.modifiedUnchangedRange.intersectsStrict(lastUnchangedRegionsModRanges[i]!)) { </ins> r.setHiddenModifiedRange(lastUnchangedRegions.regions[i].getHiddenModifiedRange(undefined), tx); break; }


Question: Initially noticed by : <img width="780" alt="Screenshot 2023-11-17 at 13 53 45" src=""

import { MarkdownString } from 'vs/base/common/htmlContent'; import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { LOCALIZED_START_INLINE_CHAT_STRING } from 'vs/workbench/contrib/inlineChat/browser/inlineChatActions'; <del> import { IBreakpoint, IDebugService } from 'vs/workbench/contrib/debug/common/debug'; </del> <ins> import { IBreakpoint, IDebugService, IDebugSession } from 'vs/workbench/contrib/debug/common/debug'; </ins> import { IPreferencesService } from 'vs/workbench/services/preferences/common/preferences'; import { URI } from 'vs/base/common/uri';


Question: Initially noticed by : <img width="780" alt="Screenshot 2023-11-17 at 13 53 45" src=""

private _gutterDecorationID: string | undefined; private _inlineChatKeybinding: string | undefined; private _hasInlineChatSession: boolean = false; <ins> private _hasActiveDebugSession: boolean = false; private _debugSessions: Set<IDebugSession> = new Set(); </ins> private readonly _localToDispose = new DisposableStore(); private readonly _gutterDecorationOpaque: IModelDecorationOptions; private readonly _gutterDecorationTransparent: IModelDecorationOptions;


Question: Initially noticed by : <img width="780" alt="Screenshot 2023-11-17 at 13 53 45" src=""

this._onEnablementOrModelChanged(); } })); <ins> this._register(this._debugService.onWillNewSession((session) => { this._debugSessions.add(session); if (!this._hasActiveDebugSession) { this._hasActiveDebugSession = true; this._onEnablementOrModelChanged(); } })); this._register(this._debugService.onDidEndSession((session) => { this._debugSessions.delete(session); if (this._debugSessions.size === 0) { this._hasActiveDebugSession = false; this._onEnablementOrModelChanged(); } })); </ins> this._register(this._inlineChatService.onDidChangeProviders(() => this._onEnablementOrModelChanged())); this._register(this._editor.onDidChangeModel(() => this._onEnablementOrModelChanged())); this._register(this._keybindingService.onDidUpdateKeybindings(() => {


Question: Initially noticed by : <img width="780" alt="Screenshot 2023-11-17 at 13 53 45" src=""

private _onEnablementOrModelChanged(): void { // cancels the scheduler, removes editor listeners / removes decoration this._localToDispose.clear(); <del> if (!this._editor.hasModel() || this._hasInlineChatSession || this._showGutterIconMode() === ShowGutterIcon.Never || !this._hasProvider()) { </del> <ins> if (!this._editor.hasModel() || this._hasActiveDebugSession || this._hasInlineChatSession || this._showGutterIconMode() === ShowGutterIcon.Never || !this._hasProvider()) { </ins> return; } const editor = this._editor;


Question:
Type: <bBug</bWhen reviewing outgoing changes for my tracking fork of microsoft/vscode after merging upstream/main into my local copy today. ! Also, based on I was surprised to see the magnifying glass icon still being used for "View Changes". VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-22T05:35:23.085Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
/assign
I'm very sure this is a duplicate of
This sounds like there was no insiders for today. Can you check you are running the build from today? The PR just got merged yesterday.
Yes, this is today's. The new codicon appears in the Timeline view, just not in the incoming/outgoing party of Source Control view: !
It does for me: !
Ah, we're not talking about the same thing. My screenshot is of the feature recently by and controlled by the and settings. It comes from here:
are you able to reproduce this consistently? Could you provide steps that that I should use to try to reproduce the issue? Thanks!
in said it was probably a known issue. Ever since Insiders got that fix I haven't had any problems opening multi-diff for outgoing changes that get listed after I merge from upstream/main into my local main prior to pushing them to origin/main (my tracking repo). So I'm closing this one.
thanks for the update!
Hmm, just happened to me again with today's Insiders: ! Reopening. I'll hold back from pushing the local changes that I merged in from upstream/main in case there are places you'd like me to look for clues while I can repro it.
Devtools console:
It's this one: ! And specifically which is of course binary: ! I guess the multi diff editor needs to handle this case gracefully instead of failing to show the diffs for the other files.
thanks! could you please take a look? Thanks!
Ahh, because it is a binary file...

*--------------------------------------------------------------------------------------------*/ import { LazyStatefulPromise, raceTimeout } from 'vs/base/common/async'; <ins> import { onUnexpectedError } from 'vs/base/common/errors'; </ins> import { IDisposable, DisposableStore, toDisposable } from 'vs/base/common/lifecycle'; import { deepClone } from 'vs/base/common/objects'; <del> import { isObject } from 'vs/base/common/types'; </del> <ins> import { isDefined, isObject } from 'vs/base/common/types'; </ins> import { URI } from 'vs/base/common/uri'; import { ConstLazyPromise, IDocumentDiffItem, IMultiDiffEditorModel } from 'vs/editor/browser/widget/multiDiffEditorWidget/model'; import { MultiDiffEditorViewModel } from 'vs/editor/browser/widget/multiDiffEditorWidget/multiDiffEditorViewModel';


Question:
Type: <bBug</bWhen reviewing outgoing changes for my tracking fork of microsoft/vscode after merging upstream/main into my local copy today. ! Also, based on I was surprised to see the magnifying glass icon still being used for "View Changes". VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-22T05:35:23.085Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
/assign
I'm very sure this is a duplicate of
This sounds like there was no insiders for today. Can you check you are running the build from today? The PR just got merged yesterday.
Yes, this is today's. The new codicon appears in the Timeline view, just not in the incoming/outgoing party of Source Control view: !
It does for me: !
Ah, we're not talking about the same thing. My screenshot is of the feature recently by and controlled by the and settings. It comes from here:
are you able to reproduce this consistently? Could you provide steps that that I should use to try to reproduce the issue? Thanks!
in said it was probably a known issue. Ever since Insiders got that fix I haven't had any problems opening multi-diff for outgoing changes that get listed after I merge from upstream/main into my local main prior to pushing them to origin/main (my tracking repo). So I'm closing this one.
thanks for the update!
Hmm, just happened to me again with today's Insiders: ! Reopening. I'll hold back from pushing the local changes that I merged in from upstream/main in case there are places you'd like me to look for clues while I can repro it.
Devtools console:
It's this one: ! And specifically which is of course binary: ! I guess the multi diff editor needs to handle this case gracefully instead of failing to show the diffs for the other files.
thanks! could you please take a look? Thanks!
Ahh, because it is a binary file...

import { EditorInput } from 'vs/workbench/common/editor/editorInput'; import { ILanguageSupport } from 'vs/workbench/services/textfile/common/textfiles'; <ins> /* hot-reload:patch-prototype-methods */ </ins> export class MultiDiffEditorInput extends EditorInput implements ILanguageSupport { static readonly ID: string = 'workbench.input.multiDiffEditor';