jiebi/CodeConvo huggingface dataset:
Change:
Testing a screenreader. to the Incoming/Outgoing part of the SCM viewlet. Actual: "Incoming/Outgoing". Expected: something like "Incoming and outgoing changes" screenreader reads origin/some-branch-name for the incoming changes. Expected: "origin/some-branch-name incoming" or "incoming changes from origin/some-branch-name" screenreader reads some-branch-name for the outgoing changes. Expected: "some-branch-name outgoing" or "outgoing changes from some-branch-name" CC for alternative suggestions
Great point, we should lead with the info, so place "outgoing" or "incoming" before the branch name in this case.
I have confirmed that the titles show up upon hovering over the entries, but that NVDA still reads the text as-is rather than reading the title text. Reopening.
That's interesting given that I am using the IconLabel widget's property to set the aria label.

Discussion:
templateData.iconContainer.classList.add(...ThemeIcon.asClassNameArray(historyItemGroup.icon)); } <del> templateData.label.setLabel(historyItemGroup.label, historyItemGroup.description); </del> <ins> templateData.label.setLabel(historyItemGroup.label, historyItemGroup.description, { title: historyItemGroup.ariaLabel }); </ins> templateData.count.setCount(historyItemGroup.count ?? 0); }

return { label, disposables: new DisposableStore() }; } renderElement(element: ITreeNode<SCMViewSeparatorElement, void>, index: number, templateData: SeparatorTemplate, height: number | undefined): void { <del> templateData.label.setLabel(element.element.label); </del> <ins> templateData.label.setLabel(element.element.label, undefined, { title: element.element.ariaLabel }); </ins> } renderCompressedElements(node: ITreeNode<ICompressedTreeNode<SCMViewSeparatorElement>, void>, index: number, templateData: SeparatorTemplate, height: number | undefined): void {

if (historyItemGroups.length > 0) { children.push({ label: localize('syncSeparatorHeader', "Incoming/Outgoing"), <ins> ariaLabel: localize('syncSeparatorHeaderAriaLabel', "Incoming and outgoing changes"), </ins> repository: inputOrElement, type: 'separator' } as SCMViewSeparatorElement);

(this.showIncomingChanges() === 'auto' && (historyItemGroupDetails.incoming.count ?? 0) > 0))) { children.push({ ...historyItemGroupDetails.incoming, <ins> ariaLabel: localize('incomingChangesAriaLabel', "Incoming changes from {0}", historyItemGroupDetails.incoming.label), </ins> repository: element, type: 'historyItemGroup' });

(this.showOutgoingChanges() === 'auto' && (historyItemGroupDetails.outgoing.count ?? 0) > 0))) { children.push({ ...historyItemGroupDetails.outgoing, <ins> ariaLabel: localize('outgoingChangesAriaLabel', "Outgoing changes from {0}", historyItemGroupDetails.outgoing.label), </ins> repository: element, type: 'historyItemGroup' });

} export interface SCMHistoryItemGroupTreeElement extends ISCMHistoryItemGroupEntry { <ins> readonly ariaLabel?: string; </ins> readonly repository: ISCMRepository; readonly type: 'historyItemGroup'; }

export interface SCMViewSeparatorElement { readonly label: string; <ins> readonly ariaLabel?: string; </ins> readonly repository: ISCMRepository; readonly type: 'separator'; }
Change:
Testing a screenreader. to the Incoming/Outgoing part of the SCM viewlet. Actual: "Incoming/Outgoing". Expected: something like "Incoming and outgoing changes" screenreader reads origin/some-branch-name for the incoming changes. Expected: "origin/some-branch-name incoming" or "incoming changes from origin/some-branch-name" screenreader reads some-branch-name for the outgoing changes. Expected: "some-branch-name outgoing" or "outgoing changes from some-branch-name" CC for alternative suggestions
Great point, we should lead with the info, so place "outgoing" or "incoming" before the branch name in this case.
I have confirmed that the titles show up upon hovering over the entries, but that NVDA still reads the text as-is rather than reading the title text. Reopening.
That's interesting given that I am using the IconLabel widget's property to set the aria label.

