jiebi/CodeConvo huggingface dataset:
Change:
{ "name": "code-oss-dev", "version": "1.82.0", <del> "distro": "49cc0fbc0a8e222bcce2a7c3bf62e0d23f20d258", </del> <ins> "distro": "2100ad274ed566f978bb917f327b3d99f95d59f2", </ins> "author": { "name": "Microsoft Corporation" },

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?: N/A (remote extensions are needed) <!-- 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.81.0 (Universal) and 1.82.0-insider (Universal) OS Version: MacOS 13.3.1 (22E261) [Ventura] Steps to Reproduce: a repository with a devcontainer from GitHub Codespaces (either in browser VS Code, or desktop) at the Source Control tab - it says "Scanning folder for git repositories…" I have seen this issues before months back, and it was fixed in Insiders and subsequently the release version - but it is back again and very frustrating. I have a minimal repo here - you will need to create a Codespace to see the issue (or choose a different devcontainer workflow). The issue could be to do with the docker image used, I think last time there was some suggestion of a problem with Alpine (or Alpine containers), and I believe the Jekyll container is based on Alpine. too.
it looks like has resurfaced. I am able to reproduce with the latest Insiders release.
Very likely candidate , will investigate tomorrow.

Steps for verification: Reopen in a container Verify server launches and integrated terminal works fine
I've checked in the latest Insiders release and the same bug seems to still be present when using GitHub Codespaces (both in web version of VS Code insiders, and desktop version of VS Code insiders when connecting to the Codespace) Version: 1.83.0-insider (Universal) Commit: Date: 2023-09-13T05:34:48.836Z Electron: 25.8.0 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin x64 22.4.0
the alpine servers run fine with the provided container configuration, however the git scm is hanging for a different reason can you please look into it
I have created a new Codespace on the linked repository and I am still able to reproduce the problem. As far as I can tell the extension how is completely busted as running "Show Running Extensions" is empty. In the Window output log I see the following: If I look at the Git extension I see the following: !
Ah missed the logs, is based on whereas our server alpine modules are built on . We don't plan to revert the alpine version as is reaching EOL I am closing this as designed, please update the jekyll container to use
Change:
"vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0-beta.56", </del> <ins> "xterm": "4.19.0-beta.58", </ins> "xterm-addon-search": "0.9.0-beta.39", "xterm-addon-serialize": "0.7.0-beta.12", "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0-beta.36", "xterm-headless": "4.19.0-beta.56", </del> <ins> "xterm-addon-webgl": "0.12.0-beta.37", "xterm-headless": "4.19.0-beta.58", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },

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 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: Version: 1.67.2 OS Version: macOS 12.4 My project uses unicode box characters to render scrollbars in the terminal. They don't render as expected in the vscode terminal. Here's the scrollbars in the VSCode terminal: https://user- Here's how the scrollbars look in iTerm on MacOS (and other terminal emulators): https://user- It looks as though these box characters render with the wrong color. The border around the window above is also rendered with the same box characters, and produces a darker color in VSCode. Steps to Reproduce: I've isolated a string which demonstrates the issue (in Python) This produces the following in iTerm: <img width="588" alt="Screenshot 2022-05-31 at 09 12 06" src="https://user-"And in VSCode: <img width="588" alt="Screenshot 2022-05-31 at 09 15 26" src="https://user-"
Another issue caused by 1: ! 5: !
We should also exclude box drawing characters from the setting, anything decorative.
Upstream
After fix: ! Marking as verified.
You guys are awesome.
Change:
this._suggestTips(); this._suggestWorkspaceRecommendations(); <ins> // Executable based recommendations carry out a lot of file stats, so run them after 10 secs // So that the startup is not affected setTimeout(() => this._suggestBasedOnExecutables(this._exeBasedRecommendations), 10000); </ins> } getWorkspaceRecommendations(): TPromise<string[]> {

