jiebi/CodeConvo huggingface dataset:
Code change:
static id: 'editor.action.accessibleViewNext'; constructor() { super({ <del> id: AccessibleViewNextAction.id, </del> <ins> id: 'editor.action.accessibleViewNext', </ins> precondition: accessibleViewIsShown, keybinding: { primary: KeyMod.Alt | KeyCode.BracketRight,

Related discussion:
text: One way of resolving this would be repeating the position information when I press any of the commands, even if there is no change. Another possibility would be to prevent the widget from refocusing when I am in the first / last element, and I try to move beyond that element. In that way pressing the next command will not produce any feedback if I am in the last one, and the previous will not produce any feedback if I am in the first one. Does it make sense? In any case, this would be a refinement, not something that would prevent someone from using the feature. Originally posted by in
Something else to consider when fine tuning the responses. Right now, position information is announced using an alert in macOS, and a status message in Windows. This is a situation where it makes sense to use an alert in all platforms so that screen readers prioritize this over other events. For example, right now JAWS is announcing position information after reannouncing the widget.
Huh, I'm using for all platforms here which appears to be platform agnostic I think it might just be a JAWS issue - does this repro when using NVDA?
It doesn't, but NVDA handles aria-live differently. You may be right dough. I'll debug NVDA on Monday and we'll know for sure which event it is seeing. JAWS may be simply prioritizing the focus event.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Focus an accessible view for which there are several elements (like chat responses or notifications). Verify that if you are on the first or last element, pressing next or previous does not result in repeated alerts. it should not notify the screen reader user as nothing has changed.
Note to verifier there's an issue to disable these actions when they cannot be taken, which is the better fix.
Verified. With NVDA, if I press enter on the Next button while on the last chat response, the focus goes back to the response text instead of staying on the button, though that might be by design.
Code change:
} this._accessibleBuffer.tabIndex = -1; this._accessibleBuffer.classList.add('active'); <del> this._xtermElement.classList.add('hide'); </del> if (this._lastContentLength !== fragment.length || this._refreshSelection) { let lineNumber = 1; const lineCount = model?.getLineCount();

Related discussion:
text: Type: <bBug</bcc: Since Friday the 3rd, I have not been able to access the terminal accessibility buffer in my linux environment. I activate a terminal and am informed by orca about accessibility in the terminal. But pressing shift+tab does not move the focus to the accessibility buffer. Am I doing something wrong or has something changed from day 3? VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-06T05:21:55.128Z) OS version: Linux x64 6.1.14-200.fc37.x8664 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (39)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.49.0 vscode-chatgpt3.9.4 rest-client0.25.1 better-cpp-syntax1.17.2 azure-pipelines1.208.0 vscode-docker1.24.0 csharp1.25.4 vscode-dotnet-runtime1.6.0 vscode-kubernetes-tools1.3.11 remote-containers0.283.0 remote-ssh0.99. remote-ssh-edit0.84.0 azure-account0.11.3 cmake-tools1.13.45 cpptools1.14.4 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell-preview2023.2.1 remote-explorer0.3. vsliveshare1.0.5832 oracledevtools21.5.0 fabric8-analytics0.3.6 java1.16. vscode-xml0.25. vscode-yaml1.11.0 sonarlint-vscode3.15.1 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.44.0 vscode-java-debug0.49. vscode-java-dependency0.21. vscode-java-pack0.25. vscode-java-test0.38. vscode-maven0.40.
Code change:
} this._accessibleBuffer.tabIndex = -1; this._accessibleBuffer.classList.add('active'); <del> this._xtermElement.classList.add('hide'); </del> if (this._lastContentLength !== fragment.length || this._refreshSelection) { let lineNumber = 1; const lineCount = model?.getLineCount();

Related discussion:
text: vscode-spring-boot-dashboard0.11.1 vscode-spring-initializr0.11.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
You can use this command for now, but I can repro the issue
The other change that has been made here is tab moves focus mode has to be on for that keybinding to work. This prevents issues where the terminal should be handling shift + tab such as for or autocomplete. The clause for this command can be configured in the keybindings editor though if you do not like this behavior.
After using the command Terminal: Focus Accessible Buffer, the behavior was a little strange. focus is on the accessible buffer, the tab key does not move focus to the terminal, but to the status bar. When I'm in the accessible buffer I need to press tab and then shift+tab to access the terminal. seems that the accessible buffer is not always updated when I execute a command in the terminal.
Yes thanks, covered in these issues:
Code change:
} this._accessibleBuffer.tabIndex = -1; this._accessibleBuffer.classList.add('active'); <del> this._xtermElement.classList.add('hide'); </del> if (this._lastContentLength !== fragment.length || this._refreshSelection) { let lineNumber = 1; const lineCount = model?.getLineCount();

Related discussion:
text: there's an issue now because tabbing goes to the status bar instead of the terminal. I see that isn't set on the element. even when I set that explicitly, it seems like it's removed Originally posted by in
Code change:
null, this._contextViewService, { <ins> // width:FIND_INPUT_AREA_WIDTH, </ins> label: NLS_FIND_INPUT_LABEL, placeholder: NLS_FIND_INPUT_", validation: (value: string): InputBoxMessage | null => {

Related discussion:
text: Testing I found "Find in Cell Selection" confusing label for the button given it is to find in selected cells. Does it make sense? Would "Find in Selected Cells" be a bit easier? !
Yeah, agreed that the labeling isn't perfect. Will workshop this in the next iteration, as this button will be serving dual purpose as a way to search in textual selections within a cell, as well as searching in multi-cell selections as the feature is currently. Thanks for the feedback!
Code change:
null, this._contextViewService, { <ins> // width:FIND_INPUT_AREA_WIDTH, </ins> label: NLS_FIND_INPUT_LABEL, placeholder: NLS_FIND_INPUT_", validation: (value: string): InputBoxMessage | null => {

Related discussion:
text: Notebooks: ! Editor: ! Version: 1.90.0-insider Commit: Date: 2024-05-28T05:48:32.492Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Darwin arm64 23.4.0
Code change:
null, this._contextViewService, { <ins> // width:FIND_INPUT_AREA_WIDTH, </ins> label: NLS_FIND_INPUT_LABEL, placeholder: NLS_FIND_INPUT_", validation: (value: string): InputBoxMessage | null => {

Related discussion:
text: Type: <bBug</bThe default width feels small, especially that we have 4 icons in the notebook find widget. It can only render 6 characters and then truncate. ! VS Code version: Code - Insiders 1.88.0-insider (, 2024-03-28T22:10:25.599Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (27)</summaryExtensionVersion ------ esbuild-problem-matchers0.0.3 vscode-eslint2.4.4 vscode-deno3.36.0 gitlens2024.3.2805 EditorConfig0.16.4 prettier-vscode10.4.0 copilot1.176.0 copilot-chat0.14. vscode-pull-request-github0.85. vscode-mocha-test-adapter2.14.1 vscode-test-explorer2.21.1 vscode-dotnet-runtime2.0.3 black-formatter2024.1. debugpy2024.2.0 isort2023.10.1 python2024.3. vscode-pylance2024.3.102 datawrangler0.29.6 jupyter2024.3. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.353.0 extension-test-runner0.0.6 test-adapter-converter0.1.9 vscode-github-issue-notebooks0.0.130 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Code change:
env: GITHUB_TOKEN: "$(github-distro-mixin-password)" displayName: Build server <del> condition: and(succeeded(), ne(variables['VSCODE_ARCH'], 'arm64')) </del> - powershell: | . build/azure-pipelines/win32/exec.ps1

Related discussion:
text: It appears that this is possible now, and we should consider adopting this in VS Code ()
There is community interest:
Please add this!
Steps for verification: Connect to Windows arm64 using the latest pre-release of SSH extension () Verify that connection is successful Use or similar tool to confirm that executable is of architecture.
Code change:
menuId: this._options?.contextMenu, menuActionOptions: { renderShortTitle: true, ...this._options?.menuOptions }, contextKeyService: this._contextKeyService, <del> onHide: () => this.getElement().classList.toggle('config', false), </del> }); })); }

Related discussion:
text: I recently noticed an animation to indicate toolbar actions can be changed: ! This seems to be inspired by Safari toolbar when you edit it: ! I am seeing a few issues with our approach: we allow to change visibility of actions in a lot of places (activity bar, status bar) where currently there is no such animation in Safari to get into this mode, the user explicitly picks an action "Customize Toolbar" while for us it starts on right click already in Safari you can actually grab an action and move it, I even think they only animate the action to make that more obvious (not so much the fact that you can hide the action) I would vote for not having the animation until we can support what Safari does including to drag and reorder actions. I think the menu makes it already clear what the right click gesture allows you to do: <img width="299" alt="image" src="https://user-"
Yes, thanks, this feels very strange to me. I don't think animating the whole menubar make sense when you are only operating on a single item.
How about beginning a right-click menu with an inactive entry that acts as a header? Something like "Button Visibility". It would also act as a protection against accidental hiding, since I can imagine some folk inadvertently pressing right button down, moving the mouse a few pixels right, releasing the button and seeing vanish the button they intended to actuate. Especially on Linux where there's a longstanding issue about this happening on context menus at certain Zoom levels and certain places on the screen.
related/motivation
Well, strictly speaking you operate on the whole menu because you also have toggle actions for all its entries. I like that direction. We already do something similar to right click the overflow item. You cannot hide that but you get a disabled "Hide" entry for consistency. On the flip side it is bogus use of menu items as "headers" <img width="340" alt="Screenshot 2022-09-29 at 08 23 30" src="https://user-"Overall the motivation for same kind of animation is mostly the . Left and right click show a context menu which do very different things but look very similar
Any scope for changing the button icon when in this edit mode? Maybe to pencil or gearwheel.
Note that animations like this look pretty terrible on standard DPI monitors due to the blurriness.
Code change:
menuId: this._options?.contextMenu, menuActionOptions: { renderShortTitle: true, ...this._options?.menuOptions }, contextKeyService: this._contextKeyService, <del> onHide: () => this.getElement().classList.toggle('config', false), </del> }); })); }

