jiebi/CodeConvo huggingface dataset:
Change:
GetBranchOperation | GetBranchesOperation | GetCommitTemplateOperation | GetObjectDetailsOperation | GetRefsOperation | GetRemoteRefsOperation | HashObjectOperation | IgnoreOperation | LogOperation | LogFileOperation | MergeOperation | MergeAbortOperation | MergeBaseOperation | MoveOperation | PostCommitCommandOperation | PullOperation | PushOperation | RemoteOperation | RenameBranchOperation | RemoveOperation | <del> ResetOperation | RebaseOperation | RebaseAbortOperation | RebaseContinueOperation | RevertFilesOperation | RevListOperation | </del> <ins> ResetOperation | RebaseOperation | RebaseAbortOperation | RebaseContinueOperation | RevertFilesOperation | RevListOperation | RevParseOperation | </ins> SetBranchUpstreamOperation | ShowOperation | StageOperation | StatusOperation | StashOperation | SubmoduleUpdateOperation | SyncOperation | TagOperation;

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: on a file from the "All Changes" node that the diff editor does not have the commit for the right hand side !
Change:
assertElectronAcceleratorLabel(OperatingSystem.Macintosh, KeyChord(KeyMod.CtrlCmd | KeyCode.KEY_A, KeyMod.CtrlCmd | KeyCode.KEY_B), 'cmd+a cmd+b'); }); <ins> test('issue #91235: Do not end with a +', () => { assertUSLabel(OperatingSystem.Windows, KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.Alt, 'Ctrl+Alt'); }); </ins> });

Discussion:
Issue Type: <bBug</bWhen using screencast mode, if you press a sequence of keys such as "Ctrl" + "Alt", Visual Studio Code adds an extra + at the end of the sequence. ! VS Code version: Code 1.42.1 (, 2020-02-11T14:45:59.656Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (32)</summaryExtensionVersion ------ 30-seconds-of-code1.0.0 better-comments2.0.5 Bookmarks11.0.0 vscode-color0.4.5 bracket-pair-colorizer1.0.61 javascript-ejs-support1.3.1 vscode-npm-script0.3.11 vsc-material-theme32.5.0 vsc-material-theme-icons1.1.4 php-intellisense2.3.14 vscode-mocha-test-adapter2.2.2 vscode-test-explorer2.17.0 python2020.2. remote-wsl0.42.3 vsliveshare1.0.1653 material-icon-theme3.9.3 java0.57.0 vscode-xml0.10.1 code-settings-sync3.4.3 vscode-spotify3.1.0 java-generate-setters-getters5.3.0 code-spell-checker1.7.24 vscodeintellicode1.2.5 vscode-java-debug0.25.0 vscode-java-dependency0.9.0 vscode-java-pack0.8.1 vscode-java-test0.22.1 vscode-maven0.21.0 change-case1.0.0 vscode-wpilib2020.2.2 viml0.0.2 material-theme3.2.3 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Isn't this an expected behavior? As it only happens with keys that can be used in combinations (Alt, Ctrl, Shift, Win ecc;)
Well I felt like that if I just press Ctrl and Alt it should say Ctrl+Alt instead of Ctrl+Alt+ as if some other letter had been pressed
Also, I can work on this issue if necessary
Verification: (Windows only) Enable Press and confirm that is displayed on the screen and not . Press and confirm that is displayed on the screen.
Change:
} .monaco-workbench .panel.integrated-terminal .xterm-viewport::-webkit-scrollbar-thumb { <ins> min-height: 20px; </ins> background-color: inherit; }

Discussion:
Testing save this file as UTF8 with bom (I think it is already) configure run run Obseve: the scrollbar slider becomes very small and it is difficult to grab it with the mouse It would be nice if the mouse cursor would not be an or if it would give hover feedback: !
I'd like to pick this up, if possible.
Change:
"tas-client-umd": "0.1.6", "vscode-oniguruma": "1.6.1", "vscode-textmate": "7.0.1", <del> "xterm": "5.1.0-beta.49", "xterm-addon-canvas": "0.3.0-beta.23", </del> <ins> "xterm": "5.1.0-beta.61", "xterm-addon-canvas": "0.3.0-beta.26", </ins> "xterm-addon-search": "0.11.0-beta.7", <del> "xterm-addon-unicode11": "0.5.0-beta.1", "xterm-addon-webgl": "0.14.0-beta.32" </del> <ins> "xterm-addon-unicode11": "0.5.0-beta.5", "xterm-addon-webgl": "0.14.0-beta.38" </ins> } }

