jiebi/CodeConvo huggingface dataset:
Change:
return actions; } <ins> //#endregion //#region groupedAccounts helpers private async addOrUpdateAccount(providerId: string, account: AuthenticationSessionAccount): Promise<void> { const accounts = this.groupedAccounts.get(providerId); const existingAccount = accounts?.find(a => a.id === account.id); if (existingAccount) { if (existingAccount.label !== account.label) { existingAccount.label = account.label; } return; } const sessionFromEmbedder = await this.sessionFromEmbedder; // If the session stored from the embedder allows sign out, then we can treat it and all others as sign out-able let canSignOut = !!sessionFromEmbedder?.canSignOut; if (!canSignOut) { if (sessionFromEmbedder?.id) { const sessions = (await this.authenticationService.getSessions(providerId)).filter(s => s.account.id === account.id); canSignOut = !sessions.some(s => s.id === sessionFromEmbedder.id); } else { // The default if we don't have a session from the embedder is to allow sign out canSignOut = true; } } if (!accounts) { this.groupedAccounts.set(providerId, [{ ...account, canSignOut }]); return; } accounts.push({ ...account, canSignOut }); } private removeAccount(providerId: string, account: AuthenticationSessionAccount): void { const accounts = this.groupedAccounts.get(providerId); if (!accounts) { return; } const index = accounts.findIndex(a => a.id === account.id); if (index === -1) { return; } accounts.splice(index, 1); if (accounts.length === 0) { this.groupedAccounts.delete(providerId); } } private async addAccountsFromProvider(providerId: string): Promise<void> { try { const sessions = await this.authenticationService.getSessions(providerId); this.problematicProviders.delete(providerId); const result = await Promise.allSettled(sessions.map(s => this.addOrUpdateAccount(providerId, s.account))); for (const r of result) { if (r.status === 'rejected') { this.logService.error(r.reason); } } } catch (e) { this.logService.error(e); this.problematicProviders.add(providerId); } } //#endregion </ins> } export interface IProfileActivity extends IActivity {

Discussion:
Update: reproduces in web + desktop Steps to Reproduce: a Codespace until it is loaded various activity bar items that open menus (gear menu, accounts, main menu, home indicator) = somehow the accounts menu only opens for me after a delay, as if something was resolved when clicking? !
This still reproduces
does this still repro? maybe its imperceptible to me?
Yeah still seems slightly delayed to me, can we not check the code and see if a longer running promise prevents the menu from showing?
looks like we fetch session info every time, so this probably adds some delay. maybe this can be cached and updated separately
Yeah that seems like a reasonable ask since it goes to the extension host and back, today.
This issue has existed since 2 years! But only recently have I encountered this.
Change:
# Sent whenever a new fish prompt is about to be displayed. # Updates the current working directory. function __vsc_update_cwd --on-event fish_prompt <del> __vsc_esc P "Cwd=$(__vsc_escape_value "$PWD")" </del> <ins> __vsc_esc P Cwd=(__vsc_escape_value "$PWD") </ins> # If a command marker exists, remove it. # Otherwise, the commandline is empty and no command was run.

