jiebi/CodeConvo huggingface dataset:
Code change:
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!

Related discussion:
text: }, [], `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;
Code change:
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.

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: 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';
Code change:
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.

Related discussion:
text: 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({
Code change:
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.

Related discussion:
text: 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({
Code change:
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.

Related discussion:
text: 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,
Code change:
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.

Related discussion:
text: 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({
Code change:
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.

Related discussion:
text: } } <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()) {
Code change:
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.

Related discussion:
text: 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;
Code change:
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.

Related discussion:
text: quickPick.hide(); colorStyleDisposable.dispose(); <ins> return result?.id; </ins> } selectPreviousSuggestion(): void {
Code change:
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.

Related discussion:
text: 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);
Code change:
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.

Related discussion:
text: 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");
Code change:
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.

Related discussion:
text: 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 }, {
Code change:
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.

Related discussion:
text: 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; }
Code change:
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.

Related discussion:
text: 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');