jiebi/CodeConvo huggingface dataset:
Code change:
export function restoreRecentlyOpened(data: RecentlyOpenedStorageData | undefined, logService: ILogService): IRecentlyOpened { const result: IRecentlyOpened = { workspaces: [], files: [] }; if (data) { <del> const restoreGracefully = function <T>(entries: T[], func: (entry: T, index: number) => void) { </del> <ins> const restoreGracefully = function <T>(entries: T[], onEntry: (entry: T, index: number) => void) { </ins> for (let i = 0; i < entries.length; i++) { try { <del> func(entries[i], i); </del> <ins> onEntry(entries[i], i); </ins> } catch (e) { logService.warn(`Error restoring recent entry ${JSON.stringify(entries[i])}: ${e.toString()}. Skip entry.`); }

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/No Yes <!-- 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. --- VS Code Version: 1.71.2 (user setup) OS: Windows_NT x64 10.0. CPU: i5- Run command and pick a invalid uri (e.g. path doesn't exist) when having "large" (like a few hundreds) amount of recent history entries, vscode will freeze for a few seconds !
By the way, having "large" amount of recent history entries will also slow down the start up time (both vscode start up and open file time) for a few seconds as well, just tested that with out any history with a few hundreds
thanks for testing that, do you recall how you got into this state of having many entries? Just by opening folders and files that contribute to the history? If you could do me a favor: open the command palette run the command "Log Storage Database Contents" run command "Toggle Developer Tools" click on "Console" expand the first "Storage..." output that is printed there find the entry (see picture below) how many entries do you see? <img width="1005" alt="image" src="https://user-"
Total of 671 entries, most of them are temp files opened from things like MobaXterm and !
Got it, we do have a limit of 500 entries when presented, but I still have to understand the performance issue. You could actually help out by doing a performance trace yourself when this happens by starting performance tracing before invoking the time consuming action and stopping right after.
Code change:
export function restoreRecentlyOpened(data: RecentlyOpenedStorageData | undefined, logService: ILogService): IRecentlyOpened { const result: IRecentlyOpened = { workspaces: [], files: [] }; if (data) { <del> const restoreGracefully = function <T>(entries: T[], func: (entry: T, index: number) => void) { </del> <ins> const restoreGracefully = function <T>(entries: T[], onEntry: (entry: T, index: number) => void) { </ins> for (let i = 0; i < entries.length; i++) { try { <del> func(entries[i], i); </del> <ins> onEntry(entries[i], i); </ins> } catch (e) { logService.warn(`Error restoring recent entry ${JSON.stringify(entries[i])}: ${e.toString()}. Skip entry.`); }

Related discussion:
text: The steps are outlined here:
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified
Thanks!
Code change:
} getAriaLabel(element: ListElement): string | null { <del> return element.saneAriaLabel; </del> <ins> return element.separator?.label ? `${element.saneAriaLabel}, ${element.separator.label}` : element.saneAriaLabel; </ins> } getWidgetRole() {

Related discussion:
text: A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Visual Studio Code Client; #BM-VisualStudioCode-Win32-Nov2021; #Win32; #Narrator; #NVDA; #ScreenReader; #WCAG4.2.5 #AINotInScope; #FTP; #STP; Application Name: Visual Studio Code Client Windows Version: Windows 11 1)Turn on Narrator/NVDA. 2)Open Visual studio code editor. 3)Open the command Pallet by pressing "F1" key and type "Theme" 4)Using Down arrow key select "Preference color Theme" and press enter key to select. 5)Using "Up/Down" arrow key select different available theme. 6)verify that screen reader is announcing the associated label for the 'recently used' and 'Other commands' or not. Screen reader does not announce associated label for the 'recently used' and 'Other commands'.. Screen reader should announce the associated label for the 'recently used' and 'Other commands'. Screen Reader users will not get the complete information about the controls. !
The issue here is that the group label "recently used" does not get read. I suggest to append the group name to the aria label of the first element in the quick pick that belongs to that group. I think it should be a low hanging fix.
Code change:
<array> <dict> <key>begin</key> <del> <string>/**</string> </del> <ins> <string>/**(?!/)</string> </ins> <key>captures</key> <dict> <key>0</key>

Related discussion:
text: VSCode Version: Code 1.12.2 (, 2017-05-10T13:20:36.315Z) OS Version: Windows_NT ia32 10.0. Steps to Reproduce: "JSON" file Expected outcome styled as (invalid) content token. Actual outcome styled as comment. Still properly marked as invalid, though. Remarks is OK. Same steps in JavaScript file is OK. ! Ad "JSON" in quotation marks: .
Code change:
const others = distinct([ ...Object.keys(this._exeBasedRecommendations), ...this._dynamicWorkspaceRecommendations, <del> ...Object.keys(this._experimentalRecommendations)]); </del> <ins> ...Object.keys(this._experimentalRecommendations), ]); </ins> shuffle(others); <del> return others.map(extensionId => { const sources: ExtensionRecommendationSource[] = []; if (this._exeBasedRecommendations[extensionId]) { sources.push('executable'); } if (this._dynamicWorkspaceRecommendations[extensionId]) { sources.push('dynamic'); } return (<IExtensionRecommendation>{ extensionId, sources }); }); </del> <ins> return [ ...this.getRestoredRecommendationsByReason(ExtensionRecommendationReason.Executable), ...this.getRestoredRecommendationsByReason(ExtensionRecommendationReason.DynamicWorkspace), ...this.getRestoredRecommendationsByReason(ExtensionRecommendationReason.Experimental), ...others] .map(extensionId => { const sources: ExtensionRecommendationSource[] = []; if (this._exeBasedRecommendations[extensionId]) { sources.push('executable'); } if (this._dynamicWorkspaceRecommendations[extensionId]) { sources.push('dynamic'); } if (this._sessionRestoredRecommendations[extensionId.toLowerCase()]) { sources.push(...this._sessionRestoredRecommendations[extensionId.toLowerCase()].sources); } return (<IExtensionRecommendation>{ extensionId, sources }); }); </ins> }); } <ins> private getRestoredRecommendationsByReason(reason: ExtensionRecommendationReason): string[] { return Object.keys(this._sessionRestoredRecommendations).filter(key => this._sessionRestoredRecommendations[key].reasonId === reason); } </ins> getKeymapRecommendations(): IExtensionRecommendation[] { return (product.keymapExtensionTips || []).map(extensionId => (<IExtensionRecommendation>{ extensionId, sources: ['application'] })); }

Related discussion:
text: Issue Type: <bBug</bOpen extension recommendations Click on one In the editor, click the ignore recommendation button Note that the extension is removed from the recommended extension list as expected Click on the undo button in the editor Note that the recommended extension is not placed back in the list. VS Code version: Code - Insiders 1.25.0-insider (, 2018-06-26T05:18:23.085Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ html-snippets0.2.1 jshint0.10.19 vscode-eslint1.4.12 tslint1.0.33 vscode-great-icons2.1.35 vscode-gutter-preview0.12.2 vscode-azureappservice0.8.1 vscode-cosmosdb0.7.2 azure-account0.4.1 csharp1.15.2 vs-keybindings0.2.0 team1.136.0 debugger-for-chrome4.7.0 addDocComments0.0.8 cordova-tools1.4.0 </details<!-- generated by issue reporter --! Testing:
Note: this only applies to non-workspace recommendations. Will look into
Closed with
Code change:
id: MenuId.NotebookCellTitle, when: ContextKeyExpr.and(NOTEBOOK_EDITOR_FOCUSED, NOTEBOOK_EDITOR_EDITABLE, NOTEBOOK_CELL_EDITABLE), group: CellOverflowToolbarGroups.Copy, <ins> order: 1, </ins> }, keybinding: platform.isNative ? undefined : { when: ContextKeyExpr.and(NOTEBOOK_EDITOR_FOCUSED, ContextKeyExpr.not(InputFocusedContextKey)),

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/No <!-- 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. --- VS Code Version: OS Version: Steps to Reproduce: a ntoebook click on a cell, and notice the order of the cell actions same entries for regular editors is All places the order is We might want to consider changing this.
is this a papercut or ux issue I'm concerned that changing this now could result in issues due to muscle memory (i.e. users being used to this order). Thus changing this might not be a good idea, then again, i don't think it is. Thoughts?
discussed with team, Lets change this
Code change:
import { CodeCellViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/codeCellViewModel'; import { URI } from 'vs/base/common/uri'; import { Event } from 'vs/base/common/event'; <ins> import { IChatAgentService } from 'vs/workbench/contrib/chat/common/chatAgents'; </ins> type CellDiagnostic = { cellUri: URI;

Related discussion:
text: There are some parts in notebook land that depend on . This service and its provider are deprecated and should be removed. As of today the following dependencies must be cleaned up first: , , The should be used instead, it will allow you to know if a agent per location exists or not
Code change:
location: ProgressLocation.Notification, title: progressStartEvent.body.title, cancellable: progressStartEvent.body.cancellable, <del> priority: NotificationPriority.SILENT, </del> source, delay: 500 }, progressStep => {

Related discussion:
text: I am writing a debugger adapter. I use ProgressStartEvent/ProgressUpdateEvent/ProgressEndEvent to report some debug opertions' progress information. In previous versions, the progress information was shown in right-bottom corner, however, in 1.86.0, the progress information is shown in status bar instead. I think this is not a good idea, as user might not be able to notice the progress information. If there is a workaround if I still want to show progress information in right-bottom corner of VS code? Thanks! Bill Zhang
I haven't yet found a 1.86 commit that specifically changes this behaviour. Have you perhaps been trying out this new 1.86 feature?
If this is a confirmed regression, it would help to know which change caused it. We maintain a based CLI tool  that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression. Steps: install (if not yet done) follow the instructions until you found the offending build (its fine to leave the commit empty) report back the commit range in this issue Thanks!
The progress information was shown in status bar, not a pop-up window as before versions, so I have no way to enable/disable notification. In addition, notification was shown as before in right-bottom corner.
85 does not have this issue.
If you cannot find the actual commit causing this using , then you need to provide a minimal repro for us to try out.
Code change:
location: ProgressLocation.Notification, title: progressStartEvent.body.title, cancellable: progressStartEvent.body.cancellable, <del> priority: NotificationPriority.SILENT, </del> source, delay: 500 }, progressStep => {

Related discussion:
text: I have tried the vscode-bisect, but it failed: PS C:gitBIOSDBGV4srcextensionnpx --yes --reset [build] deleting cache directory C:UserszhiqzhanAppDataLocalTempvscode-bisect √ Commit of released insiders build that reproduces the issue (leave empty to pick the latest build) ... √ Commit of released insiders build that does not reproduce the issue (leave empty to pick the oldest build) ... [build] fetching all builds from [build] total 171 builds with roughly 7 steps [build] downloading build from [build] unzipping build to C:UserszhiqzhanAppDataLocalTempvscode-bisect.buildsVSCode-win32-x64-1.85.0-insider... [build] starting desktop build ... √ Is good or bad? » Good [build] downloading build from [build] unzipping build to C:UserszhiqzhanAppDataLocalTempvscode-bisect.buildsVSCode-win32-x64-1.86.0-insider... [build] starting desktop build ... √ Is good or bad? » Bad [build] downloading build from [error] Error: read ECONNRESET You can run vscode-bisect --verbose for more detailed output and vscode-bisect --reset for a fresh start without caches.
At first, it is quick in downloading vscode-insider, but later it takes a long time to download it. I am not sure why. !
thanks a lot for trying it though, maybe some connection trouble. I can try it if you tell me how to reproduce.
I create a simple debugger for testing. code: vsix: I am not sure whether you know how to start a debugger or not: 1) install test-debugger- 2) open a empty folder and then create a ! 3) select Debugger For Test ! 4) Start Testing debugger ! 5) You will see progress information in status bar !
If run in 1.85.2, it is as below: !
thanks! Is it possible that you have snoozed notifications either globally or for the extension?
Code change:
location: ProgressLocation.Notification, title: progressStartEvent.body.title, cancellable: progressStartEvent.body.cancellable, <del> priority: NotificationPriority.SILENT, </del> source, delay: 500 }, progressStep => {

Related discussion:
text: You effectively see the same notification but when it appears in the status bar, it means the notification is hiding because of the "Do not disturb mode". When you click the status bar entry you can see how it changes to the notification toast.
Yes, you are right. But even in below setting (BIOSDBG V4 is my extension): ! The notification is hidden unless you click the right-bottom icon. ! I think it makes me confused and it is not easy for user to notice this. Thanks!
There is indeed a change that happened as part of our latest release, but I think for the better: debug had always decided to show notifications for debug progress in the status bar via this directive: A change I did last milestone actually made to support it now: So I am deferring to debug component to further triage, but I think this is actually expected behaviour.
I think we should revert to the old behavior for consistency as that's what users have historically seen
Code change:
import { ICodeEditor } from 'vs/editor/browser/editorBrowser'; import { IEditorOptions } from 'vs/editor/common/config/editorOptions'; import { TextEditorOptions, EditorModel, EditorInput, EditorOptions } from 'vs/workbench/common/editor'; <ins> import { ResourceEditorInput } from 'vs/workbench/common/editor/resourceEditorInput'; </ins> import { BaseTextEditorModel } from 'vs/workbench/common/editor/textEditorModel'; import { UntitledEditorInput } from 'vs/workbench/common/editor/untitledEditorInput'; import { BaseTextEditor } from 'vs/workbench/browser/parts/editor/textEditor';

Related discussion:
text: Start legacy protocol debug session Open something via "Open loaded scripts" scroll down ctrl+tab to switch to another doc ctrl+tab back to the newly opened script It's scrolled up to the top. Is it being closed/opened each time we switch away?
This problem is independent from the "Open Loaded Scripts" feature. To reproduce: debug a simple node hello world program and stop on entry in the CALL STACK select an internal module press Control-Tab twice (to switch between two editors) Observe: you loose the scroll position in the internal module
March to investigate
Workbench is not preserving scroll location of in memory resources. Same is true for diff view. Forwarding to since he probably already has an issue for this
I do but I cannot find it right now, PR welcome.
give me some code pointers for the PR and I can do it in debt week
we do it for and via the and methods that are actually defined in and we could probably push this down from and and just use it from textEditor for any input that has a resource
Ok, makes sense. Assigning to me and April to look into it
Related:
With landed, we keep the UI state when you switch editors, though we clear it when you close a tab. The rationale is that the lifecycle of these editors that have virtual resources is not known, as such we assume the view state can be ditched once the editor closes.
That sounds perfect!
Code change:
const editorOptions = this._configurationService.getValue<IEditorOptions>('editor'); const xterm = new Terminal({ <ins> altClickMovesCursor: config.altClickMovesCursor, </ins> scrollback: config.scrollback, theme: this._getXtermTheme(), drawBoldTextInBrightColors: config.drawBoldTextInBrightColors,

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.46.1 OS Version: Ubuntu 20.04 LTS x86_64 shell: bash When alt-clicking in terminal (e. g. to open a file or URL), it gets filled up with lots of or : ! Steps to Reproduce: integrated terminal (or, for a more practical example, in a temp dir) -click anywhere <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Having the same issue in WSL with Ubuntu 18.04 when alt+clicking any link.
Looks like this is an issue where the alt+click feature (move cursor when clicking) is conflicting with links, only when is used.
This issue also occurs on MacOS, only with Opt+Click instead of Alt+Click. I thought at first that this was related to the Opt+Click on a detected link in the terminal (since that is an Alt+Click on Windows/Linux). But this truly does occur when Opt+Clicking anywhere in the terminal while a command is waiting for input. I can confirm that this occurs on my MacOS regardless of the value of setting.
set in , now the way you click url is cmd + click, and it wont happen again
nope, that only slightly changes the junk that is dumped into the Terminal, but it doesn't get rid of it... With (default): With :
emmm, you say is right, i just change a way to open url in vscode terminal to avoid echo ^[[D but not fix it , this also occurs in , if you use option + click. by the way,my final setting as follows (if , vscode still let you click url with option + click ) !
Oh! That's a great observation, Alt+Click fills the terminal with junk even in the standard MacOS Terminal app and also in iTerm2. Now, I am aware that is originally reporting this for Ubuntu. I checked my Linux laptop (Fedora 31), and Alt+Click in the standard system terminal emulator does nothing. It only occurs in VSCode's terminal.
Code change:
const editorOptions = this._configurationService.getValue<IEditorOptions>('editor'); const xterm = new Terminal({ <ins> altClickMovesCursor: config.altClickMovesCursor, </ins> scrollback: config.scrollback, theme: this._getXtermTheme(), drawBoldTextInBrightColors: config.drawBoldTextInBrightColors,

Related discussion:
text: But this still makes me wonder if all of this is system-level issues, or perhaps terminal "emulator" issues, not really a VSCode issue. Hard to know. But the Microsoft devs would know.
As for your workaround, thank you so much for that!!! I still don't see any change in VSCode's behavior when using , but changing definitely avoids the core issue. I hope you don't mind me describing in more detail... According to , "The Go To Definition and Open Link gestures will also respect this setting and adapt such that they do not conflict. For example, when the setting is ctrlCmd, multiple cursors can be with Ctrl/Cmd+Click, and opening links or going to definition can be invoked with Alt+Click." You probably did what I did when originally installing VSCode... I'm using to using Ctrl+Click in Linux and Cmd+Click in MacOS to multi-select files in Finder, items in a list, etc. So I set to be . However, this means that attempting to click on a link in the terminal (for example, an error message referencing the offending line in your source code) requires the use of the other shortcut (Alt + Click). Since it seems that Linux and MacOS have various strange behaviors when Alt + Clicking in a terminal, you are suggesting we switch back to the default . Now we'll use Ctrl+Click / Cmd+Click to follow links in the Terminal, avoiding all that ^[[D^[[D^[[D^[[D nonsense that sometimes causes the terminal to hang. For multi-selecting in the editor window, we'll have to get used to using Alt + Click for that, but in my opinion, that is better than having terminal hanging issues unexpectedly.
So to clarify what I originally posted to Alt+Click will still cause junk to fill the screen, regardless of the value of "editor.multiCursorModifier" setting. However, the above workaround means we don't need the Alt+Click anymore.
it's a feature that's sending keys to move the terminal cursor to the position of the mouse cursor. It needs support in whatever program is running in the terminal though which is why you might see the printed, we cannot detect this support though. The advice right now is to avoid alt clicking if it doesn't work in the program.