jiebi/CodeConvo huggingface dataset:
Change:
} // Consolidate (support *.json files in the workspace settings folder) <del> this.consolidate(); </del> <ins> this.consolidate(settingsConfiguration); </ins> return this._cache; }

Discussion:
apply the patch that logs fs calls which is included below run open a folder and open a single css file don't modify it (i.e. avoid hot exit) and reload the window <details<summaryPatch</summary</detailsObserve the following fs calls that occur before the first editor rendering: IMHO the following fs calls should be postponed: [ ] [ ] [ ] [x] I also noticed that we read the following files twice: [ ]
I have no clue what we use install source for, but lots of digging reveals this commit:
Updating the list - is only read once.
is read twice because First time during initialising configuration without user tasks User tasks is read later when there is an idle time - by reloading user configuration - during which settings and tasks files are read.
Install source is a common telemetry property. It can be set after installing VS Code. It came as an ask from Anaconda, to know how many installations came from them. We decided to go with creating a new file rather than updating existing files, to avoid scenarios where we'd break important files (eg or ). I don't have great ideas to work around this other than refactoring the code until the first telemetry event gets submitted, which is still pretty early. Will ask around to learn whether this common telemetry property is still in use.
is gone!
Tasks and Launches are part of Config and they are accessed sync from config service. In order to prevent reading these files during start up we should loading them until they are needed. (probably workbench restored phase) an assertion to make sure no component is reading them until then
This needs considerable refactoring and I do not think it is worth a change for the gain given that these files are resolved in parallel. Hence marking this as no fix.
Change:
import { MarkdownRenderer } from 'vs/editor/contrib/markdownRenderer/browser/markdownRenderer'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { ICommentService } from 'vs/workbench/contrib/comments/browser/commentService'; <del> import { LayoutableEditor, STARTING_EDITOR_HEIGHT, SimpleCommentEditor, calculateEditorHeight } from 'vs/workbench/contrib/comments/browser/simpleCommentEditor'; </del> <ins> import { LayoutableEditor, MIN_EDITOR_HEIGHT, SimpleCommentEditor, calculateEditorHeight } from 'vs/workbench/contrib/comments/browser/simpleCommentEditor'; </ins> import { Selection } from 'vs/editor/common/core/selection'; import { Emitter, Event } from 'vs/base/common/event'; import { INotificationService } from 'vs/platform/notification/common/notification';