Discussion:
} else if (isSCMResourceGroup(element)) { return element.label; } else if (isSCMHistoryItemGroupTreeElement(element)) { <del> return `${stripIcons(element.label).trim()}${element.description ? `, ${element.description}` : ''}`; </del> <ins> return element.ariaLabel ?? `${element.label.trim()}${element.description ? `, ${element.description}` : ''}`; </ins> } else if (isSCMHistoryItemTreeElement(element)) { return `${stripIcons(element.label).trim()}${element.description ? `, ${element.description}` : ''}`; } else if (isSCMHistoryItemChangeTreeElement(element)) {

return result.join(', '); } else if (isSCMViewSeparator(element)) { <del> return element.label; </del> <ins> return element.ariaLabel ?? element.label; </ins> } else { const result: string[] = [];
Change:
Testing I don't seem to have the sync changes button available to me, unless you're referring to the small icons in the status bars. !
I was able to get the Sync Changes button with the node-spdlog repository on my mac. It could be because my Windows machine and/or the vscode repository I tested with both have
that should not be the case. In your screenshot, I see that you have both incoming and outgoing changes, and no pending changes so the "Sync Changes" button should be shown instead of the disabled "Commit" button. Could you please share the exact steps that got you into this state? Also what is the value of the setting?
The has the default value. I seemed to repro it again, so here are some steps: the microsoft/vscode repository, switch to a new branch off of the main branch a file and push to establish the remote version of the branch , edit a separate file on that (remote) branch and commit the change directly to that branch. , edit yet another file and commit the change. Do not push. the git fetch command. :bug: There are both incoming and outgoing changes but the sync button does not appear.
Thanks for the steps. I will keep trying but for now I am unable to reproduce the issue: !

Discussion:
this.onDidChangeSmartCommitSettings(); } <del> if (e.affectsConfiguration('scm.experimental.showSyncView') || e.affectsConfiguration('git.branchProtectionPrompt', root) || </del> <ins> if (e.affectsConfiguration('git.branchProtectionPrompt', root) || </ins> e.affectsConfiguration('git.postCommitCommand', root) || e.affectsConfiguration('git.rememberPostCommitCommand', root) || e.affectsConfiguration('git.showActionButton', root)) {

} protected override getPublishBranchActionButton(): SourceControlActionButton | undefined { <del> const scmConfig = workspace.getConfiguration('scm'); if (scmConfig.get<boolean>('experimental.showSyncView', false)) { return undefined; } </del> const config = workspace.getConfiguration('git', Uri.file(this.repository.root)); const showActionButton = config.get<{ publish: boolean }>('showActionButton', { publish: true });

} protected override getSyncChangesActionButton(): SourceControlActionButton | undefined { <del> const scmConfig = workspace.getConfiguration('scm'); if (scmConfig.get<boolean>('experimental.showSyncView', false)) { return undefined; } </del> const config = workspace.getConfiguration('git', Uri.file(this.repository.root)); const showActionButton = config.get<{ sync: boolean }>('showActionButton', { sync: true }); const branchIsAheadOrBehind = (this.state.HEAD?.behind ?? 0) > 0 || (this.state.HEAD?.ahead ?? 0) > 0;
Change:
Some commands take a while to resolve. We indicate that progress is happening for screen reader users with the progress audio cue and we indicate completion by reading the response immediately after it's resolved. Sighted users now see step by step progress. For example, for requests, the following are presented with spinner information: Collecting workspace structure Deciding which workspace information to collect Collecting workspace info This information is fleeting and disappears when the response begins to render. ! Because these can take a variable amount of time, and could be very noisy, I'm considering a few approaches and would like your feedback and I think number 3 is the best. use - a downside is the announcement might not be relevant by the time it is announced. use - a downside is this is really noisy and could be disruptive. have a command and key binding to query the status. So, if it's taking a while, a user could run this to find out which step it is on.
I believe there is not a good solution for things like this one at the moment. I think I would prefer approach number 1 (alert). At least with Voiceover, and alert would be cancel if a second alert comes in. approach number 2 wouold create a queue of invalid messages that will be read even if the response is already available, and approach number 3 (a new key-binding) would requiree learning and integrating a new keyboard command for something that is not worth it in my opinion. I would also make these announcement customizable in settings so that people can turn them off if they don't find them helpful.
Thanks for starting this discussion. I wonder i this needs to be treated differently than other progress experiences in VS Code? For progress we use the role I am not sure how well it is supported by screen readers though.
I was thinking of status messages. Is this like a progress bar where each steps gets highlighted as it progresses?
Yes, it is clear which step is happening at any given time.
Enable a screen reader. Run a command which reports progress steps - . Verify that you hear each of these steps as it becomes visible.

Discussion:
import * as dom from 'vs/base/browser/dom'; import { IActionViewItemOptions } from 'vs/base/browser/ui/actionbar/actionViewItems'; <del> import { AriaRole } from 'vs/base/browser/ui/aria/aria'; </del> <ins> import { AriaRole, alert } from 'vs/base/browser/ui/aria/aria'; </ins> import { Button } from 'vs/base/browser/ui/button/button'; import { renderIcon } from 'vs/base/browser/ui/iconLabel/iconLabels'; import { IListRenderer, IListVirtualDelegate } from 'vs/base/browser/ui/list/list';

} private renderProgressMessage(progress: IChatProgressMessage, showSpinner: boolean): IMarkdownRenderResult { <ins> if (showSpinner) { // this step is in progress, communicate it to SR users alert(progress.content.value); } </ins> const codicon = showSpinner ? ThemeIcon.modify(Codicon.sync, 'spin').id : Codicon.check.id; const markdown = new MarkdownString(`$(${codicon}) ${progress.content.value}`, { supportThemeIcons: true
Change:
Testing Instead of opening the settings editor to you could use to show just that one setting. at one point when there was an exact ID match in the settings editor, we would only show that one setting. It seems like that is happening for some settings (like doesn't show ) but here I see a bunch of results <img width="650" alt="image" src=""did we get rid of that logic or is it just semantic matches kicking in?
The logic is still there, but it's buggy because it didn't sort some entries properly

Discussion:
}; const filterMatches = preferencesModel.filterSettings(this._filter, this.getGroupFilter(this._filter), settingMatcher); <del> if (filterMatches[0] && filterMatches[0].score === LocalSearchProvider.EXACT_MATCH_SCORE) { </del> <ins> const exactMatch = filterMatches.find(m => m.score === LocalSearchProvider.EXACT_MATCH_SCORE); if (exactMatch) { </ins> return Promise.resolve({ <del> filterMatches: filterMatches.slice(0, 1), </del> <ins> filterMatches: [exactMatch], </ins> exactMatch: true }); } else {
Change:
Testing Works on macOS but not on Windows 11 !
Works for me on Windows 11. at the lack of command start decoration on the following line in the screenshot where this doesn't work. !
Logs from
is happening after the next in the above, which is pretty weird. We try to detect quick fixes , so it's not surprising this is failing. any thoughts?
I likely caused this when making command markers more reliable on Windows
Seems this is broken for the non-polling case, which is why I am not seeing it (with starship).

Discussion:
this._disposeQuickFix(this._lastQuickFixId, false); } <del> // Wait for the next command to start to ensure the quick fix marker is created on the next // prompt line const commandDetection = this._capabilities.get(TerminalCapability.CommandDetection); if (commandDetection) { await Event.toPromise(commandDetection.onCommandStarted); } </del> const resolver = async (selector: ITerminalQuickFixOptions, lines?: string[]) => { if (lines === undefined) { return undefined;
Change:
I like the AI sparkle but I think its color is too strong. IMO it should be less strong and so that it blends away a little more <img width="192" alt="Screenshot 2023-11-29 at 12 46 12" src=""
for help
Hey thanks for writing about this, this is indeed a good point. I can make the opacity lower (set it for example to 0.5). With such an opacity, the icon looks as follows: ! ! What do you think ?
Looks like an improvement

Discussion:
"--vscode-editorInlayHint-typeBackground", "--vscode-editorInlayHint-typeForeground", "--vscode-editorLightBulb-foreground", <ins> "--vscode-editorLightBulbAi-foreground", </ins> "--vscode-editorLightBulbAutoFix-foreground", "--vscode-editorLineNumber-activeForeground", "--vscode-editorLineNumber-dimmedForeground",

"--zoom-factor", "--test-bar-width" ] <del> } </del> <ins> } </ins>  No newline at end of file

color: var(--vscode-editorLightBulbAutoFix-foreground, var(--vscode-editorLightBulb-foreground)); } <ins> .monaco-editor .lightBulbWidget.codicon-sparkle-filled { color: var(--vscode-editorLightBulbAi-foreground, var(--vscode-icon-foreground)); } </ins> .monaco-editor .lightBulbWidget:before { position: relative; z-index: 2;

*/ export const editorLightBulbForeground = registerColor('editorLightBulb.foreground', { dark: '#FFCC00', light: '#DDB100', hcDark: '#FFCC00', hcLight: '#007ACC' }, nls.localize('editorLightBulbForeground', "The color used for the lightbulb actions icon.")); export const editorLightBulbAutoFixForeground = registerColor('editorLightBulbAutoFix.foreground', { dark: '#75BEFF', light: '#007ACC', hcDark: '#75BEFF', hcLight: '#007ACC' }, nls.localize('editorLightBulbAutoFixForeground', "The color used for the lightbulb auto fix actions icon.")); <ins> export const editorLightBulbAiForeground = registerColor('editorLightBulbAi.foreground', { dark: darken(iconForeground, 0.4), light: lighten(iconForeground, 1.7), hcDark: iconForeground, hcLight: iconForeground }, nls.localize('editorLightBulbAiForeground', "The color used for the lightbulb AI icon.")); </ins> /** * Diff Editor Colors
Change:
Currently we do not really track MRU of editor groups across windows. Some features rely on this though, so we should see if we can track MRU truly across aux windows.

Discussion:
import { localize } from 'vs/nls'; import { EditorGroupLayout, GroupDirection, GroupLocation, GroupOrientation, GroupsArrangement, GroupsOrder, IAuxiliaryEditorPart, IAuxiliaryEditorPartCreateEvent, IEditorDropTargetDelegate, IEditorGroupsService, IEditorSideGroup, IFindGroupScope, IMergeGroupOptions } from 'vs/workbench/services/editor/common/editorGroupsService'; import { Emitter } from 'vs/base/common/event'; <del> import { DisposableStore, IDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { DisposableStore, IDisposable, toDisposable } from 'vs/base/common/lifecycle'; </ins> import { GroupIdentifier } from 'vs/workbench/common/editor'; import { EditorPart, MainEditorPart } from 'vs/workbench/browser/parts/editor/editorPart'; import { IEditorGroupView, IEditorPartsView } from 'vs/workbench/browser/parts/editor/editor';

readonly mainPart = this._register(this.createMainEditorPart()); <ins> private readonly mostRecentActiveParts = [this.mainPart]; </ins> constructor( @IInstantiationService private readonly instantiationService: IInstantiationService ) {

private registerEditorPartListeners(part: EditorPart, disposables: DisposableStore): void { disposables.add(part.onDidFocus(() => { <ins> this.doUpdateMostRecentActive(part, true); </ins> if (this._parts.size > 1) { this._onDidActiveGroupChange.fire(this.activeGroup); // this can only happen when we have more than 1 editor part } })); <ins> disposables.add(toDisposable(() => this.doUpdateMostRecentActive(part))); </ins> disposables.add(part.onDidChangeActiveGroup(group => this._onDidActiveGroupChange.fire(group))); disposables.add(part.onDidAddGroup(group => this._onDidAddGroup.fire(group)));

disposables.add(part.onDidChangeGroupLocked(group => this._onDidChangeGroupLocked.fire(group))); } <ins> private doUpdateMostRecentActive(part: EditorPart, makeMostRecentlyActive?: boolean): void { const index = this.mostRecentActiveParts.indexOf(part); // Remove from MRU list if (index !== -1) { this.mostRecentActiveParts.splice(index, 1); } // Add to front as needed if (makeMostRecentlyActive) { this.mostRecentActiveParts.unshift(part); } } </ins> private getGroupsLabel(index: number): string { return localize('groupLabel', "Window {0}", index + 1); }

getGroups(order = GroupsOrder.CREATION_TIME): IEditorGroupView[] { if (this._parts.size > 1) { let parts: EditorPart[]; <del> if (order === GroupsOrder.MOST_RECENTLY_ACTIVE) { parts = distinct([this.activePart, ...this._parts]); // put active part first in this order } else { parts = this.parts; </del> <ins> switch (order) { case GroupsOrder.GRID_APPEARANCE: // we currently do not have a way to compute by appearance over multiple windows case GroupsOrder.CREATION_TIME: parts = this.parts; break; case GroupsOrder.MOST_RECENTLY_ACTIVE: parts = distinct([...this.mostRecentActiveParts, ...this.parts]); // always ensure all parts are included break; </ins> } return parts.map(part => part.getGroups(order)).flat();
Change:
<!-- 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. --Can the default file icon theme be updated in VS Code (seems just need to follow the to run the script) files should by now have the Maven (mvnw) icon but are still showing regular XML icon.
Verify that the files now have the Maven (mvnw) icon

Discussion:
"git": { "name": "seti-ui", "repositoryUrl": "https://github.com/jesseweed/seti-ui", <del> "commitHash": "fd20793e5a75b350eab8d489165fb9b420df3f62" </del> <ins> "commitHash": "8eec7f2e37cd8fd91a98c61d129468bb49735a94" </ins> } }, "version": "0.1.0"

"version.txt": "_clock", "version": "_clock", "mvnw": "_maven", <ins> "pom.xml": "_maven", </ins> "tsconfig.json": "_tsconfig", "swagger.json": "_json_1", "swagger.yml": "_json_1",

"sql": "_db", "swift": "_swift", "typescript": "_typescript", <del> "typescriptreact": "_typescript", </del> <ins> "typescriptreact": "_react", </ins> "xml": "_xml", "dockercompose": "_docker_3", "yaml": "_yml",

"sql": "_db_light", "swift": "_swift_light", "typescript": "_typescript_light", <del> "typescriptreact": "_typescript_light", </del> <ins> "typescriptreact": "_react_light", </ins> "xml": "_xml_light", "dockercompose": "_docker_3_light", "yaml": "_yml_light",

"version.txt": "_clock_light", "version": "_clock_light", "mvnw": "_maven_light", <ins> "pom.xml": "_maven_light", </ins> "tsconfig.json": "_tsconfig_light", "swagger.json": "_json_1_light", "swagger.yml": "_json_1_light",

"npm-debug.log": "_npm_ignored_light" } }, <del> "version": "https://github.com/jesseweed/seti-ui/commit/fd20793e5a75b350eab8d489165fb9b420df3f62" </del> <ins> "version": "https://github.com/jesseweed/seti-ui/commit/8eec7f2e37cd8fd91a98c61d129468bb49735a94" </ins> }  No newline at end of file
Change:
Testing Related: The UX degrades quite a bit when the maximum item count is hit. Thinking about the explorer specifically and the maximum 40% height cap, I think it makes sense to increase the maximum to something closer to 10. Here's my standard explorer setup: ! This has plenty of room to include the sticky scroll entries, which not only improve contextual awareness of , but every file in the view at that time, especially with guides showing: ! not sure if you've seen similar feedback for editor? I rarely have code indented that deep fwiw, but that's just my preferred style.
So I have not received feature requests for this in the editor. I think the code is less nested generally than in the explorer, where you can easily have a nesting with 10 levels.
because of that I think we're bad users to evaluate whether this is needed. The question is, as a user who frequently writes/reads deeply nested code, is it better to take an additional 20+ pixels per row for the proper context showing. Provided we have a decent maximum percentage cap I would guess that the answer will usually be yes, and in the off case where it's no the user can decrease the maximum themselves.
I was planning on increasing it, but wasn't sure yet what value to pick. 10 seems like a lot even if the user has the space for it. I think I will increase it to around 7/8. I'm also looking into other solutions which would compress multiple nodes into one when the limit is reached, but this won't be part of this release. I think 5 is good for the other two sticky scrolls.
I came up with a similar idea to compress which I think will be even better than increasing the max like that !
Should this not be based on screen size rather than a concrete item limit? My screen is a tiny 13" macbook and does not have room for 7/8
there's a cap of 40% of screen size regardless of the setting value

Discussion:
[treeStickyScrollMaxElements]: { type: 'number', minimum: 1, <del> default: 5, </del> <ins> default: 7, </ins> markdownDescription: localize('sticky scroll maximum items', "Controls the number of sticky elements displayed in the tree when `#workbench.tree.enableStickyScroll#` is enabled."), }, [typeNavigationModeSettingKey]: {
Change:
Repro: terminal with sticky scroll enabled command that "overflows screen" (ie, it scroll terminal beyond what's visible) it once again to again overflow screen (not sure if it needs to be run again, but that's how I repro'ed) screen (ctrl+l) once again & see sticky scroll shown even though not required (also reported with vid and logs in DM to ) Version: 1.85.0-insider Commit: Date: 2023-11-29T02:45:05.413Z Electron: 25.9.6 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin arm64 23.1.0

Discussion:
return; } <ins> // Hide sticky scroll if the prompt has been trimmed from the buffer if (command.promptStartMarker?.line === -1) { this._setVisible(false); return; } </ins> // Determine sticky scroll line count const buffer = xterm.buffer.active; const promptRowCount = command.getPromptRowCount();