jiebi/CodeConvo huggingface dataset:
Code change:
} let index: number; <del> if (this.editor.hasModel() && (typeof lineNumber === 'number')) { </del> <ins> if (this.editor.hasModel() && (typeof lineNumber === 'number' || !this.widget.provider)) { </ins> index = this.model.findNextClosestChange(typeof lineNumber === 'number' ? lineNumber : this.editor.getPosition().lineNumber, true, this.widget.provider); } else { const providerChanges: number[] = this.model.mapChanges.get(this.widget.provider) ?? this.model.mapChanges.values().next().value;

Related discussion:
text: Open a file with multiple changed regions in git Move cursor inside/next to some change Run "Show Next Change" (alt+f3) It reveals and shows a different change- I think it always shows the last one in the editor. It should show the next one after the cursor position I can press it multiple times to cycle through changes, and that's correct, but it always starts with the last change
I'd like to fix this for April, but it looks like the change could be risky. I will fix it for May.
Found a low risk fix.
This works, thanks! But one thing that my muscle memory is unsure about, did this command previously move the cursor? I'm noticing that if I press it multiple times, then press escape, the view moves back to the place where I started, when I'm expecting this to be like a "navigate" action. I can open a new issue, or if it's always worked like this, it's fine
I went back to 1.74 to check, and it didn't move the cursor there. "Go to Next Change" will move the cursor though.
Code change:
**/extensions/markdown-language-features/notebook-out/** **/extensions/typescript-basics/test/colorize-fixtures/** **/extensions/**/dist/** <ins> **/extensions/typescript-language-features/test-workspace/** </ins>

Related discussion:
text: Currently, we have to add this copyright header manually to every new file: /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ An ES Lint rule that has an auto fix would be really nice. What are your thoughts ! (using )
I like. The closest that we have today is this snippet
Let's do it!
Code change:
updateOptions(newOptions: Partial<NotebookViewModelOptions>) { this._options = { ...this._options, ...newOptions }; <ins> this._viewCells.forEach(cell => cell.updateOptions({ readonly: this._options.isReadOnly })); </ins> this._onDidChangeOptions.fire(); }

Related discussion:
text: Type: <bBug</bDelete a notebook file in a git repo Open it from the SCM view It's editable ;( VS Code version: Code - Insiders 1.94.0-insider (Universal) (, 2024-09-11T05:04:03.124Z) OS version: Darwin arm64 23.6.0 Modes: <!-- generated by issue reporter --
Fixed by
Code change:
dropdownActions.push(new SubmenuAction('split.profile', localize('splitTerminal', 'Split Terminal'), submenuActions)); dropdownActions.push(new Separator()); } <del> for (const [, configureActions] of dropdownMenu.getActions()) { for (const action of configureActions) { // make sure the action is a MenuItemAction if ('alt' in action) { dropdownActions.push(action); } } } </del> <ins> const actions = dropdownMenu.getActions(); dropdownActions.push(...Separator.join(...actions.map(a => a[1]))); </ins> const defaultSubmenuProfileAction = submenuActions.find(d => d.label.endsWith('(Default)')); if (defaultSubmenuProfileAction) {

Related discussion:
text: Could look like this, but have and/or tasks entries as well as a one. Hiding it by default is a good way to avoid cluttering the action bar - so people only see it if they want to <img width="285" alt="Screen Shot 2022-09-30 at 12 56 57 PM" src="https://user-"
cc
Talked w Kai and we're thinking to instead add a action to the terminal dropdown which aligns with the menu and will aid in discoverability !
Code change:
"@vscode/vscode-languagedetection": "1.0.21", "@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> "cookie": "^0.4.0", "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2",

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/vscode-languagedetection": "1.0.21", "@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> "cookie": "^0.4.0", "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2",

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/vscode-languagedetection": "1.0.21", "@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> "cookie": "^0.4.0", "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2",

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:
readonly allowEditorOverflow = true; private readonly domNode = document.createElement('div'); <del> private readonly elements = h('.editor-dictation-widget@main', [h('span@mic')]); constructor(private readonly editor: ICodeEditor) { </del> <ins> constructor(private readonly editor: ICodeEditor, keybindingService: IKeybindingService) { </ins> super(); <del> this.domNode.appendChild(this.elements.root); this.domNode.style.zIndex = '1000'; reset(this.elements.mic, renderIcon(Codicon.micFilled)); </del> <ins> const actionBar = this._register(new ActionBar(this.domNode)); const stopActionKeybinding = keybindingService.lookupKeybinding(EditorDictationStopAction.ID)?.getLabel(); actionBar.push(toAction({ id: EditorDictationStopAction.ID, label: stopActionKeybinding ? localize('stopDictationShort1', "Stop Dictation ({0})", stopActionKeybinding) : localize('stopDictationShort2', "Stop Dictation"), class: ThemeIcon.asClassName(Codicon.micFilled), run: () => EditorDictation.get(editor)?.stop() }), { icon: true, label: false, keybinding: stopActionKeybinding }); this.domNode.classList.add('editor-dictation-widget'); this.domNode.appendChild(actionBar.domNode); </ins> } getId(): string {

Related discussion:
text: Testing My first reaction for how to stop dictation in the editor was to click the flashing microphone. It would be cool if something happened when the flashing microphone is clicked.
I will turn this into a real with action and hover.
Code change:
setTimeout(() => { dom.addClass(this._innerDomNode, 'visible'); <ins> dom.addClass(this._innerDomNode, 'visible-transition'); </ins> this._innerDomNode.setAttribute('aria-hidden', 'false'); setTimeout(() => { this._findInput.select();

Related discussion:
text: Microsoft/vscode Repro: PR ext description page something, shift+tab until you hit the start of the screen There are 4 focusable items, close, next match, previous match and the find input.
Would you like me to start on this?
Yes please. It is too late to get a fix in for the January VS Code release but you can submit a PR any time and we'll try to get this fixed for February
LOL ... my Dragon dictation did the equivalent of a butt dial , deleted assignments and pasted an eMoji sorry about that :-P
FYI: started on this and I can reproduce and see it. simpleFind transitions in and out with animation, hidden only because of z-index and/or overflow. The widget always has display type:flex , therefore the four tabs stops for the buttons and input are always in the tabIndex order fix should be simple, however, there is an interaction between the animation and the display mode such that simultaneously going from display:none =flex messes up the animation. I'm working on separating the display mode from the transition to see if that will work. I have to do more experiments , May have a question or two later...
See PR: Verification: Use a screen reader with screen output on so you can see and track each tab stop Open the new pull request extension page Click on the upper pane to begin focus there Tab through the various toolbar buttons , after dependencies the next tab SHOULD land on With the webview not the simpleFind widget. Verify showing and hiding simpleFind has smooth animation as before Note: When focuses on bottom for web view pane , screen readers output a bunch of base64 encoded text (see truncated output lines below). But I think this is an accessibility bug, if you guys agree I'll post an issue. NVDA Output: with visibility fix (correct output, no tab stops within the hidden simpleFind) NVDA Output: original scenario without fix (can see tabs stops in widget)
Code change:
} rawUpdate(data: IRawModelUpdate): void { <ins> const threadIds: number[] = []; </ins> data.threads.forEach(thread => { <ins> threadIds.push(thread.id); </ins> if (!this.threads.has(thread.id)) { // A new thread came in, initialize it. this.threads.set(thread.id, new Thread(this, thread.name, thread.id));

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.35.1 (also tried current 1.36.0-insider) OS Version: Ubuntu 18.04 VSCode's view seems to show all threads that ever existed, not just the ones returned by latest request. Repro: and run mock-debug extension from this branch: the folder and start configuration. all threads in the thread list and start stepping line by line. After each step the adapter will reduce the number of active threads by one. requests for invalid thread ids will be failed. By line 5, there will be only one thread remaining, yet VSCode tries to display all 5.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.586 --- <!-- score: 0.462 --- <!-- score: 0.461 --- <!-- score: 0.461 --<!-- potentialduplicatescomment --
make sure that only the threads returned by the last thread request (plus additional threads coming reported via the "thread" event) are shown.
thanks for the nice repo steps. I have changed that we now always respect the request as the absolute truth. So if a thread is not returned as part of the response we will delete it. I have created a PR which tackles this and I will merge this PR in next week since now we are in endgame and I would like to get more insiders coverage so we catch potential extensions which might rely on the current bugy behavior.
Code change:
} } <del> private notifyOnAppRootEditors(appRootUri: URI): void { const resourceUri = EditorResourceAccessor.getOriginalUri(this.editorService.activeEditor, { supportSideBySide: SideBySideEditor.BOTH }); const isResourceAppRootedFn = (uri: URI): boolean => this.uriIdentityService.extUri.isEqualOrParent(uri, appRootUri); let isResourceAppRooted = false; if (URI.isUri(resourceUri)) { if (isResourceAppRootedFn(resourceUri)) { isResourceAppRooted = true; } } else if (resourceUri) { if (resourceUri.primary && isResourceAppRootedFn(resourceUri.primary)) { isResourceAppRooted = true; } else if (resourceUri.secondary && isResourceAppRootedFn(resourceUri.secondary)) { isResourceAppRooted = true; } } // It is dangerous to edit files in the installation directory of Code because // an update will remove all files and replace them with the new version. // As such, we notify the user whenever an editor opens that is located somewhere // in the installation directory. // https://github.com/microsoft/vscode/issues/138815 if (isResourceAppRooted) { this.notificationService.prompt( Severity.Warning, localize('notifyOnAppRootEditors', "Files within the installation folder of '{0}' ({1}) will be OVERWRITTEN or DELETED IRREVERSIBLY without warning during a future update.", this.productService.nameShort, this.environmentService.appRoot), [{ label: localize('understood', 'Understood'), run: async () => { // Nothing to do } }], { neverShowAgain: { id: 'window.notifyOnAppRootEditors', isSecondary: true }, sticky: true } ); } } </del> private onAddFoldersRequest(request: IAddFoldersRequest): void { // Buffer all pending requests

Related discussion:
text: a JS file: to definition on Bug I see this scary notification: <img width="671" alt="Screen Shot 2022-07-26 at 2 31 10 PM" src="https://user-"In this case, the user was likely just trying to view the file Would it be possible to either: show this notification when saving? open these file as ?
This came in via from and I think is not good. This also reminds me that when debugging you may end up in a file from the installation dir. I think we should probably revert the change for now and think about a better solution unless there are objections.
I agree. Maybe pursue your earlier suggestion of opening all installation directory files in readonly mode. Perhaps combine with a scary warning if you save a new file in there.
Code change:
import { IStorageService, StorageScope, StorageTarget } from '../../../../platform/storage/common/storage.js'; import { INotificationService } from '../../../../platform/notification/common/notification.js'; import { IExtensionService } from '../../../services/extensions/common/extensions.js'; <ins> import { groupBy as groupBy2 } from '../../../../base/common/collections.js'; </ins> const PICK_REPOSITORY_ACTION_ID = 'workbench.scm.action.graph.pickRepository'; const PICK_HISTORY_ITEM_REFS_ACTION_ID = 'workbench.scm.action.graph.pickHistoryItemRefs';

Related discussion:
text: Testing I wonder how well it scales to show multiple tag icons, why not find a new icon that resembles multiple tags: !
I like that. Adding as that would require a new Codicon...
!
Or just show one tag in the row, but show all of them on hover like you do now.
How about showing one badge pert type (ex: branch, remote branch, tag) and a number indicating how many they are. That way there is no need create new icons that would cause further confusion.
I am actually not entirely sure what value there is to distinguish 1 tag from N tags? I would just show 1 icon if there is any tag.
Seems reasonable. Let's start with that and see how things go.
Code change:
if (exitCode) { this._xterm.writeln(exitCodeMessage); } <del> let message = typeof this._shellLaunchConfig.waitOnExit === 'string' ? this._shellLaunchConfig.waitOnExit : nls.localize('terminal.integrated.waitOnExit', 'Press any key to close the terminal'); // Bold the message and add an extra new line to make it stand out from the rest of the output message = `nx1b[1m${message}x1b[0m`; this._xterm.writeln(message); </del> <ins> if (typeof this._shellLaunchConfig.waitOnExit === 'string') { let message = this._shellLaunchConfig.waitOnExit; // Bold the message and add an extra new line to make it stand out from the rest of the output message = `nx1b[1m${message}x1b[0m`; this._xterm.writeln(message); } </ins> // Disable all input if the terminal is exiting and listen for next keypress this._xterm.setOption('disableStdin', true); if (this._xterm.textarea) {

Related discussion:
text: VSCode Version: 1.27.1 OS Version: Windows 10 (Build ) Steps to Reproduce: a simple (build) task setting presentation.showReuseMessage to false the task a blank line where the reuse message used to show up, instead of no extra line displayed at all Does this issue occur when all extensions are disabled?: Yes I was expecting this setting to reduce the overall lines printed by running the task, but all it does is prints an empty line instead of removing the line completely.
Able to reproduce.
I currently set . I can't simply set it to false since this would close the terminal. Any advice how to avoid the blank line?
I guess you want to pass in and handle it here:
OK. I will change the code as follows: if waitOnExit is a boolean honor it and never print a message if it is a string wait and print the provided message. Is this OK for you ?
Code change:
.monaco-editor .view-ruler { position: absolute; top: 0; <ins> --box-shadow-color: rgba(0, 0, 0, 0); box-shadow: 1px 0 0 0 var(--box-shadow-color) inset; </ins> }  No newline at end of file

Related discussion:
text: The rulers and indent guides do not display well on high pixel density displays VSCode Version: Version 1.21.0 (1.21.0) OS Version: macOS Sierra 10.12.6 (16G1212) Steps to Reproduce: out editor Does this issue occur when all extensions are disabled?: Yes Example !
Code change:
cursor: pointer; color: white; flex: 1; <ins> white-space: nowrap; overflow: hidden; } .colorpicker-header .picked-color .picked-color-presentation { white-space: nowrap; margin-left: 5px; margin-right: 5px; </ins> } .colorpicker-header .picked-color .codicon { color: inherit; font-size: 14px; <del> position: absolute; left: 8px; </del> } .colorpicker-header .picked-color.light {

Related discussion:
text: When the content hover contains a color picker and it is resized too small, the text and the color picker box overflow. Perhaps the text should disappear when there is not enough space for the text.
At least the text does not wrap to the next line anymore, but imho the text should remain visible for as long as possible and could possibly also have text-overflow: ellipses? <img width="153" alt="image" src=""
Hi thanks for your comment. The following PR which was merged yesterday should set a minimum width on the content hover when a color picker is embedded and resolve the issue. The fix should appear in today's insiders with commit number
Indeed, thanks!