Discussion:
window a comment :bug: as you can see from the scrollbar, the comment text doesn't fill the full editor !
<!-- UNABLETOLOCATECOMMITMESSAGE issue --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased
closedWith
Change:
import { ISaveOptions, IRevertOptions } from 'vs/workbench/common/editor'; import { CancellationToken } from 'vs/base/common/cancellation'; import product from 'vs/platform/product/common/product'; <ins> import { IActivity, IActivityService } from 'vs/workbench/services/activity/common/activity'; </ins> export class TestTextResourcePropertiesService implements ITextResourcePropertiesService {

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 quickPick = this._quickInputService.createQuickPick<KernelQuickPickItem>(); const quickPickItems = this._getKernelPickerQuickPickItems(notebook, matchResult, this._notebookKernelService, scopedContextKeyService); <del> if (quickPickItems.length === 1 && supportAutoRun(quickPickItems[0])) { return await this._handleQuickPick(editor, quickPickItems[0]); </del> <ins> if (quickPickItems.length === 1 && supportAutoRun(quickPickItems[0]) && !skipAutoRun) { return await this._handleQuickPick(editor, quickPickItems[0], quickPickItems as KernelQuickPickItem[]); </ins> } quickPick.items = quickPickItems;

Discussion:
Testing microsoft/vscode-jupyter Open a new window where no kernels have been used Open the kernel picker, get the kernel source picker Click the back button The quick pick flashes closed/opened and shows the source picker again
Was trying the MRU out with my new machine and ran into the same thing. Just adding a few more comments: The progress bar makes it look like the process to find kernels just hangs I'd expect to see like the old experience feels unfinished--it's my first time picking a kernel for this project so I expect it to tell me to just !
Change:
}); } exports.config = { <del> version: product.electronRepository ? '22.4.5' : util.getElectronVersion(), </del> <ins> version: product.electronRepository ? '22.4.7' : util.getElectronVersion(), </ins> productAppName: product.nameLong, companyName: 'Microsoft Corporation', copyright: 'Copyright (C) 2023 Microsoft. All rights reserved',

Discussion:
This works on web e.g. but does not work in desktop, either with a desktop git clone or with RemoteHub. The last time this happened it was due to a regression in the list of enabled codecs for our Electron builds.
Sorry for the breakage, the changes from has not been to Electron = 22 versions yet. It will be addressed in new builds this week.
Addressed in
Reopening because of
Change:
options.frame = false; } <del> if (useWindowControlsOverlay(this.configurationService, this.environmentMainService)) { </del> <ins> if (useWindowControlsOverlay(this.configurationService)) { </ins> // This logic will not perfectly guess the right colors // to use on initialization, but prefer to keep things

Discussion:
I tried enabling it in my Code-OSS settings but it didn't seem to work. The sentence from that I quoted make me think it had been hardwired off in Code-OSS. I haven't searched the codebase yet though. Originally posted by in
OSS does seem to have the WCO disabled. says that WCO was disabled in OSS due to upstream issues, but there's been a bunch of fixes recently, so it's probably OK to enable it again.
Verification steps: the WCO in OSS by enabling the setting. VS Code when prompted and change the colour theme. Windows 11, one can verify the WCO has been enabled by checking that the snap layout UX is available. On Windows 10, one can verify the WCO has been enabled by switching through colour themes and checking that the area with the minimize/maximize/close buttons updates its colours before the rest of the titlebar does.
Change:
} else { const uri = part instanceof ChatRequestDynamicVariablePart && part.data.map(d => d.value).find((d): d is URI => d instanceof URI) || undefined; <del> const title = uri ? this.labelService.getUriLabel(uri, { relative: true }) : ''; </del> <ins> const title = uri ? encodeURIComponent(this.labelService.getUriLabel(uri, { relative: true })) : ''; </ins> <del> result += `[${part.text}](${variableRefUrl}${title})`; </del> <ins> result += `[${part.text}](${variableRefUrl}?${title})`; </ins> } }

Discussion:
We still have the check in place to disable these in the stable build...
Can be verified by code review, or once we have a stable build.
Verifying on 0.11.1 Edit: I see the suggestion is enabled, but the behaviour is off to me. Discussing offline. Edit 2: Discussed. Marking as verified.
Change:
verbositySettingKey: AccessibilityVerbositySettingId.Chat, provideContent(): string { return responseContent; }, onClose() { <ins> verifiedWidget.reveal(focusedItem); </ins> if (chatInputFocused) { verifiedWidget.focusInput(); } else { <del> verifiedWidget.reveal(focusedItem); </del> verifiedWidget.focus(focusedItem); } },

Discussion:
chat the whole view 1 accessibility view. Nothing happens Only if I move focus to be on one exact element the command will work. We should make the command more flexibly, so it is not so strict with regards to focus. It should also work if I am on the Chat input, or on the whole Chat view. In those cases it should probably act as if the focus was on the last item.
also mentioned this, makes sense
AFAIK, one cannot focus the chat view without focusing either the list (item) or the input. So, to verify: focus the chat input that the accessible view shows the most recent response repeat the steps but with focus on an item - it should show that item
Thanks for fixing it, it is better than before. However now the help view always has the content of the last chat. Ideally it would respect the focused chat element, if none of the chat elements are focused then we should show the content of the last one in the accessibility help editor. Reopening this to hear what you think about this proposal. Thanks
that is working for me - could you pls attach a gif of what you're seeing?
Here's what I am seeing. It looks like the accessibility help always gets the content from the editor. Here's a gif: I might be doing something wrong !
Thanks - that's a bug, but different from this issue - to test this issue, you'll want to use . I'll make a new one to cover that
Thanks! Here's the alt+f2 behaviour. It always show the last content. So it also seems to be off !
Hm, that's very strange - I cannot reproduce but will try again
I see you are focusing a request - in that case, it will just show the last response by design
ok I can repro now, thanks!
I tried with latest insiders and now I see the following: When the focus is on the last element or on the input box works as expected If the focus is anywhere else, is a no-op looks like we still have one case that we did not cover. Should we reopen? Can you repro? Thanks
Thanks for testing Where is your focus when you are seeing a ? I cannot repro unless my focus is on a request, which is expected.
You are correct, the focus is on the request.

Why is that an expected no-op? Why do we treat request and response differently?
I consulted with JooYoung about this and he agreed that since the user entered the request, they don't need to inspect it closely.
It would be great if you could verify this particular issue - happy to make a new one if you disagree about the request no-op
I have the verified label. As for request and response behaving differently, I will open a new issue.
Change:
assert.strictEqual(tabs[3].input.uri.toString(), commandFile.toString()); }); <del> test('Tabs - Ensure tabs getter is correct', async function () { </del> <ins> (env.uiKind === UIKind.Web ? test.skip : test)('Tabs - Ensure tabs getter is correct', async function () { </ins> // Reduce test timeout as this test should be quick, so even with 3 retries it will be under 60s. this.timeout(10000); // This test can be flaky because of opening a notebook

Discussion:
Honestly you might want to avoid touching a notebook (or maybe any webview editor) in an integration test. We have had a lot of issues with webviews in integration tests and don't run notebook tests in the web. Test that with a unit test if possible
It's hard to easily test this with unit tests because there are a lot of editor setup and other stuff that goes on to ensure the end to end tab model is correct. I can remove the notebook piece but then I worry if notebooks or any other non-text type could regress and we wouldn't know
You could also just skip the test in web
Again, in web
Also in web for
/closedWith
Change:
// change part size along the main axis public resizePart(part: Parts, sizeChange: number): void { <del> const visibleEditors = this.editorService.getVisibleEditors().length; </del> <ins> const visibleEditorCount = this.editorService.getVisibleEditors().length; const panelPosition = this.partService.getPanelPosition(); </ins> const sizeChangePxWidth = this.workbenchSize.width * (sizeChange / 100); const sizeChangePxHeight = this.workbenchSize.height * (sizeChange / 100);

Discussion:
Code / Insiders All OS Part resize logic with one editor and panel. Editor with focus, just panel does not resize. To be clear and honest, this is my logic bug that actually is independent and pre-existing from the vertical panel addition. My issue not ;-) The bug is more obvious with vertical panel. Steps to Reproduce: code with one editor, panel open , sidebar hidden editor, try Increase/Decrease commands - editor does not resize panel, try resize - panel resizes correctly Testing : I know you guys are testing and working on panel issues. While not a panel issued directly this bug is more noticeable with vertical panel so your guys call on PR integration... Fixed with PR
thanks for pointing this out and thanks for providing a PR. However since this behavior is already there in stable and since there are a lot of moving parts currently in the panel area I will postpone this to November. When we can discuss on how to best fix this and then I can also review you PR. Hope that makes sense. Thanks
Yup. I will try to get the fix for command support with split windows for the same time.
Change:
["[", "]"], ["`", "`"], ["_", "_"], <del> ["*", "*"] </del> <ins> ["*", "*"], ["{", "}"], ["'", "'"], [""", """] </ins> ], "folding": { "offSide": true,

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. --Currently, the Markdown supports surround with parentheses , square brackets , backtick, underscore, and asterisk. Selection surround support should also be extended to curly brace , single quote , and double quote . I can certainly fork and make a PR myself if that is all that's needed. Suggested: I'm submitting here after submitting on the extension and being informed this upstream change is needed.
These are all probably good to add. We support all of them in plain text files when I tested Please send a PR to add them when you have a chance
Hello, are you already working on a PR for this issue? If not, is it okay If I go ahead and take a stab at it?
Yes please do
Change:
return; } <del> this._currentResolveCodeLensSymbolsPromise = createCancelablePromise(token => { </del> <ins> const resolvePromise = createCancelablePromise(token => { </ins> const promises = toResolve.map((request, i) => {

Discussion:
Issue Type: <bBug</bTypeScript references code lenses the VS Code Code base, open the line: After type a comma then and re-type again Bug Suggestions take forever to come in Computing the references in TypeScript can potentially be expensive. This is caused because the method is not being as aggressively canceled when the document changes as I expect it to be (and as I believe it used to be) We can workaround this on the TS side but it seems like unexpected behavior /cc VS Code version: Code - OSS Dev 1.41.0 (Commit unknown, Date unknown) OS version: Darwin x64 18.7.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Adds a TS specific fix. Whenever the document changes, we now aggressively cancel all existing code lens requests against the TS server for that document
I believe nothing has changed here - at least not as far as my recent memory goes... Cancellation happens after 250ms which isn't aggressive but should also not be perceived as overly slow. Are those 250ms the delay you were seeing?
the delay is more like several seconds. It could be because we now provide references code lenses for object members, which adds a lot more references for TS to compute.
hm... but the delay/debounce on the by this... Does work happens on the extension host thread (not the tsserver-process) so that the cancellation doesn't come through until the event loop is free again?
Ok, so after more digging, I don't think is related to the debounce. Instead it seems some calls to are not ever canceled when the document changes. Here's the basic sequence I see on the extension host side: The issue is that the first batch of resolve requests (40-49) are not cancelled when they should be Resolving individual TS code lenses can take around a second in some cases
Nice find and kudos for digging through that code
Change:
import { Registry } from 'vs/platform/registry/common/platform'; import { ViewPaneContainer } from 'vs/workbench/browser/parts/views/viewPaneContainer'; import { defaultQuickAccessContextKeyValue } from 'vs/workbench/browser/quickaccess'; <del> import { IWorkbenchContribution, WorkbenchPhase, registerWorkbenchContribution2 } from 'vs/workbench/common/contributions'; import { Extensions as ViewExtensions, IViewContainersRegistry, IViewDescriptor, IViewDescriptorService, IViewsRegistry, ViewContainerLocation } from 'vs/workbench/common/views'; </del> <ins> import { Extensions as ViewExtensions, IViewContainersRegistry, IViewDescriptor, IViewsRegistry, ViewContainerLocation } from 'vs/workbench/common/views'; </ins> import { GotoSymbolQuickAccessProvider } from 'vs/workbench/contrib/codeEditor/browser/quickaccess/gotoSymbolQuickAccess'; import { AnythingQuickAccessProvider } from 'vs/workbench/contrib/search/browser/anythingQuickAccess'; import { registerContributions as replaceContributions } from 'vs/workbench/contrib/search/browser/replaceContributions';

Discussion:
I came across this: Can we by now remove it? Seems quite old:
Yes, this can be removed!
Change:
// First save through the editor service if we save all to benefit // from some extras like switching to untitled dirty editors before saving. let result: boolean | undefined = undefined; if (typeof arg1 === 'boolean' || dirtyWorkingCopies.length === this.workingCopyService.dirtyCount) { result = await this.editorService.saveAll({ includeUntitled: typeof arg1 === 'boolean' ? arg1 : true, ...saveOptions });

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.73.0-insider OS Version: Windows_NT x64 10.0. Auto Save by onFocusChange does not sync internal cache when direct quitting by 'X' button. Steps to Reproduce: settings: "Files: Auto Save" =onFocusChange a text file and save it somewhere. the file a little more. But this time, do not save or change focus and just press 'X' button directly to quit. the text file again with vscode. to save the file. Now you can see this error message: "Failed to save '...': The content of the file is newer." <img width="341" alt="image" src="https://user-"
That is weird, we trigger auto save on shutdown unless auto save is turned off: Does this still reproduce in all projects?
Oh nice I can reproduce, looks really like a bug.
Great catch!
Thank you for your response and effort on this issue!
<!-- 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
Change:
easy = 42; ||| <del> >**Tip:** You can also enable the checks workspace or application wide by adding |"javascript.implicitProjectConfig.checkJs": true| to your workspace or user settings and explicitly ignoring files or lines using |// @ts-nocheck| and |// @ts-expect-error|. Check out the docs on [JavaScript in VS Code](https://code.visualstudio.com/docs/languages/javascript) to learn more. </del> <ins> >**Tip:** You can also enable the checks workspace or application wide by adding |"js/ts.implicitProjectConfig.checkJs": true| to your workspace or user settings and explicitly ignoring files or lines using |// @ts-nocheck| and |// @ts-expect-error|. Check out the docs on [JavaScript in VS Code](https://code.visualstudio.com/docs/languages/javascript) to learn more. </ins> ## Thanks!

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.58.0 OS Version: Arch Linux x86_64 5.12.15-arch1-1 Steps to Reproduce: the VSCode interactive playground. down to the JavaScript Type Checking section. Description: The walkthrough section currently advises setting to get TS checks in JavaScript files. ! The property's been deprecated in favour of . ! The walkthrough should be updated to reflect the same.