Discussion:
In the renderer we want to stay away from sync fs API calls to because each call will stop the VM from doing anything. We should try to use the async fs APIs. The code in question is:
What about ?
yes, I reported those at the same time I reported this one via
There about 20 files that I need to run the checks on (this will definitely grow). Assuming there are about 20 paths in the PATH env variable, that is about 400 file checks to make in the worst case scenario If I do all of this async, thats about 400 async calls made at the same time. This can have an adverse affect as well correct? Or it doesnt matter at all?
anything is better than doing it sync, especially if you are stat'ing 400 files which probably means that the user cannot do anything for a couple of 100ms. We have  that allows to batch resolve. my 2 cents: having to stat 400 files for a feature seems wrong to me, especially if this blocks a piece of UI from working properly. At the very minimum this should run in the background, maybe buffered and not block any UI from showing up.
Change:
import { coalesce } from 'vs/base/common/arrays'; import { DeferredPromise } from 'vs/base/common/async'; import { VSBuffer } from 'vs/base/common/buffer'; <ins> import { ResourceMap } from 'vs/base/common/map'; </ins> import { parse } from 'vs/base/common/marshalling'; import { Schemas } from 'vs/base/common/network'; import { isWeb } from 'vs/base/common/platform';

Discussion:
Type: <bBug</bSame steps as with . VS Code version: Code - Insiders 1.74.0-insider (, 2022-11-11T05:19:14.666Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
<!-- 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:
private updateCommentBody(body: string | IMarkdownString) { this._body.innerText = ''; <del> if (this._md) { this._body.removeChild(this._md); this._md = undefined; } </del> <ins> this._md = undefined; </ins> if (typeof body === 'string') { this._body.innerText = body; } else {

Discussion:
Comments cannot be updated using the comment API. Specifically, anything that causes the comment body to change will throw an error:
Change:
return; // refresh already triggered } <ins> const elements = this.debugService.getModel().getReplElements(); const delay = elements.length > 0 ? Repl.REFRESH_DELAY : 0; </ins> this.refreshTimeoutHandle = setTimeout(() => { this.refreshTimeoutHandle = null; this.tree.refresh().then(() => {

Discussion:
When clicking the clear output action, the output is only cleared after 1 second. !
Every console update is done with a 0.5s delay to not kill the tree with too many updates Closing this as designed as this is the limitation we will have to live with as long as we use the tree. In the next couple of milestones I plan to investigate into using the editor instead of the tree.
...
Created a PR with a fix.
Great fix - thanks!
Change:
return snippet; } <ins> function getParentDocumentUri(document: vscode.TextDocument): vscode.Uri { if (document.uri.scheme === Schemes.notebookCell) { for (const notebook of vscode.workspace.notebookDocuments) { for (const cell of notebook.getCells()) { if (cell.document === document) { return notebook.uri; } } } } return document.uri; } </ins>

Discussion:
Type: <bBug</bnotebook an image from the workspace into a markdown cell Bug this inserts the full uri, such as It should insert the relative path instead VS Code version: Code - Insiders 1.71.0-insider (Universal) (, 2022-08-10T05:18:38.020Z) OS version: Darwin x64 21.6.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
this.feedback = ''; this.sentiment = 1; <ins> this.maxFeedbackCharacters = this.feedbackService.getCharacterLimit(this.sentiment); </ins> this.feedbackForm = null; this.feedbackDescriptionInput = null;

Discussion:
Due to being appended to it !
this looks like a good place to start off, is this something I can help with?
:+1: it's marked help wanted which probably means won't get to it any time soon.
Go for it, this is a great issue to start contributing to Code. Let me know if you need any help.
Awesome, I am on it! :)
Please review :) Couldn't find any unit tests for this, did I miss it?
Change:
newItems.push(e.item); } <ins> Object.entries(newValue).forEach(([key, value]) => { // value from the scope has changed back to the default if (scopeValue[key] !== value && defaultValue[key] === value) { delete newValue[key]; } }); const newObject = Object.keys(newValue).length === 0 ? undefined : newValue; </ins> if (template.objectCheckboxWidget) { <del> Object.entries(newValue).forEach(([key, value]) => { // A value from the scope has changed back to the default. // For the bool object renderer, we don't want to save these values. if (scopeValue[key] !== value && defaultValue[key] === value) { delete newValue[key]; } }); </del> template.objectCheckboxWidget.setValue(newItems); } else { template.objectDropdownWidget!.setValue(newItems); } <del> template.onChange?.(newValue); </del> <ins> template.onChange?.(newObject); </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?: No Problem with default extension settings. <!-- 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.64.2 OS Version: Windows 10 Pro x64 Steps to Reproduce: Behavior before updating to 1.64 version (and it's an expected result) I create extension settings in in contributes section (according to ) user opens Settings -Extensions -~someExtension~Settings user cannot delete default settings Behavior after updating to 1.64 version (and it's an actual result) I create extension settings in in contributes section (according to ) user opens Settings -Extensions -~someExtension~Settings user can delete default settings (it's a 1st issue) if get all settings by vscode.workspace.getConfiguration() - we get these deleted default settings (it's a 2nd issue) As result, the user deleted default settings, but it's still there, but not visible Video:
I think it is fine for the user to delete default settings to change the setting value away from the default. That change comes from But, the deleted settings still showing up when we fetch the configuration doesn't seem correct.
It is because of merging strategy of object value settings. For eg merging following objects results to So, this is expected. Not sure what changed in UI so leaving to you
Verification steps: and run the extension to the JSON Settings editor. the following: over to the GUI Settings editor. for the setting . that a row with the key still shows up.
Change:
ui.message.style.display = visibilities.message ? '' : 'none'; ui.progressBar.getContainer().style.display = visibilities.progressBar ? '' : 'none'; ui.list.display(!!visibilities.list); <del> ui.container.classList.toggle('show-checkboxes', visibilities.checkBox); </del> <ins> ui.container.classList.toggle('show-checkboxes', !!visibilities.checkBox); </ins> this.updateLayout(); // TODO }

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: Ubuntu 20.04.1 When an extension assigns a value to an input box's property, the box slightly moves to the right or left (See the screen capture below). Note that it's not because of text length changes or other text rendering details. Even re-assigning the property with a constant value makes the shaking happen. I've made a repo to help verify this on your side. As of my observations, the problem was not present in VS Code v1.72. It's now happening in v1.74 (I'm not sure about v1.73 since I've skipped that update). this repo (it's a sample extension): the cloned directory in VS Code. debugging by pressing F5. the opened window, open the command palette, find the "Hello World" command and invoke it. should now see a shaking input box, like this: ! The extension just creates an input box, and repeatedly updates the title of the input box with a constant value:
I've pushed a fix for that.
<!-- 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:
} }, this)); <ins> this._register(extensionEnablementService.onEnablementChanged(platformExtensions => { if (this.getAutoUpdateValue() === 'onlyEnabledExtensions' && platformExtensions.some(e => this.extensionEnablementService.isEnabled(e))) { this.checkForUpdates(); } }, this)); </ins> this.queryLocal().then(() => { this.resetIgnoreAutoUpdateExtensions(); this.eventuallySyncWithGallery(true);

Discussion:
Today I noticed that VSCode updates and installs extensions even if they are disabled. In fact, I was reminded of a couple of extensions I no longer use by the hundreds of megabytes downloaded in the background. Could you consider adding this as a toggle in settings or disabling this behavior altogether?
I see your point. But what is the reason behind having such extension installed and disabled, instead of uninstalling it?
So that they don't update in the background and waste traffic on my metered connection ;) I switch between a lot of languages and runtimes regularly. I use VSCode for C++, C#, F#, PHP, Python, JS/Flow, Processing, GLSL/HLSL, Arduino and others, but I like to keep a "working set" of supporting extensions, depending on the project I'm working on. This comes down to the question "what does disabling extensions actually do", besides declutter the list? Initially I thought this would help with memory usage and startup time, but I don't believe that's really the case. If there's no practical use for disabling, maybe that option should be deprecated in favor of just uninstalling them.
Yes, Disabling helps you in creating a working set. But I see your point and agreed that not auto updating a disabled extension makes sense.
Know that disabled extension can also still popup a notification as well. I'm sure the C++ extension (ms-vscode.cpptools) occasionally (not sure when exactly) asks you to enter a survey even when the extension is disabled.
This should not happen. Please file a separate issue with steps to repro.
I will take a look at this one and follow up with a pull request.
I was wondering about the current status of this issue? If this issue still persists, I would love to contribute and try to resolve it. If this is the case, I would highly appreciate a code pointer to the update procedure, as I am fairly new to this project.
I have not had the chance to look into this. is this something that we still want to pursue?
It looks to me like you have already implemented the desired changes a few days ago?
This is not yet supported and contribution is very much appreciated. Code pointer: Auto update of extensions happen here
Thank you I will look into it. I would say, we just out the disabled extensions and do not return them.

Do you have something different / more elaborate in mind? And do you happen to know an easy way to test this function (i.e. forcing an auto-update)?
I was able to implement this feature and also a configuration to let users decide on whether disabled extensions should be updated. The PR can be found at .
Change:
} protected override get webviewContentEndpoint(): string { <del> return `${Schemas.vscodeWebview}://${this.id}`; </del> <ins> return `${Schemas.vscodeWebview}://${this.iframeId}`; </ins> } /**

Discussion:
(observed for installed extensions, but I think it is slower for all extensions) Insiders: ! Stable: !
cc
Seeing similar slowness in Getting Started, cc is it maybe a general markdown issue?
Yes, I can confirm that markdown rendering has slowed down. Hence assigning back to
Doesn't seem to happen for the markdown preview which suggests to me something in core with markdown rendering. Let me know if you notice this for any other webviews
I have a potential fix but don't yet understand why it works To summarize: when loading webviews, we load a file called from the disk. This file is very small and should be loaded almost instantly. And it is for normal webviews However for the extension editor, the network request for this file is in the state for almost a full second. I've confirmed that our code to serve this file runs very quickly (however it is only hit after the stall) so the stall must be happening somewhere else: Unlike other webviews, the extension editors all share a single internal webview identifier. This means that the requests look like: However if I change the extension editors to also have unique ids for the requests, the stall disappears My best guess right now is there's a cache lookup or something that causes the stall (I thought it could be the service worker, but both cases have the service worker enabled and the service worker also only sees the fetch after the stall)
cc
Also porting fix to November release
There is a limit on the number of socket connections per host, currently it is set to 6 in all chromium based browsers ;l=43-54, it is very likely possible that we hit this when using the same origin for extension editors. I can confirm if this is the case by taking a net log with . Edit: custom protocol requests don't show up in the above netlog trace, I will confirm with this in runtime trace and follow-up here.
Change:
const resultExpression: ParsedStringPattern = function (path: string, base?: string, hasSibling?: (name: string) => boolean | Promise<boolean>) { let name: string | undefined = undefined; <ins> let resultPromises: Promise<string | null>[] | undefined = undefined; </ins> for (let i = 0, n = parsedPatterns.length; i < n; i++) {

Discussion:
While reviewing some code in I noticed potential issues: and Will wrongly stop the loop when the result is a even when that result resolves to . Would be good to have a test case for this too.
I think you the support for for the expression matching via , do we really still need this? I feel this makes glob matching overly complicated. Checking on usages, I think search component uses it to lazily resolve children...
PR:
Are you suggesting to resolve children before doing the glob matcher? It would be a lot faster to avoid matching children until you need them. I don't like the flexible typing of this though. It should be explicitly sync or not.
Change:
* The UI-visible count of {@link SourceControlResourceState resource states} of * this source control. * <del> * Equals to the total number of {@link SourceControlResourceState resource state} * of this source control, if undefined. </del> <ins> * If undefined, this source control will * - display its UI-visible count as zero, and * - contribute the count of its {@link SourceControlResourceState resource states} to the UI-visible aggregated count for all source controls </ins> */ count?: number;

Discussion:
Issue Type: <bBug says of the optional property: I'm finding that this doesn't happen. To reproduce: the source-control-sample folder, build it () and run it () to SCM view and see that the (0) badge appears on the provider line (JSFiddle #demo) one of the demo documents, save the change, and confirm that the (1) badge appears on the Changes group and on the provider. the Extension Development Host window. the extension sample source, and comment out this line: the test again. :bug: the provider line count remains zero even when a change is made to a demo file. This is not a 1.54 regression; it also exists in 1.53 VS Code version: Code - Insiders 1.54.0-insider (, 2021-02-26T05:13:29.656Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
I think we should probably just update the docs here to say that the SCM control determines the count. thoughts?
So how about using this wording in Would you like a PR from me?
I think this is a quick win in the current issue grooming iteration because I have already submitted a PR to fix it in documentation. Please consider merging it.
thanks for the nudge. Merged!
/verified Confirmed change present in main. Won't appear in online doc at until 1.62 ships.