Discussion:
Issue Type: <bPerformance Issue</bEver since I got this M1 mac with apple silicon, any scrolling I do in VSCode is super choppy and laggy. To reproduce it on my machine I just need to open an editor with a scrollbar or a terminal with some history and scroll quickly up and down. VS Code version: Code 1.69.2 (, 2022-07-18T16:32:39.000Z) OS version: Darwin arm64 21.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryProcess Info</summary</details<details<summaryWorkspace Info</summary</details<details<summaryExtensions (11)</summaryExtensionVersion ------ prettier-vscode9.5.0 go0.35.1 githd2.3.3 vscode-docker1.22.1 python2022.10.1 vscode-pylance2022.8.10 jupyter2022.6. jupyter-keymap1.0.0 jupyter-renderers1.0.9 vsliveshare1.0.5669 vscode-yaml1.9.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Can you do a performance profile in devtools (Help Toggle Developer Tools) and upload it here? !
Sure, attached.
Hey this issue might need further attention. you can help us out by closing this issue if the problem no longer exists, or adding more information.
There's an abnormal about of garbage collection in that profile which I've never seen before: !
what sort of monitor are you connected to? Could you also open devtools via the Help menu and run in the console? My guess is your font size is so large that the terminal's texture atlas is thrashing and redrawing all glyphs almost every frame.
Upstream issue tracking the texture cap problem:
This one can only be verified by the
<!-- 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!