Related discussion:
text: It also removes sub-pixel anti-aliasing which makes it look even more different to non-animating. ! Regular: ! Animating: !
is that specific to this animation or something you notice with animations in general? Like the sync-spinner or the language status wiggle?
I also think the spinner looks pretty bad, though it's less noticeable than this I don't think I've noticed this, but any animation like these should have this problem. You can notice it when websites use animations as well, the shift from animated to non-animated is often jarring.
Or even spinning gearwheel
Can you please file a dedicated issue? There is a bunch of places that use CSS animations and if there is a flaw with that we should look at it holistically Created to disable the animation for now. Let's take time in October to revisit this. Lets discuss (1) if this is really needed and (2) if we should align other hide-able items (consistency is key)
created with a lot of details
Code change:
if (!node.hasChildren) { childrenPromise = Promise.resolve(Iterable.empty()); } else { <del> const slowTimeout = timeout(800); </del> <ins> const children = this.doGetChildren(node); if (isIterable(children)) { childrenPromise = Promise.resolve(children); } else { const slowTimeout = timeout(800); </ins> <del> slowTimeout.then(() => { node.slow = true; this._onDidChangeNodeSlowState.fire(node); }, _ => null); </del> <ins> slowTimeout.then(() => { node.slow = true; this._onDidChangeNodeSlowState.fire(node); }, _ => null); </ins> <del> childrenPromise = this.doGetChildren(node) .finally(() => slowTimeout.cancel()); </del> <ins> childrenPromise = children.finally(() => slowTimeout.cancel()); } </ins> } try {

Related discussion:
text: takes much longer to render with file nesting enabled. Impact is lessened by disabling file nest auto-expansions. is not significantly slower to render with nesting, though I have not collected proper numbers yet.
closedWith
takes a comparable amount of time to render with file nesting enabled, though there is a perceptible delay for both. However, I do also notice that the window becomes intermittently unresponsive after expanding , e.g. when scrolling in the explorer. Is this known?
Yeah, same thing happens with nesting disabled. There's an open issue somewhere for ways to reduce that (like streaming the dir contents).
Code change:
} } <del> const tocHiddenDuringSearch = this.configurationService.getValue('workbench.settings.settingsSearchTocBehavior') === 'hide'; if (!tocHiddenDuringSearch) { // Sort the settings according to internal order if indexed. if (this.settingsOrderByTocIndex) { filterMatches.sort((a, b) => compareTwoNullableNumbers(a.setting.internalOrder, b.setting.internalOrder)); } return filterMatches; </del> <ins> // The search only has filters, so we can sort by the order in the TOC. if (!this._viewState.query) { return filterMatches.sort((a, b) => compareTwoNullableNumbers(a.setting.internalOrder, b.setting.internalOrder)); </ins> } <del> // The table of contents is hidden during the search. // The settings could appear in a more haphazard order. // Sort the settings according to their score. </del> <ins> // Sort the settings according to their relevancy. // https://github.com/microsoft/vscode/issues/197773 </ins> filterMatches.sort((a, b) => { if (a.matchType !== b.matchType) { // Sort by match type if the match types are not the same.

Related discussion:
text: Pinging authors of the issues above along with those who I have seen express interest in reverting the behaviour:
Another idea I have rather than doing a full revert is to use table of contents order as a last resort sorting key for the keyword matches. Therefore, keyword matches in the title could come before keyword matches in the description, and the settings that all have a description-only keyword match could be sorted amongst themselves by table of contents order. With this concept, some extension settings could preserve their order, but an extension setting found by keyword matching would still always come before an extension setting found by a similarity algorithm.
To revert the search results in the Settings editor to order by keyword matches first in the Visual Studio Code extension, you can follow these steps Open the Settings editor: You can do this by pressing the Ctrl+, (Windows, Linux) or Cmd+, (macOS) keyboard shortcut, or by clicking on the gear icon in the Activity Bar and selecting "Settings" from the dropdown menu. Search for the "workbench.settings.settingsSearchTocBehavior" setting: In the search bar at the top of the Settings editor, type "workbench.settings.settingsSearchTocBehavior". Change the value of the setting to "hide": Click on the dropdown menu next to the setting and select "hide". This will disable the table of contents ordering and prioritize keyword matches. Restart Visual Studio Code: To apply the changes, you need to restart Visual Studio Code. Once you restart, the search results in the Settings editor will be ordered by keyword matches first.
that behaviour was implemented as part of , and yes, it is a workaround in a sense. This proposal is on ordering results by keyword matches first even when the table of contents is shown.
Try doing this way In the file, add the following property to the contributes section: { "name": "revert-settings-search-to-keyword-matches-first", "version": "1.0.0", "description": "Reverts settings search in the Settings editor to order results by keyword matches first.
Code change:
} } <del> const tocHiddenDuringSearch = this.configurationService.getValue('workbench.settings.settingsSearchTocBehavior') === 'hide'; if (!tocHiddenDuringSearch) { // Sort the settings according to internal order if indexed. if (this.settingsOrderByTocIndex) { filterMatches.sort((a, b) => compareTwoNullableNumbers(a.setting.internalOrder, b.setting.internalOrder)); } return filterMatches; </del> <ins> // The search only has filters, so we can sort by the order in the TOC. if (!this._viewState.query) { return filterMatches.sort((a, b) => compareTwoNullableNumbers(a.setting.internalOrder, b.setting.internalOrder)); </ins> } <del> // The table of contents is hidden during the search. // The settings could appear in a more haphazard order. // Sort the settings according to their score. </del> <ins> // Sort the settings according to their relevancy. // https://github.com/microsoft/vscode/issues/197773 </ins> filterMatches.sort((a, b) => { if (a.matchType !== b.matchType) { // Sort by match type if the match types are not the same.

Related discussion:
text: ", "publisher": "your-name", "categories": ["Settings"], "activationEvents": ["onStartup"], "contributes": { "configuration": { "properties": { "search.settings.sortByKeywordMatchesFirst": { "type": "boolean", "default": true } } } }, "main": "" } the extension's main script file, add the following code: const vscode = require('vscode'); vscode.extensions.onDidChangeConfiguration(() ={ const sortByKeywordMatchesFirst = vscode.workspace.getConfiguration('search').get('settings.sortByKeywordMatchesFirst'); // Update the Settings editor's search sorting algorithm here. });
Since I am coming from , it would be important to me that the order determined by the extension is retained when only " is called (as you also suggested in ). This then serves as a filter for the items in the base order. If you then place a keyword behind it, you can search "smartly" again.
Verification notes: for title bar style should show the setting first no matter what value is set to. for should show the CSS category first, followed by the LESS category, and lastly by the SCSS category.
Code change:
*/ .vscode-light .hljs-function, <del> .vscode-light .hljs-params { </del> <ins> .vscode-light .hljs-params, .vscode-light .hljs-number, .vscode-light .hljs-class  { </ins> color: inherit; }

Related discussion:
text: In Markdown preview with light theme, numbers in code blocks are not clearly distinguishable because of their color. It will be good if a different color can be switched in light theme mode ! It seems that in , the following part may add a switch. Thank you!
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.474 --- <!-- score: 0.457 --- <!-- score: 0.456 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Please share the text of the code along with screenshots
Actually, code itself does't matter this issue. It influences on many kinds of code with numbers.
Hey, I am a new contributor here. I want to give a try on this issue.
Code change:
if [ -n "$RPROMPT" ]; then RPROMPT="$__vsc_prior_rprompt" fi <ins> __vsc_initialized="1" </ins> __vsc_in_command_execution="1" __vsc_command_output_start }

Related discussion:
text: !
updated Insider's and the problem remains
I think this is the same as We will need to always send the exit code and have it get evaluated on the renderer against the extracted command name to fix these problems.
sometimes reproduces on mac
you can check if this is the same issue () by running a command a few times and then when is run if it's a single entry or multiple in the output.
interesting to me that it allows repro on linux/WSL and does so inconsistently on mac. here's linux: !
K, let's try understand this a little better then, that shouldn't happen as the initial history id is 0:
Oh I figured out when it reproes on mac - if you run the same command in a different terminal, then the second and beyond ones don't have an exit code
Running the command again in the terminal where you first ran the command works every time and does not repro on mac. So mac steps are: in terminal 1 - again in terminal 1 - in terminal 2 - Linux: a terminal and run any command - placeholder decoration shown for the first one regardless of exit code
It would be nice to fix this since is the default shell used
Think I see the problem, PR incoming.
Code change:
import * as assert from 'assert'; import { join } from 'path'; <del> import { commands, workspace, window, Uri, ViewColumn } from 'vscode'; </del> <ins> import { commands, workspace, window, Uri, ViewColumn, Range, Position } from 'vscode'; </ins> suite('commands namespace tests', () => {

Related discussion:
text: For
Verify: write an extension that exercises the following APIs by passing in a selection as option and verify the selection is revealed and showing up in the opened editor: command API Provide a property of type to get it. !
Code change:
return candidate; } <del> if (element === document.body) { </del> <ins> if (element === this.scrollableElement.getDomNode() || element === document.body) { </ins> return null; } } while (element = element.parentElement);

Related discussion:
text: I did this on accident, but it took a little effort to figure out how I did it. Drag file from Finder onto Explorer Get scrollbar in Explorer to be visible, like by dragging near the top/bottom of the Explorer The entire explorer becomes highlighted when you hold the file over the scrollbar Drop file onto the scrollbar The entire explorer stays highlighted. It stays highlighted through interacting with the explorer and even switching to another viewlet. Only can be reversed by dragging another file onto the explorer. !
Actually a much easier way to repro is to two-finger scroll while dragging the file to get the scrollbar to appear.
i'm able to reproduce it. will try to fix it
couldn't find where to start. help is appreciated
I gave it a go in this PR:
Code change:
this.emit('change'); } <ins> private static getUpdateChannel(): string { const channel = settings.manager.getValue('update.channel') || 'default'; return channel === 'none' ? null : env.quality; } </ins> private static getUpdateFeedUrl(channel: string): string { <ins> if (!channel) { return null; } </ins> if (platform.isLinux) { return null; }

Related discussion:
text: Users that don't want automatic updates should still be given the opportunity to stay in the same version. ping
Code change:
})); this.prevBtn = this._register(new SimpleButton({ <del> label: NLS_PREVIOUS_MATCH_BTN_LABEL, </del> <ins> label: NLS_PREVIOUS_MATCH_BTN_LABEL + (options.previousMatchActionId ? this._getKeybinding(options.previousMatchActionId) : ''), </ins> icon: findPreviousMatchIcon, onTrigger: () => { this.find(true);

Related discussion:
text: Terminal: <img width="328" alt="image" src=""Editor: <img width="436" alt="image" src=""