Discussion:
<!-- 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 <!-- 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.74.0 OS Version: macOS 13.0 Error when launching terminal with fish integration set up: Steps to Reproduce: terminal. is there.
Change:
"languages": [{ "id": "shellscript", "aliases": ["Shell Script", "shellscript", "bash", "sh", "zsh", "ksh", "csh"], <del> "extensions": [".sh", ".bash", ".bashrc", ".bash_aliases", ".bash_profile", ".bash_login", ".ebuild", ".install", ".profile", ".bash_logout", ".zsh", ".zshrc", ".zprofile", ".zlogin", ".zlogout", ".zshenv", ".zsh-theme", ".ksh", ".csh", ".cshrc"], </del> <ins> "extensions": [ ".sh", ".bash", ".bashrc", ".bash_aliases", ".bash_profile", ".bash_login", ".ebuild", ".install", ".profile", ".bash_logout", ".zsh", ".zshrc", ".zprofile", ".zlogin", ".zlogout", ".zshenv", ".zsh-theme", ".ksh", ".csh", ".cshrc", ".tcshrc", ".yashrc", ".yash_profile" ], </ins> "filenames": [ <del> "APKBUILD", "PKGBUILD", ".envrc" ], "firstLine": "^#!.*b(bash|zsh|sh|tcsh|ksh|ash|qsh|csh).*|^#s*-*-[^*]*mode:s*shell-script[^*]*-*-", </del> <ins> "APKBUILD", "PKGBUILD", ".envrc", ".hushlogin", "zshrc", "zshenv", "zlogin", "zprofile", "zlogout", "bashrc_Apple_Terminal", "zshrc_Apple_Terminal" ], "firstLine": "^#!.*b(bash|zsh|sh|ksh|dtksh|pdksh|mksh|ash|dash|yash|sh|csh|jcsh|tcsh|itcsh).*|^#s*-*-[^*]*mode:s*shell-script[^*]*-*-", </ins> "configuration": "./language-configuration.json", "mimetypes": ["text/x-shellscript"] }],

Discussion:
<!-- 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. --Let's expand the file patterns recognized as POSIZy shell scripts: Files with ash, dash, posh, yash shebangs zsh core configuration files (, , , , , , , , , , , , , , ) Slant rhyme filenames like , This last one is going to trigger some false positives, but perhaps that is better than highlighting as TXT files.
Also see . PRs are welcome!
Hey I can take this. Any tips on where to start looking? :slightlysmilingface:
Cool. Have a look here:

<!-- Do Not Delete This! bugreporttemplate --VSCode does a decent job highlighting many different shell script languages. But it doesn't seem to be aware that pdksh, dash, mksh, and posh, especially configuration files like and shebanged extensionless scripts, are POSIXy shell scripts. They just highlight as Plain Text files instead. Same for , that's a Tcsh shell script.
PR welcome!
Change:
* It is not globally unique in order to limit it to one character. */ private readonly _instanceId: string; <ins> private _deltaDecorationCallCnt: number = 0; </ins> private _lastDecorationId: number; private _decorations: { [decorationId: string]: IntervalNode }; private _decorationsTree: DecorationsTrees;