I'll mark this issue as verified as part of . Please file a new issue if the bug continues to occur on the latest Stable and/or Insiders versions of VS Code.
Change:
})); toDispose.push(window.onDidChangeActiveTextEditor(handleActiveEditorChange)); <del> let handleRetrySchemaCommand = () => { </del> <ins> let handleRetryResolveSchemaCommand = () => { </ins> if (window.activeTextEditor) { <del> client.sendRequest(ForceValidateRequest.type, window.activeTextEditor.document.uri.toString()); statusBarItem.text = '$(watch)'; </del> <ins> schemaResolutionErrorStatusBarItem.text = '$(watch)'; const activeDocUri = window.activeTextEditor.document.uri.toString(); client.sendRequest(ForceValidateRequest.type, activeDocUri).then((diagnostics) => { const schemaErrorIndex = diagnostics.findIndex(candidate => candidate.code === /* SchemaResolveError */ 0x300); if (schemaErrorIndex !== -1) { // Show schema resolution errors in status bar only; ref: #51032 const schemaResolveDiagnostic = diagnostics[schemaErrorIndex]; fileSchemaErrors.set(activeDocUri, schemaResolveDiagnostic.message); } else { schemaResolutionErrorStatusBarItem.hide(); } schemaResolutionErrorStatusBarItem.text = '$(alert)'; }); </ins> } }; <del> toDispose.push(commands.registerCommand('_json.retrySchema', handleRetrySchemaCommand)); </del> <ins> toDispose.push(commands.registerCommand('_json.retryResolveSchema', handleRetryResolveSchemaCommand)); </ins> client.sendNotification(SchemaAssociationNotification.type, getSchemaAssociation(context)); });

Discussion:
testing : Yes, there is now a warning icon in the status bar, but it is difficult to understand its purpose: For a json scheme url with a non-existing hostname the hover message shows this: ! For a json scheme url with a non-existing version number the hover message shows this: ! In both cases the error shown is too low-level and the message does not explain that the status refers to the json scheme of the current editor contents.
FYI
Looks like I misinterpreted what kind of messages I'd get from the backend, sorry for that! We could resort to showing a generic message like 'Unable to resolve JSON schema from (url)', which would probably be sufficient for most issues. I also considered logging the error to console (don't know your policy on that), but if we get whole pages in the error message, that's not an option. Displaying a generic message with the URL only would also Otherwise I guess we'd need to parse the error message to find out which kind and display a meaningful message, but that doesn't seem right. Another implication of this is that we'll probably have to re-add at least one layer of error description to vscode-languageservice-json - I always had a prefix with something like "Unable to resolve (something)", but that might have been a code reloading issue or specific to the way I was testing, by cutting the Internet connection and blocking DNS resolutions. Let me know if a generic error message defined only in the client would work.
That's fine. Users don't really see logs.
I can repro with this setting:
Change:
this._inFlightRequests.set(extensionId, inFlightRequests); try { <del> await session; </del> <ins> const s = await session; return s; </ins> } finally { const requestIndex = inFlightRequests.findIndex(request => request.scopes === sortedScopes); if (requestIndex > -1) {

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: an extension that does this: 'll notice that is though it should exist because we created it on line 1. This is because we cache the session id based on the provider id & extension name but really we should be caching them based on provider id, extension name, AND SCOPES. This will allow the 3rd time to find the session created in the first line.
Verification steps: The code session3 should not be undefined.
is your solution to this issue the reason that the Insiders builds have started bugging me at least once a day to sign into GitHub? With four windows open, each with two extensions that want a GitHub token (GitLens and GitHub Issues and Pull Requests), I have to generate 8 tokens to make VS Code stop bugging me... at which point it almost always discovers a VS Code update, and often we do the dance again after it restarts.
(And never mind, I see it was, and I see you fixed it!)
Reopening this because I reverted the change that fixed it.
just checking to see if there were any updates on this issue?
haven't had a chance to revisit this. You can take a look at my commit if you'd like. The problem I needed to address is migrating from the old storage keys to the new storage keys and my commit didn't handle that. Unfortunately, I have some other work I'm working on at the moment so I won't be able to look at this this month.
This appears to be fixed. Closing now
verification: original steps to repro. Instead, session3 should be defined.
Change:
} } const exactMatchTask = tasks.find(t => task && (t.getDefinition(true)?.configurationProperties?.identifier === task || t.configurationProperties?.identifier === task || t._label === task)); <del> const atLeastOneMatch = tasks.some(t => { if (task) { if (t._label.includes(task)) { if (!type || t.type === type) { return true; } } } else if (type && t.type === type) { return true; } return false; }); </del> if (exactMatchTask) { const id = exactMatchTask.configurationProperties?.identifier || exactMatchTask.getDefinition(true)?.configurationProperties?.identifier; if (id) {

Discussion:
! Here is me triggering run task, it pops up very slowly in todays insiders.
This is most likely because we have to wait for many things before we can provide tasks. Do you see in the status bar an extensions loading spinner?
No the spinner only flashes for like one millisecond. I notice it's slow only when in a repo with just NPM tasks.
which repo are you in there?
this has started happening recently for you, correct?
Yeah, within this iteration. I was on vacation so don't have a better time estimate
I am also experiencing this since updating to the latest VS code version (1.72)
can you share your file?
Change:
resourceFsPath = resourceFsPath.toLowerCase(); } <del> return startsWith(resource.fsPath, rootPath); </del> <ins> return startsWith(resourceFsPath, rootPath); </ins> }

Discussion:
VSCode Version: Code 1.41.0 (, 2019-12-11T18:37:42.077Z) OS Version: Windows_NT x64 10.0. Steps to Reproduce: a Markdown file on a network shared folder (ex.: ). that network shared folder to a drive letter in Windows (ex.: ). the Markdown file in VS Code using the mapped drive letter (ex.: ) and open its Side-by-Side Preview (). The preview should be correctly formatted. the same Markdown file in VS Code, but using the file's UNC path (ex.: ) and open its Side-by-Side Preview. The preview is incorrectly formatted. Does this issue occur when all extensions are disabled?: Yes Correct format (file opened through mapped drive letter): ! Wrong format (file opened through UNC path): !
I would like to work on this if possible.
There was a typo in the code was causing this. I have tested on Windows 10 with a file on a UNC path with the fix above and it is working fine.
Change:
import { LifecyclePhase } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { Registry } from 'vs/platform/registry/common/platform'; import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; <del> import { EditorDescriptor, Extensions as EditorExtensions, IEditorRegistry } from 'vs/workbench/browser/editor'; </del> <ins> import { DEFAULT_EDITOR_ASSOCIATION, EditorDescriptor, Extensions as EditorExtensions, IEditorRegistry } from 'vs/workbench/browser/editor'; </ins> import { Extensions as WorkbenchExtensions, IWorkbenchContribution, IWorkbenchContributionsRegistry } from 'vs/workbench/common/contributions'; import { ActiveEditorContext, Extensions as EditorInputExtensions, IEditorInputSerializer, IEditorInputFactoryRegistry } from 'vs/workbench/common/editor'; import { IViewsService } from 'vs/workbench/common/views';

Discussion:
When I select "Open with..." on a code search file, I would have expected to see our search editor in there as well: ! Slightly related, I would probably expect an entry "Settings Editor" when opening a file with...
Change:
} } <ins> if (verificationStatus === true) { this.logService.info(`Extension signature is verified: ${extension.identifier.id}`); } else if (verificationStatus === false) { this.logService.info(`Extension signature verification is not done: ${extension.identifier.id}`); } else { this.logService.warn(`Extension signature verification failed with error '${verificationStatus}': ${extension.identifier.id}`); } </ins> return { location, verificationStatus }; }

Discussion:
Continue installing the extension when signature verification fails - Report the error in telemetry CC
To verify: Install extension and make sure the extension is installed successfully. Also make sure you see following in the Shared log
Change:
err = true; } <del> if (!/yarn[w-.]*.js$|yarnpkg$/.test(process.env['npm_execpath'])) { </del> <ins> if (!/yarn[w-.]*.c?js$|yarnpkg$/.test(process.env['npm_execpath'])) { </ins> console.error('033[1;31m*** Please use yarn to install dependencies.033[0;0m'); err = true; }

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: master OS Version: mac-os Steps to Reproduce: -produces yarn-[...].cjs file in When switching yarn version from berry to classic the .cjs file extension is not recognized by while building. The preinstall script produces an error stating:
Change:
} const lang = await this.languageDetectionService.detectLanguage(this.textEditorModelHandle); <del> if (lang && !this.isDisposed()) { </del> <ins> const prevLang = this.getLanguageId(); if (lang && lang !== prevLang && !this.isDisposed()) { </ins> this.setLanguageIdInternal(lang, LanguageDetectionLanguageEventSource); const languageName = this.languageService.getLanguageName(lang); <del> if (languageName) { this.accessibilityService.alert(localize('languageAutoDetected', "Language {0} was automatically detected and set as the language mode.", languageName)); } </del> <ins> this.accessibilityService.alert(localize('languageAutoDetected', "Language {0} was automatically detected and set as the language mode.", languageName ?? lang)); </ins> } }

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.77.1 OS Version: Windows 10 Steps to Reproduce: some reason this is fine on documents which are already open when VSCode starts, so start by making a new file. Don't save it: once it has an extension, autodetection stops kicking in. some markdown. Eventually the screen reader announces that the language was autodetected. a single letter, pause, and the screen reader will announce that the language was autodetected as markdown again. Continue typing single characters and waiting and it continues to do the same. This also does the same if you just type normally, but the above is a repro that's likely to work even with typing echo on. I'd expect it to announce it only when it changes.
do you know who owns language detection?
owns it :) Good catch - it seems like we should announce only if the Detected Language changes.
Change:
public static readonly v380 = API.fromSimpleString('3.8.0'); public static readonly v381 = API.fromSimpleString('3.8.1'); public static readonly v390 = API.fromSimpleString('3.9.0'); <del> public static readonly v400rc = API.fromSimpleString('4.0.0-rc'); </del> public static readonly v400 = API.fromSimpleString('4.0.0'); <ins> public static readonly v401 = API.fromSimpleString('4.0.1'); </ins> public static fromVersionString(versionString: string): API { let version = semver.valid(versionString);

Discussion:
Issue Type: <bBug</brepo your user tsdk to use this version, for example: load the VS Code workspace (making sure you are using your user TS version) a file in and try getting the document outline Bug Big delay. This is because two full TS Servers are being spawned instead of a syntax only server + full server (see memory usage in screenshot): <img width="1079" alt="Screen Shot 2020-08-11 at 3 13 33 PM" src="https://user-"VS Code version: Code - Insiders 1.48.0-insider (, 2020-08-11T10:13:04.551Z) OS version: Darwin x64 19.6.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Seems like this was caused by
For verification, try the following cases: Using TS 3.9.7 Using TS 4.0.1-rc Using TS Using an old TS version like 3.5 (older versions don't support the syntax server at all) All should load the document symbols quickly even while the loading spinner is showing You can use the same global install in all cases, just make sure to reload VS Code each time
Assigning this to july milestone since it is a candidate.
following your steps I have verified that the outline get loaded quickly, however I still see two tsservers spinning up when I open the process explorer. If I understood correctly this is by design, since only one of them has a large memory usage. I have verified for TS: 3.9.7, 4.0.1-rc. ts 3.5 Thus adding verified label !
Change:
private isBuilt = false; private readonly stopActionViewItemDisposables = this._register(new DisposableStore()); <ins> /** coordinate of the debug toolbar per aux window */ private readonly auxWindowCoordinates = new WeakMap<CodeWindow, { x: number; y: number | undefined }>(); </ins> constructor( @INotificationService private readonly notificationService: INotificationService,

Discussion:
So that you know that you are debugging. //cc
I'm not sure on this, personally I would find it kind of annoying to have the toolbar on all windows. Maybe it's a setting, or can be dragged between windows? (Is there reusable cross-window drag logic yet?)
To clarify: not visible on all windows at the same time, but visible on the window that has focus maybe? Otherwise, it will be quite hard to step through a file using mouse in floating windows?
I think having it appear in the active window (when in floating mode) is good.
We solved this issue for quick open where we also want to appear it at the window that has focus. For that, there is which will always be the right container to put global UI elements and is derived from the currently active window. There is a event that can be used to reparent the UI element live.
Thanks!!!
Verification: Start debugging, and drag an editor out to an aux window Make sure the debug toolbar appears on whichever window has focus The debug toolbar should reappear in the same place per-window as you focus it
Change:
// options and group to use accordingly if (picked) { <ins> // If the user selected to configure default we trigger this picker again and tell it to show the default picker if (picked.item.id === EditorOverrideService.configureDefaultID) { return this.doPickEditorOverride(editor, options, group, true); } </ins> // Figure out target group let targetGroup: IEditorGroup | undefined; if (picked.keyMods?.alt || picked.keyMods?.ctrlCmd) {

Discussion:
When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc