jiebi/CodeConvo huggingface dataset:
Code change:
await this._stageChanges(textEditor, [changes[index]]); <del> const firstStagedLine = changes[index].modifiedStartLineNumber - 1; </del> <ins> const firstStagedLine = changes[index].modifiedStartLineNumber; </ins> textEditor.selections = [new Selection(firstStagedLine, 0, firstStagedLine, 0)]; }

Related discussion:
text: VSCode info: Version: 1.75.0-insider Commit: Date: 2022-12-19T05:35:41.089Z (10 hrs ago) Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 21.6.0 Sandboxed: Yes
Code change:
} const config = workspace.getConfiguration('git', Uri.file(this.repository.root)); <del> const fetchBeforeCheckout = config.get<boolean>('fetchBeforeCheckout', false) === true; </del> <ins> const pullBeforeCheckout = config.get<boolean>('pullBeforeCheckout', false) === true; </ins> <del> if (fetchBeforeCheckout) { </del> <ins> if (pullBeforeCheckout) { </ins> await this.repository.fastForwardBranch(this.ref.name!); }

Related discussion:
text: Testing The feature is called . But it does more than fetch, it also pulls. Fetch typically only 'downloads' commits, but does not update any branches. Maybe the proper name would be:
Code change:
export function keybindingForAction(id: string): Keybinding { switch (id) { <del> case GlobalNewFileAction.ID: </del> <ins> case GlobalNewUntitledFileAction.ID: </ins> return new Keybinding(KeyMod.CtrlCmd | KeyCode.KEY_N); case TriggerRenameFileAction.ID: return new Keybinding(isMacintosh ? KeyCode.Enter : KeyCode.F2);

Related discussion:
text: VSCode Version: 1.0.0 OS Version: OSX 10.11.3 I noticed that we can set to a keybinding. Which creates a nice input field in the sidebar to create the directory at the current selected position. ! But there is no possibility to do this for a file. Yes you can bind but it does not do the same thing. It just creates a new and when pressing <kbdcmd</kbd+ <kbds</kbdyou have to choose the destination in a picker. So, is it possible to add something for a new file as well? It would really improve my speed because I don't have to touch my mouse anymore to create a new named file in a specific directory.
sounds like a good example for a PR?
Yes I looked into it but to be honest, I have to clue where to start :). So if you can point me in the right direction, I would be very happy to do one :).
I would start by fulltext search for the action id () and that brings you here: From there you can get a feeling how this global action works and maybe add the new one. You will also see the one on top for creating an untitled file (which is not what you want). When you find the references of that action you will see where it is being registered to the system:
Alright, awesome. Thank you very much Will see what I can do :).
Code change:
} .merge-editor-block:not(.handled):not(.focused) { <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledUnfocused-border); </ins> } .merge-editor-block:not(.handled).focused { <del> border: 1px dashed var(--vscode-mergeEditor-conflict-unhandledFocused-border); </del> <ins> border: 1px solid var(--vscode-mergeEditor-conflict-unhandledFocused-border); </ins> } .merge-editor-block.handled:not(.focused) {

Related discussion:
text: ! The highlighting is important to understand which conflict in the bottom view corresponds to which conflicts in result. I think the change of the color of the dashed border is difficult to notice.
Code change:
collapseByDefault: true, expandOnlyOnTwistieClick: true, multipleSelectionSupport: false, <ins> showNotFoundMessage: false </ins> } ); }

Related discussion:
text: Type: <bBug</ba file for which a DocumentSymbolProvider will return some items, for example on the filename in the breadcrumb, then type Ctrl/Cmd+F. The list filter widget looks OK, though it hides the first filename in the list ( ought to help with this once merged). the same but one item to the right in the breadcrumb. The filter widget is transparent. ! VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-22T05:16:19.478Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: Yes <!-- generated by issue reporter --
/assign
Easier steps: <kbdCtrl F</kbdon an outline breadcrumb
I still see this. It looks like the background of the find widget gets removed, but the contents still scroll up out of the breadcrumbs widget
Did you test this in dev? Because we still didn't get an Insiders build with the fix.
Code change:
collapseByDefault: true, expandOnlyOnTwistieClick: true, multipleSelectionSupport: false, <ins> showNotFoundMessage: false </ins> } ); }

Related discussion:
text: Originally posted by in
This also happens if step 5 is omitted and Search mode is used. The problem seems to be that to put the 'No elements found.' warning message under the find-in-list's input widget a ContextView is created immediately below it. But when find is occurring in a breadcrumb list, that list is itself in a ContextView which gets hidden and cleared immediately before the one for the warning message is shown. The warning message appears in the top left of the VS Code window in a very narrow column. See below, where I open , click on the filename in the breadcrumb to get a list of sibling filenames, then type "z" which isn't present in any of the filenames. !
Code change:
return this.sendAllBreakpoints(); } <del> addBreakpoints(uri: uri, rawBreakpoints: IBreakpointData[]): TPromise<IBreakpoint[]> { </del> <ins> addBreakpoints(uri: uri, rawBreakpoints: IBreakpointData[], context: string): TPromise<IBreakpoint[]> { </ins> const breakpoints = this.model.addBreakpoints(uri, rawBreakpoints); breakpoints.forEach(bp => aria.status(nls.localize('breakpointAdded', "Added breakpoint, line {0}, file {1}", bp.lineNumber, uri.fsPath))); <ins> breakpoints.forEach(bp => this.telemetryDebugAddBreakpoint(bp, context)); </ins> return this.sendBreakpoints(uri).then(() => breakpoints); }

Related discussion:
text: When going over our telemetry for debug actions we have the ability to track usage counts of debug actions triggered from keyboard shortcuts and commands, as they execute commands which we emit telemetry for, but we don't seem to have telemetry in place for breakpoints set in the gutter (click or context menu). This is unfortunate as my hypothesis is that the majority of breakpoints are set this way. Ask Add ability to track breakpoint toggles (add/remove/change) from Gutter click Add ability to track breakpoint toggles from gutter context menu
would you like to contribute a PR for this? It shuold be fairly simple and you already have the nice code pointers.
I'd be happy too, but we should land on an agreement on how to implement it. What's the best approach? 1) Add telemetry directly to the gutter actions 2) Re-wire the gutter actions to execute a command instead?
for the best approach let's first see what you want to get exactly? total amount of all breakpoints set (including the gutter) grained events for breakpoint setting based on the way the user initated that aciton In case of 1 we should just add a telemetry ping in the  since everyone should go through there In case of 2 depends on how fine grained you want it, if for every place then we should add an argument or something like that in the addBreakpoints method and then also report that to telemetry.
I'd like us to be able to contribute a source/initiator to given breakpoint, so we can get an UI usage distributions, etc.
I suggest the following Add a third argument In the implementation of that method use the telemetry service to report the appropriate event with the context. And you should nicely get all the errors of all the callers of , simply pass different string context for each caller and you shuold be good to go. Let me know if you have any questions
Cool, I'l see what I can get cooking!
Removing my assignment for this. feel free to assign me back if you do not have time to tackle this and if we need this for August
hey, would you still like this? If yes I can also look into it in October
I'd still like to do this to get my hands dirty.
cool, unasigning myself and let's leave it for October
Verified by code review, adding verified label
Code change:
export const listInactiveFocusOutline = registerColor('list.inactiveFocusOutline', { dark: null, light: null, hc: null }, nls.localize('listInactiveFocusOutline', "List/Tree outline color for the focused item when the list/tree is inactive. An active list/tree has keyboard focus, an inactive does not.")); export const listHoverBackground = registerColor('list.hoverBackground', { dark: '#2A2D2E', light: '#F0F0F0', hc: null }, nls.localize('listHoverBackground', "List/Tree background when hovering over items using the mouse.")); export const listHoverForeground = registerColor('list.hoverForeground', { dark: null, light: null, hc: null }, nls.localize('listHoverForeground', "List/Tree foreground when hovering over items using the mouse.")); <del> export const listDropBackground = registerColor('list.dropBackground', { dark: listFocusBackground, light: listFocusBackground, hc: null }, nls.localize('listDropBackground', "List/Tree drag and drop background when moving items around using the mouse.")); </del> <ins> export const listDropBackground = registerColor('list.dropBackground', { dark: '#062F4A', light: '#D6EBFF', hc: null }, nls.localize('listDropBackground', "List/Tree drag and drop background when moving items around using the mouse.")); </ins> export const listHighlightForeground = registerColor('list.highlightForeground', { dark: '#0097fb', light: '#0066BF', hc: focusBorder }, nls.localize('highlight', 'List/Tree foreground color of the match highlights when searching inside the list/tree.')); export const listInvalidItemForeground = registerColor('list.invalidItemForeground', { dark: '#B89500', light: '#B89500', hc: '#B89500' }, nls.localize('invalidItemForeground', 'List/Tree foreground color for invalid items, for example an unresolved root in explorer.')); export const listErrorForeground = registerColor('list.errorForeground', { dark: '#F88070', light: '#B01011', hc: null }, nls.localize('listErrorForeground', 'Foreground color of list items containing errors.'));