Discussion:
VS Code: 1.67.0 (, 2022-05-04T12:06:02.889Z) Since this update (also tested on clean Insiders), if a variable is selected using the "" shortcut ( in my case), the occurrence indicators of it don't clean up when selection is canceled by cursor navigating away from it. Here is how it works with a mouse (correct): ! And with a shortcut (stay forever): ! They won't clean up even if I select a different variable, the indicators are just to the previous ones. They only disappear if I switch editor to a different file and come back.
fyi this is also caused by recursing i.e.
Would you like to release a patch? This bug is so annoying!!!
Change:
|| e.equals(KeyMod.CtrlCmd | KeyCode.Escape) || e.equals(KeyMod.Alt | KeyCode.Escape) || e.equals(KeyMod.Shift | KeyCode.Escape) <del> ) { e.preventDefault(); this.hide(); } if ( e.equals(KeyCode.Space) </del> <ins> || e.equals(KeyCode.Space) </ins> || e.equals(KeyCode.Enter) ) { e.preventDefault();

Discussion:
CC and Version: 1.75.0-insider (system setup) Commit: Date: 2023-01-16T05:21:04.032Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes VSCode-insiders with screen reader. any PR commit in diff editor. Alt+F5 to go to the next change in diff editor: You will hear audio cues. the changed line, press F7 to open the special diff pane where you can navigate what's been deleted and denoted with +/- signs. ESC to close the special diff pane once you have figured out the differences: The cursor location has changed. The original cursor line is not preserved in the diff editor. Notes: The original cursor location is preserved only when you explicitly press enter on the changed line in F7 diff pane. The original cursor position in the diff editor must be preserved after closing the F7 diff pane via ESC. I have already found the amazing usefullness of Alt+F5 and F7 interplays. Alt+F5 is very useful for a general overview of changes (+-) whereas F7 gives the detailed information on changes. It would be even nicer if we could have a smoother interplay between them like below: diff editor, press Alt+F5 to go to any next changes. F7 to open detailed changes in the special diff pane. soon as the F7 diff pane is open, the focus is landed on the specific change denoted with +/- signs: Currently the focus moves to the top of the F7 diff pane so that users need to arrow-down several times to find the specific changes.
This makes sense to me. The F7 special diff pane feels jumpy to me as it currently is.
any historical context here I'm missing?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!

I do not have much historical context here. But I think we should be flexible to change things here based on user feedback and what we think is better.
I'm not sure if it was fixed or not, here's what I see. The same with or without a screenreader enabled alt+F5, the cursor is at the top of a changed block F7 Escape, the cursor is now a couple lines above the changed block
This is working - notice the blue focus border around the line in the f7 view - that's where the cursor is and should be when I escape that view https://user-
This works well when I use the arrow keys after F7, but if I just do F7 and then then I see the same as Rob.
has this been fixed in v2?
I'm not so sure this is a bug. Afaik we intentionally synchronize the cursor position from the accessible diff viewer with the normal diff viewer.
This is working for me.
Change:
export const MessagesVisibleContext = new RawContextKey<boolean>('globalMessageVisible', false); export const EditorsVisibleContext = new RawContextKey<boolean>('editorIsOpen', false); export const InZenModeContext = new RawContextKey<boolean>('inZenMode', false); <ins> export const SidebarVisibleContext = new RawContextKey<boolean>('sidebarVisible', false); </ins> export const NoEditorsVisibleContext: ContextKeyExpr = EditorsVisibleContext.toNegated(); interface WorkbenchParams {

Discussion:
Currently there is no way to tell if sidebar is visible. You can get the state only for 2/5 viewlets. Explorer: Search: Source Control: Debug: Extensions: Sidebar (any of the above is visible):
PR that fixes this is welcome. Code pointer Basicaly the part service would need to add new context key and set it when sidebar gets shown / hidden. I propose to call this context key .
Change:
"vscode-oniguruma": "1.7.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "9.0.0", <del> "xterm": "5.3.0-beta.46", "xterm-addon-canvas": "0.5.0-beta.9", "xterm-addon-image": "0.6.0-beta.2", "xterm-addon-search": "0.13.0-beta.8", "xterm-addon-serialize": "0.11.0-beta.8", "xterm-addon-unicode11": "0.5.0", "xterm-addon-webgl": "0.16.0-beta.16", "xterm-headless": "5.3.0-beta.46", </del> <ins> "xterm": "5.3.0-beta.58", "xterm-addon-canvas": "0.5.0-beta.19", "xterm-addon-image": "0.6.0-beta.11", "xterm-addon-search": "0.13.0-beta.17", "xterm-addon-serialize": "0.11.0-beta.17", "xterm-addon-unicode11": "0.6.0-beta.9", "xterm-addon-webgl": "0.16.0-beta.27", "xterm-headless": "5.3.0-beta.58", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },

Discussion:
<img width="1116" alt="Screenshot 2023-08-04 at 2 35 57 pm" src=""I've been seeing this fairly consistently, when doing the set upstream quick fix it will lock the scrolling, scrolling down manually will do the audio cue for the next quick fix.
diff from 5.2.1:
Possible cause:
I'm guessing this is the issue: , we never want to animate this case.
Is ctrl+. still supposed to trigger the quick fix widget? It doesn't currently for me
yes ctrl/cmd+.
Never mind, I apparently customized it some time ago (likely for another TPI), all good
Change:
promptChoices.push({ label: localize('install release version', "Install Release Version"), run: () => { <del> const installAction = this.installOptions?.isMachineScoped ? this.instantiationService.createInstance(InstallAction, { installPreReleaseVersion: !!this.installOptions.installPreReleaseVersion }) : this.instantiationService.createInstance(InstallAndSyncAction, { installPreReleaseVersion: !!this.installOptions?.installPreReleaseVersion }); </del> <ins> const installAction = this.instantiationService.createInstance(InstallAction, { installPreReleaseVersion: !!this.installOptions?.installPreReleaseVersion }); </ins> installAction.extension = this.extension; return installAction.run(); }

Discussion:
Look at telemetry and if not a lot of users are using the Install and Do not Sync extension action remove the action to simplify the Extension Install flow. is the action name. fyi
Ok was run on 59K distinct machines. For comparison extensionGallery:install was executed on 10.4M machines. So Do not Sync is used in 0.5% of cases. I think it is fine if we remove it - we keep it somewhere but not so prominent. what do you think?
Any suggestions?
We already have the "Sync Extension" check in the Extension context menu when it is installed - this is great. ! And we already have the "Sync Extension" check in the same context menu when it is not installed. Just currently if I click this, there is no effect. So ideally the experience would be that I can uncheck this before installing the extension. And thus we need no new actions. !
Lets try this in insiders already and see if we get any hit back.
Awesome - thanks!
Change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> export const testUrlMatchesGlob = (url: string, globUrl: string): boolean => { </del> <ins> import { URI } from 'vs/base/common/uri'; // TODO: rewrite this to use URIs directly and validate each part individually // instead of relying on memoization of the stringified URI. export const testUrlMatchesGlob = (uri: URI, globUrl: string): boolean => { let url = uri.with({ query: null, fragment: null }).toString(); </ins> const normalize = (url: string) => url.replace(//+$/, ''); globUrl = normalize(globUrl); url = normalize(url);

Discussion:
<!-- 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: out of GitHub if you are logged in a trusted domain rule for GitHub Repos extension or something else, start a Login for GitHub Notice that you get prompted to allow this URL as a trusted domain No prompt This is because () doesn't handle query parameters well... and thinks they are part of the path when validating. You can see this behavior by adding a at the end of in the Trusted Domains. We should really ignore query parameters and fragments here.
Change:
this._onDidChangeModel.fire(e); this._postDetachModelCleanup(detachedModel); <del> this._contributions.onAfterModelAttached(); </del> <ins> this._contributionsDisposable = this._contributions.onAfterModelAttached(); </ins> } private _removeDecorationTypes(): void {

Discussion:
<!-- 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 <!-- 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.86.1 OS Version: Ubuntu 23.04 Steps to Reproduce: an empty text editor the text opening and closing an empty text editor several times that the number of disposables increases each time Opening and closing an editor 1997 times results in 3994 disposables with this stack trace: When opening an editor, the function is called , the function calls adds a disposable to the disposable store When closing and opening the editor again, the same happens: the function is called , the function calls adds a disposable to the disposable store again This probably causes more and more disposables to be in . It seems, disposing the codeEditorContributions disposable () when a text editor model becomes detached might be a possible solution. That way, it would be registered when a model is attached and disposed when a model becomes detached:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Thanks a lot!
Change:
import 'vs/css!./media/debug.contribution'; import 'vs/css!./media/debugHover'; import * as nls from 'vs/nls'; <ins> import { Color } from 'vs/base/common/color'; </ins> import { KeyMod, KeyCode } from 'vs/base/common/keyCodes'; import { SyncActionDescriptor, MenuRegistry, MenuId } from 'vs/platform/actions/common/actions'; import { Registry } from 'vs/platform/registry/common/platform';

Discussion:
I stumbled over and saw that there are still many colors hard-coded. Also while at the .css file, it's good practice to qualify all rules with (or ) now that the workbench can be embedded in the web.
Thanks for great feedback. There was some unused CSS, like the .annotation in the repl, so I removed that. I have also now qualifed all with . There is still one hard coded color for in repl, but I believe tackled this with his great PR. Though I might be mistaken?
I did, indeed, add colour contribution points to the REPL as part of but eventually you asked me to defer those until later, I do not remember the reason precisely... So the REPL is still not theme-able, unfortunately.
thanks for refreshing my memory. In case you would like to contribute that part of your PR we are open to accept it now :D From the I only see a need for color, not sure if there is more.
I am working on this now. I am taking it a step further, though, and adding theming to most of the REPL elements (errors, warnings, infos, source filenames etc.). Basically I want the whole REPL view to be fully customisable.
To verify, make sure you can customise the following colors in the debug console. You can use the setting :
Change:
{ <ins> "enableProposedApi": true, </ins> "name": "html-language-features", "displayName": "%displayName%", "description": "%description%",

Discussion:
Semantic selections: LSP: works CSS/SCSS/LESS: doesn't work, but it works in Atom. Probably need to update our dependencies. The plan now is to use emmet's "balance" commands. The challenge is that HTML/CSS language service need to include emmet. Alternatively, we can implement these commands ourselves.
Please review the animated gifs in the original thread: Seems to me the emmet functionality as it stands is wholly inadequate.
This will be available in tomorrow's insiders: !
is this suppose to work in Javascript? It's not nearly as functional as Webstorm. Also fails dramatically with HTML in .Vue files. Oh well.
Vue — it'll be available once we update the dependencies. JavaScript — we'll need to wait for TypeScript to add the semantic selection. I don't have any estimate.
Change:
<array> <dict> <key>include</key> <del> <string>#list_paragraph</string> </del> <ins> <string>#block</string> </ins> </dict> <dict> <key>include</key> <del> <string>#block</string> </del> <ins> <string>#list_paragraph</string> </ins> </dict> </array> <key>while</key>

Discussion:
When I put a fenced code area in the middle of a bulleted list, I notice that list entries following the fenced code area lose their formatting, like so: ! Is this intentional behavior? Am I formatting my markdown wrong? Is there any way that I can have formatting in both the fenced code block and the subsequent list items?
The current formatting is somewhat off: the second list is treated as code block. ! This is expected and is in keeping with the common mark spec. The correct formatting would be to indent fenced code block as well: javascript for(var i = 0; i < 5; i++){ ("Hello"); } ! Our syntax coloring is off here though, with the indented code block no longer being highlighted as js
Okay. I didn't read the markdown specification closely enough to understand that the code block should be highlighted as well. I had tried indenting the code block, but when the indented code block lost syntax highlighting, I thought I was doing something incorrect. Should I update the title of this issue to indicate that the real problem is that indented code blocks lose formatting?
Thanks I've just gone ahead and updated the title of the issue to: "Markdown Fenced Code Block in Indented List Not Properly Highlighted". If you do not feel that the new title accurately captures the bug here, feel free to update the title again
New title looks good. Thanks!
I made an extension to fix this Surely it would cause side effects but it is worth it for me at the moment.
Change:
this._extensionHostProcessManager = null; this.startDelayed(lifecycleService); <ins> if (this._environmentService.disableExtensions) { this._notificationService.info(nls.localize('extensionsDisabled', "All extensions are disabled.")); } </ins> } private startDelayed(lifecycleService: ILifecycleService): void {

Discussion:
Testing When selecting the link to run with disabled extension then we do everything automatically, even reloading the window (which is great). However, it is almost to transparent and suggested to show a notification inside the workbench that VS Code is now run with extensions disabled..
Actually, now that I think more about it, the notification should always appear, regardless of whether it due to the issue reporter.
Also, maybe there should be an action in that notification to revert the process.
Change:
data: 'data:', vscode: 'vscode:', 'vscode-insiders': 'vscode-insiders:', <ins> notebookCell: 'vscode-notebook-cell', </ins> }; const knownSchemes = [

Discussion:
while testing a markdown file with a header a notebook with a markdown cell and link to that header the link in the rendered markdown result: vscode attempts to navigate to a file named note that both auto-complete and find references for the header work correctly for that link.