jiebi/CodeConvo huggingface dataset:
Code change:
this._register(AccessibleViewAction.addImplementation(95, 'inline-completions', accessor => { const accessibleViewService = accessor.get(IAccessibleViewService); const codeEditorService = accessor.get(ICodeEditorService); <ins> const contextViewService = accessor.get(IContextViewService); </ins> const show = () => { const editor = codeEditorService.getActiveCodeEditor() || codeEditorService.getFocusedCodeEditor(); if (!editor) {

Related discussion:
text: Type: <bBug</bPressing Alt+] and Alt+[ in Accessible View includes redundant aria alert before new content. On Windows, NVDA and JAWS users hear the following info first whenever they press Alt+] and Alt+[ in Accessible View: I have tested with Accessible View against inline suggestion. Please exclude this message from the aria alert. VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-17T05:33:29.141Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.20.0 gitlens14.2.1 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.14.15 copilot1.104.343 copilot-chat0.7. remotehub0.60.0 vscode-github-actions0.26.1 vscode-pull-request-github0.70.0 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.4 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.14.0 vscode-pylance2023.8.30 jupyter2023.7.
Code change:
this._register(AccessibleViewAction.addImplementation(95, 'inline-completions', accessor => { const accessibleViewService = accessor.get(IAccessibleViewService); const codeEditorService = accessor.get(ICodeEditorService); <ins> const contextViewService = accessor.get(IContextViewService); </ins> const show = () => { const editor = codeEditorService.getActiveCodeEditor() || codeEditorService.getFocusedCodeEditor(); if (!editor) {

Related discussion:
text: jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.105.1 remote-ssh-edit0.86.0 remote-wsl0.81.0 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.15.31 cpptools1.17.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.8.1117 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.16 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.94.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.13.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.53.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.13 vscode-java-test0.39.1 vscode-maven0.42.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
can you pls try in insider's? I made some changes yesterday that should've fixed this.
This issue still exists in the latest insider that I have updated today.
That info, 'Inline Completions Accessible View' was formerly provided via the aria label.
Code change:
this._register(AccessibleViewAction.addImplementation(95, 'inline-completions', accessor => { const accessibleViewService = accessor.get(IAccessibleViewService); const codeEditorService = accessor.get(ICodeEditorService); <ins> const contextViewService = accessor.get(IContextViewService); </ins> const show = () => { const editor = codeEditorService.getActiveCodeEditor() || codeEditorService.getFocusedCodeEditor(); if (!editor) {

Related discussion:
text: With this change, , it just says 'Accessible View', but when I use the keybindings to go to next/previous, I only hear the new suggestion via as expected.
That’s odd. I still hear that redundant label info in Accessible View for inline suggestion when pressing Alt+[ and Alt+]. I have tested with NVDA and JAWS on Windows 11.
What happens for me is: inline completion accessible view "Accessible View, edit text...." 's some delay before the screen reader moves on from reading the initial text then I'm alerted with the new suggestion
If we wanted to prevent this delay, we'd need to hide the context view, wait 50 ms, reshow it. The issue with that is then it would do exactly what you describe and read the aria label + edit text before reading the new suggestion. That's what was happening in insider's yesterday and I realized was not ideal, so changed it.
can you reproduce this in today's Insiders?
it is working for me as described. I also debug with NVDA, and confirmed that it is processing the focus events before the liveRegionChange event. However, if I use Alt + left or right brackets, it behaves as we expect. If you hide the accessible view for 50 ms it might work, simply because NVDA will not receive any focus event before the alert.
I get slightly nervous about being so prescriptive when it goes to screen reader behavior. You just need a small change in the way the screen reader handle things for all these hacks to turn against us. There are a few that I feel comfortable recommending.
Thanks for confirming I've only tried macOS/ VoiceOver, so maybe the repro happens only when using NVDA. Here was the change where I had that delay
I can bring that change back if it seems reasonable to you. It's just like the other one that you tested and said works well
we still need to setup self hosting for you .
Oh yes. self-hosting is fun.
Code change:
export interface FileSearchQuery { /** * The search pattern to match against file paths. <ins> * To be correctly interpreted by Quick Open, this is interpreted in a relaxed way. The picker will apply its own highlighting and scoring on the results. * * Tips for matching in Quick Open: * With the pattern, the picker will use the file name and file paths to score each entry. The score will determine the ordering and filtering. * The scoring prioritizes prefix and substring matching. Then, it checks and it checks whether the pattern's letters appear in the same order as in the target (file name and path). * If a file does not match at all using our criteria, it will be omitted from Quick Open. </ins> */ pattern: string; }

Related discussion:
text: From We should add some clarifying comments to this parameter. It should be quite similar to that of , since the quickpick assumes the highlighting and fuzzy matching of the matches.
adds a description, which will probably get cleaned up once we start cleaning up the APIs more.
Code change:
</dict> </dict> <key>end</key> <del> <string>(?&lt;=S)(1)((?!1)|(?=11))</string> </del> <ins> <string>(?&lt;=S)(1)((?!1)|(?=11))b</string> </ins> <key>name</key> <string>markup.italic.markdown</string> <key>patterns</key>

Related discussion:
text: VSCode Version: 1.19.1 In Markdown files, the editor is incorrectly styling every other inner word surrounded by underscores as italicized. The preview correctly shows them as not italicized. !
I think this is what Text Mate grammars' behavior. Tried in TextMate 2.0 (latest), same there. !
I think is right on this. The editor has an error as it interprets the other word as if it was a separate word starting and finishing with `` (that would be italized). It is correctly displayed on Github editor :
I created a PR to fix this
Code change:
} }, { <del> "name": "Markup Setext Header", "scope": "markup.heading.setext", </del> <ins> "name": "Markup Headings", "scope": [ "markup.heading", "markup.heading.setext" ], </ins> "settings": { <del> "fontStyle": "", "foreground": "#ddbb88" </del> <ins> "fontStyle": "bold", "foreground": "#6688cc" </ins> } } ],

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --This is essentially a more general issue of the closed Markdown styling support are missing in the following, missing bold and italic: Solarized Light Red Abyss Solarized Dark Tomrrow Night Blue See screenshot below for an example. For High Contrast, section heading () are not in bold. I am unclear if it's a bug or intentional. Screenshot for Solarized Dark !
Hi, I tried bold and italic with these themes: theme-tomorrow-night-blue theme-solarized-dark theme-solarized-light theme-red theme-kimbie-dark theme-abyss hcblackdefaults(High Contrast)
Code change:
const participant = chat.createChatParticipant('api-test.participant', (request, context, _progress, _token) => { emitter.fire({ request, context }); <del> return null; </del> }); participant.isDefault = true; disposables.push(participant);

Related discussion:
text: Testing If there's no error case, I now need to return something like:
Hi we have branched off from today, so I am pinging about the milestone here. Would you like to make this issue a candidate or move it out to the milestone?
Moving to March for now. Feel free to move this issue back to February if it turns out to be a candidate.
It's already a , which allows 'undefined' but not void. Is it weird to say ?
+1 on this, I have to explicitly today
Code change:
return new Uri('file', authority, path, _empty, _empty); } <del> static from(components: { scheme: string; authority?: string; path?: string; query?: string; fragment?: string }): URI { </del> <ins> /** * Creates new URI from uri components. * * Unless `strict` is `true` the scheme is defaults to be `file`. This function performs * validation and should be used for untrusted uri components retrieved from storage, * user input, command arguments etc */ static from(components: { scheme: string; authority?: string; path?: string; query?: string; fragment?: string }, strict?: boolean): URI { </ins> const result = new Uri( components.scheme, components.authority, components.path, components.query, components.fragment, <ins> strict </ins> ); <del> _validateUri(result, true); </del> return result; }

Related discussion:
text: Following test throws: I found this while investigating At that point the editor component is quite broken because of a lot of errors being thrown. Notice how not even a tab shows for the editor: <img width="1058" alt="image" src="https://user-"
that should already throw because at least a scheme is needed. It doesn't because was designed to be the runtime counter part of which never produces such output so some IPC deserialisation cost can be saved.
, that works for me and will also throw when we get bad objects into such as the from
Yeah, my plan is to add an argument like we have in other URI-places. It will default to true and only IPC should be relaxed
Not doing that because it actually already exists as . I believe the adoption/migration task is to use instead of whenever getting uri components from storage or esp from command arguments. Tho, there is one special case for which is that it automatically uses when the scheme is missing. We could make that configurable but a check for might make this obsolete
Closing this after and the ask to use when creating uri from "untrusted" sources
I will see to adopt , I forgot we had it
Code change:
let foldersToRestore: URI[] = []; let workspacesToRestore: IWorkspacePathToOpen[] = []; if (openConfig.initialStartup && !openConfig.cli.extensionDevelopmentPath && !openConfig.cli['disable-restore-windows']) { <del> let foldersToRestore = this.backupMainService.getFolderBackupPaths(); foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </del> <ins> // don't restore backuped folders, for #92318. // let foldersToRestore = this.backupMainService.getFolderBackupPaths(); // foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </ins> // collect from workspaces with hot-exit backups and from previous window session workspacesToRestore = [...this.backupMainService.getWorkspaceBackups(), ...this.workspacesMainService.getUntitledWorkspacesSync()];

Related discussion:
text: Issue Type: <bBug</bAfter updating to 1.43.0, when VSCode relaunched, it brought up around 80 editor windows from old projects I hadn't opened in quite some time. (spooky workspace necromancy) Perhaps obviously this made my computer behave quite poorly. I tried adding "window.restoreWindows": "none" to my with another text editor, but it didn't seem to be respected (might be my fault somehow). Note that it had been on "folders" previously, in case that helps. I also tried to muck about with file. VSCode seemed to ignore my changes to it (probably not a bug -- I was desparate and dunno how this file works), but I do have a backup of a from right after this happened. It shows all the windows it will try to open when launching, and maybe other stuff. I guess the system info probably has more PII anyway. I dunno how much this helps but: I think the main common feature of the workspaces it resurrected seemed to be that they had open files with unsaved changes -- but these are also the ones which can't be closed without additional UI confirmation, and I did try a couple things to close all windows in bulk (none seemed to work, but maybe I just didn't notice?) Relaunching without extensions also didn't help, but that doesn't mean this wasn't caused by an extension in the first place or somethign. I have more than is probably reasonable installed. That said, it happening immediately after updating to 1.43.0 makes me think it's vscode and not an extension. Anyway, ultimately I just bit the bullet and closed them manually -- VSCode would be usable for about 20 seconds after starting, during which time I could close a few before too many were restored and everything got too slow. So i just did this, quit, and repeated many times until there were no more left (this actually took a couple goes -- even when I'd get down to none left, save, and reopen, it would find some new ones to bring back... Guessing these just didn't make the cut for being restored the previous time, or something) P.S. it would be nice if there were a command line argument to launch without reopening anything. P.P.S.
Code change:
let foldersToRestore: URI[] = []; let workspacesToRestore: IWorkspacePathToOpen[] = []; if (openConfig.initialStartup && !openConfig.cli.extensionDevelopmentPath && !openConfig.cli['disable-restore-windows']) { <del> let foldersToRestore = this.backupMainService.getFolderBackupPaths(); foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </del> <ins> // don't restore backuped folders, for #92318. // let foldersToRestore = this.backupMainService.getFolderBackupPaths(); // foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </ins> // collect from workspaces with hot-exit backups and from previous window session workspacesToRestore = [...this.backupMainService.getWorkspaceBackups(), ...this.workspacesMainService.getUntitledWorkspacesSync()];

Related discussion:
text: In case it isn't clear: I've been using , , and somewhat interchangably here, just so you don't think I'm being precise about which I use when. VS Code version: Code 1.43.0 (, 2020-03-09T19:34:44.548Z) OS version: Darwin x64 18.7.0 <details<summarySystem Info</summary </details<details<summaryExtensions (55)</summaryExtensionVersion ------ code-gnu-global0.2.2 better-toml0.3.2 glsl-canvas0.2.8 bracket-pair-colorizer-20.0.29 dart-code3.8.1 xml2.5.0 scopes0.45.0 gitlens10.2.1 vscode-html-css0.2.3 tslint1.0.44 vsc-material-theme32.5.0 vsc-material-theme-icons1.1.4 prettier-vscode3.20.0 vscode-test-explorer2.17.0 vscode-peacock3.6.0 language-haskell2.7.0 center-editor-window2.3.0 chat0.31.0 restructuredtext120.0.0 fish-ide0.4.0 regionfolder1.0.8 Kotlin1.7.1 rust-analyzer0.1.
Code change:
let foldersToRestore: URI[] = []; let workspacesToRestore: IWorkspacePathToOpen[] = []; if (openConfig.initialStartup && !openConfig.cli.extensionDevelopmentPath && !openConfig.cli['disable-restore-windows']) { <del> let foldersToRestore = this.backupMainService.getFolderBackupPaths(); foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </del> <ins> // don't restore backuped folders, for #92318. // let foldersToRestore = this.backupMainService.getFolderBackupPaths(); // foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </ins> // collect from workspaces with hot-exit backups and from previous window session workspacesToRestore = [...this.backupMainService.getWorkspaceBackups(), ...this.workspacesMainService.getUntitledWorkspacesSync()];

Related discussion:
text: Lisp0.1.10 ninja-syntax1.0.0 prettify-json0.0.3 vscode-json51.0.0 vscode-docker1.0.0 csharp1.21.13 sublime-keybindings4.0.6 vscode-typescript-tslint-plugin1.2.3 vsliveshare1.0.1711 vsliveshare-audio0.1.80 vsliveshare-pack0.3.4 debugger-for-chrome4.12.6 idl0.3.1 autotrim1.0.6 proto0.0.2 material-icon-theme4.0.1 polacode0.3.4 tcl0.1.0 crates0.4.7 trailing-spaces0.3.1 vscode-scheme0.4.0 fish-vscode0.2.1 shader1.1.4 rewrap1.9.1 shellcheck0.9.0 org-mode0.5.0 cmake0.0.17 vscode-lldb1.5.0 vscode-icons10.0.0 material-theme3.2.3 vscode-open-in-github1.3.6 tslint-snippets1.1.0 (11 theme extensions excluded) </details<!-- generated by issue reporter --
FWIW this does seem to be respected now and I haven't changed anything, maybe indicating that it was being ignored for some reason during all this? Not sure if this is important, but worth noting I guess.
Hit the same issue here, VSCode opened up a few hundred projects after upgrading and my mac nearly fell over:
Yeah, I expected this to happen. Works now "correctly" after pushed This is expected hot exit behaviour to restore workspaces that have backed up files.
Hit this last night as well and it completely froze my machine up for minutes opening at least 40 windows. I get why this is an expected fix for a bug, but I it made my computer totally unresponsive and probably could have used a more progressive one-time rollout.
So it looks like this was a regression in 1.42 () and it's now fixed as it's designed. It's designed this way so that by default, backups don't go "missing" by accidentally closing window(s) and forgetting which one had your notes in it.
Code change:
let foldersToRestore: URI[] = []; let workspacesToRestore: IWorkspacePathToOpen[] = []; if (openConfig.initialStartup && !openConfig.cli.extensionDevelopmentPath && !openConfig.cli['disable-restore-windows']) { <del> let foldersToRestore = this.backupMainService.getFolderBackupPaths(); foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </del> <ins> // don't restore backuped folders, for #92318. // let foldersToRestore = this.backupMainService.getFolderBackupPaths(); // foldersToOpen.push(...foldersToRestore.map(f => ({ folderUri: f, remoteAuhority: getRemoteAuthority(f) }))); </ins> // collect from workspaces with hot-exit backups and from previous window session workspacesToRestore = [...this.backupMainService.getWorkspaceBackups(), ...this.workspacesMainService.getUntitledWorkspacesSync()];

Related discussion:
text: I can attest to the fact that it's awful when many windows unexpectedly restore as it happened to me when testing settings sync. I'm not sure what the right recovery fix is but you can workaround this in the meantime by setting in your . To go back you would need to either delete the backup files manually ( from the 's folder) or open the workspaces and close unsaved files.
Just to clarify, for anyone coming to this thread who's hosed with 40+ windows, it sounds like what you're saying is the workaround is set to so that we don't have to go through a ton of different "do you want to save this?" prompts when we try to close every window. set to (or another reasonable setting) so that VS Code doesn't try to open a ton of windows for every workspace with unsaved files. delete the unsaved buffers manually until things are bearable again. Is that the recommendation?
Is all I needed to stop the window tsunami.
if you just set you should be fine if you then open a new folder () and then close the window. This is actually how I've always used hot exit and recommend it if you haven't tried, it takes the rails off and was meant so that you can close windows arbitrarily even on macOS as well as not restoring all windows with backups whenever VS Code gets launched. If you want to go back to , deleting the buffers manually after reviewing is probably the best way to go.
I'm struggling to find a way to properly fix this for users without just changing the behavior something since this change in behavior looks to have been in . Maybe some restriction on the maximum number of windows that can be opened at once, with a dialog if it's over 5 or something? do you know what the behavior was before? seems to add folders to a the active workspace, does this mean all workspaces with folders were getting restored into a single window, or did they get dropped somehow?
I am quite sure we opened 1 window per backup directory with backups. So ended up always restoring every window that has backups. We decided with this approach to ensure we always bring back dirty files into their windows independent from any setting (other than the hot exit one at least). Btw untitled workspaces behave exactly the same for the same reasons because they may contain setting changes that are unsaved.