Related discussion:
text: There is no drop hover feedback in the Explorer, for example, when in Light+ theme.
Broken by:
Code change:
"@vscode/windows-mutex": "^0.5.0", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2", "jschardet": "3.1.3",

Related discussion:
text: <!-- 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. After updating to VS Code 1.92, I noticed several scroll-related issues with the integrated terminal: exiting a full screen CLI app ( or ), sometimes scroll up or down doesn't work anymore until I press cmd+c - at which point I am teleported back to the start of the cli log. See the below video: start scroll works (though way too sensitive - see issue 2) press scroll up down no longer works press as soon as I try to scroll again, I am teleported to the top of the cli log output (though, at least scroll works after that)Note, while the above triggers the issue, sometimes the issue also occurs even without that (at one point I just run and this bug was triggered) full-screen CLI apps (, , ), the scroll sensitivity is way higher than when scrolling in non-full-screen apps. This scroll sensitivity is uncomfortably high, way higher than it was before, and remains high even if I set to a very low value like 0.1. scrolling through full-screen CLI app ( or ), sometimes the terminal will not let me scroll up. If I try to scroll up, I am "teleported" back to previous position. As soon as I scroll down, I can't scroll back up to the previous text. <!-- 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. --Relevant information: VS Code Version: 1.92 OS Version: macOS 14.5 Issues are reproducible in ZSH.
Code change:
"@vscode/windows-mutex": "^0.5.0", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2", "jschardet": "3.1.3",

Related discussion:
text: I was also able to trigger issue 1 in BASH In ZSH, I am using oh-my-zsh and powerlevel19k, BUT I was able to reproduce the issues even after I temporary disabled oh-my-zsh and powerlevel19k in my Issues are reproducible even if I start VS Code with empty user dir and empty extensions dir. A few relevant settings: is off. Enabling it does not make things better N/A as I am not holding the key - I am just scrolling using the touchpad is off. Enabling it did not make things better I am sorry if some of the above reproduction steps a bit vague - some of these don't happen each time so it's hard to see what triggered it. But these all started happening as soon as VS Code got updated to 1.92. I will keep updating this issue if I have more details. <details<summarySystem info</summaryGeneral: System info: System Information | -- | -- CPUs | Apple M1 Pro (10 x 2400) GPU Status | 2dcanvas: enabled canvasooprasterization: enabledon directrenderingdisplaycompositor: disabledoffok gpucompositing: enabled multiplerasterthreads: enabledon opengl: enabledon rasterization: enabled rawdraw: disabledoffok skiagraphite: disabledoff videodecode: enabled videoencode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off Load (avg) | 2, 2, 3 Memory (System) | 32.00GB (6.06GB free) Process Argv | /Users/mak13180/site/esri/arcgis-web-components --crash-reporter-id -0746-4857-a17b- Screen Reader | no VM | 0% Enabled extensions (BUT, issues are reproducible with all extensions disabled): Extension Version -- -- vite 0.2.5 shell-syntax 1.0.5 vscode-tailwindcss 0.12.5 vscode-eslint 3.0.10 apc-extension 0.4.1 gitlens 15.2.3 vscode-html-css 2.0.10 prettier-vscode 10.4.0 lintlens 7.5.0 copilot 1.219.0 copilot-chat 0.18.1 vscode-github-actions 0.26.
Code change:
"@vscode/windows-mutex": "^0.5.0", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2", "jschardet": "3.1.3",

Related discussion:
text: 3 vscode-pull-request-github 0.92.0 gc-excelviewer 4.2.59 todo-tree 0.0.226 search-node-modules 1.3.0 nodejs-repl 0.5.15 rainbow-csv 3.12.0 remote-ssh 0.112.0 remote-ssh-edit 0.86.0 remote-explorer 0.4.3 vscode-css-peek 4.4.1 vscode-yaml 1.15.0 code-spell-checker 3.0.1 vscode-stylelint 1.4.0 vscode-mdx 1.8.9 vscodeintellicode 1.3.1 explorer 1.0.6 vim 1.27.3 pretty-ts-errors 0.6.0 markdown-all-in-one 3.6.2 A/B experiment info: My (BUT, issues are also reproducible when VS Code is started with empty user dir): The log when VS Code is started as : </details
Upstream PR fixing it
Code change:
import { ContextScopedFindInput } from 'vs/platform/history/browser/contextScopedHistoryWidget'; import { widgetClose } from 'vs/platform/theme/common/iconRegistry'; import * as strings from 'vs/base/common/strings'; <del> import { TerminalCommandId } from 'vs/workbench/contrib/terminal/common/terminal'; </del> import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { showHistoryKeybindingHint } from 'vs/platform/history/browser/historyWidgetKeybindingHint'; import { status } from 'vs/base/browser/ui/aria/aria';

Related discussion:
text: Terminal: <img width="328" alt="image" src=""Editor: <img width="436" alt="image" src=""
Code change:
import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; import { AccessibilityVerbositySettingId, accessibilityHelpIsShown, accessibleViewIsShown } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; import { ILayoutService } from 'vs/platform/layout/browser/layoutService'; <del> import { Action2, MenuId } from 'vs/platform/actions/common/actions'; </del> <ins> import { Action2, MenuId, registerAction2 } from 'vs/platform/actions/common/actions'; </ins> import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry';

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._resourceContentProvider.deleteAndDispose(handle); } <del> $onVirtualDocumentChange(uri: UriComponents, value: string): void { </del> <ins> async $onVirtualDocumentChange(uri: UriComponents, value: string): Promise<void> { </ins> const model = this._modelService.getModel(URI.revive(uri)); if (!model) { return;

Related discussion:
text: Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.2 OS Version: Windows 10 It seems that when refreshing () the in a short period, the second refresh is not actually performed. I have provided an example repo and a video demonstrating the issue. Basically we have a that shadows the active editor so whenever a user changes the active editor we update the read only document. However, if the user changes the editors quickly enough then the second change is dropped... Steps to Reproduce: the extension the command "Open Read Only Document" tabs quickly and see how it falls behind even though the content is up to date https://user- The content is actually set but it seems the second is dropped. Because if you refresh the document manually it shows the correct content (see the video above). The issue seems to happen more frequently if the content of the file(s) is large.
I found out why it happens and attempted a fix (with explanation) in
Pinging so it does not get lost