jiebi/CodeConvo huggingface dataset:
Change:
([key, schema]) => ({ value: key, description: schema.description }) ); <del> let data: Record<string, unknown> = element.value ?? {}; if (element.setting.allKeysAreBoolean) { // Add on default values, because we want to display all checkboxes. data = { ...elementDefaultValue, ...data }; } </del> return Object.keys(data).map(key => { if (isDefined(objectProperties) && key in objectProperties) { <ins> const defaultValue = elementDefaultValue[key]; </ins> if (element.setting.allKeysAreBoolean) { return { key: {

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:
private _commentFormActions!: CommentFormActions; private _commentEditorActions!: CommentFormActions; private _reviewThreadReplyButton!: HTMLElement; <del> private _editorHeight = STARTING_EDITOR_HEIGHT; </del> <ins> private _editorHeight = MIN_EDITOR_HEIGHT; </ins> constructor( readonly owner: string,

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:
XtermScreen = 'xterm-screen' } <del> interface IDisposableDecoration { decoration: IDecoration; disposables: IDisposable[] } </del> <ins> interface IDisposableDecoration { decoration: IDecoration; disposables: IDisposable[]; exitCode?: number } </ins> export class DecorationAddon extends Disposable implements ITerminalAddon { protected _terminal: Terminal | undefined;

Discussion:
Currently you can disable them via: But this is not particularly easy and the decorations still end up rendering. We should have a switch that disables them outright, including adding them to xterm.
<img width="1111" alt="Screen Shot 2022-02-23 at 5 04 01 PM" src="https://user-"It is enabled even though shell integration is off... But thanks for the fix, now i can go back to using the integrated terminal! EDIT: the fix doesn't work, guess i'm stuck with iterm2 for now...
they're rectangles so you're probably on a pretty old build (1 week+?), updating will probably fix it for you.
are there any verification steps?
It's still unreleased, but use to disable them.
Change:
// Create toast with item and show const notificationList = this.instantiationService.createInstance(NotificationsList, notificationToast, { <ins> ariaRole: 'dialog', // https://github.com/microsoft/vscode/issues/82728 </ins> ariaLabel: localize('notificationsToast', "Notification Toast"), verticalScrollMode: ScrollbarVisibility.Hidden });

Discussion:
Environment Details: Application Name: Visual Studio Code Application Version: 1.38.1 (user setup) Commit: Electron: 4.2.10 10.11.0 OS: Windows_NT x64 10.0. Steps to Reproduce: any workspace with Extensions recommendations notification pops up Accessibility insights and track the control type for toast notification. type is tree when it is expected to be a dialog. Accessibility Impact: the control is called out as tree by screen reader which might be confusing.
It is true that each notification toast is a tree itself because that is the underlying widget we are using. We can possible change that if there is API from the tree level.
There is already a  in the AriaProvider which should be exposed in the . Not sure if you can use that one, or you need to introduce a new one or the current one will be enough? can you try it out?
this was not possible without tree changes (and also a bugfix where the tree would always set the aria role "tree", even if options were provided). Please review
I was able to verify this change, the toast now has a dialog role. One thing I noticed is that the contained still has . This doesn't cause issues with OS X voiceover, but we should keep an eye out on whether it confuses other screen readers.
Yeah, to change that would need additional support from the tree widget I think.
Please note that this should now be fixed properly via So the parent is a and each toast is a
Change:
return this._proxy.$getTunnels(); } <del> registerCandidateFinder(): void { // Every two seconds, scan to see if the candidate ports have changed; if (isLinux) { let oldPorts: { host: string, port: number, detail: string }[] | undefined = undefined; setInterval(async () => { const newPorts = await this.findCandidatePorts(); if (!oldPorts || (JSON.stringify(oldPorts) !== JSON.stringify(newPorts))) { oldPorts = newPorts; this._proxy.$onFoundNewCandidates(oldPorts.filter(async (candidate) => await this._showCandidatePort(candidate.host, candidate.port, candidate.detail))); return; } }, 2000); </del> <ins> private calculateDelay(movingAverage: number) { // Some local testing indicated that the moving average might be between 50-100 ms. return Math.max(movingAverage * 20, 2000); } async registerCandidateFinder(): Promise<void> { // Regularly scan to see if the candidate ports have changed. if (!isLinux) { return; } let movingAverage = new MovingAverage(); let oldPorts: { host: string, port: number, detail: string }[] | undefined = undefined; while (1) { const startTime = new Date().getTime(); const newPorts = await this.findCandidatePorts(); const timeTaken = new Date().getTime() - startTime; movingAverage.update(timeTaken); if (!oldPorts || (JSON.stringify(oldPorts) !== JSON.stringify(newPorts))) { oldPorts = newPorts; await this._proxy.$onFoundNewCandidates(oldPorts.filter(async (candidate) => await this._showCandidatePort(candidate.host, candidate.port, candidate.detail))); } await (new Promise<void>(resolve => setTimeout(() => resolve(), this.calculateDelay(movingAverage.value)))); </ins> } }

Discussion:
We have been seeing a bunch of remote issues where the remote extension host burns a lot of CPU. I think it is caused by our port scanning code, which executes even if the setting is false. See Possible issues: / Other: ? ? ? *
Looks like we need to work on our indentation and ensuring that we break lines once they go past the edge of the screen for the sake of readability
I could reproduce some increased CPU usage of the remote extension host using the project linked to i.e.
In insiders, you can now temporarily disable the port scanning code by adding this line to your .bashrc file, then restarting the VS Code server on your remote:
Once we have an insiders build I'll start commenting in each of the issues asking folks to try out the workaround in insiders.
Keeping open for now so that the issue can be found more easily.
Closing since the fix is available in insiders.
Verified that cpu usage was reasonable when running the petclinic app
Change:
import paths = require('vs/base/common/paths'); import { dirname, join } from 'path'; import { nfcall } from 'vs/base/common/async'; import fs = require('fs'); <ins> export function isRoot(path: string): boolean { return path === dirname(path); } </ins> export function readdir(path: string): TPromise<string[]> { return nfcall(extfs.readdir, path); }

Discussion:
In version 0.10.1 it is no longer possible to write to the root of a drive (which worked up to 0.9.1). When trying to save to e.g. , the following error message appears: Tested on Windows 7 Ultimate and Windows 10 Professional, US language, German region settings.
are you sure you can save there, can you try with nodepad?
Yes, I can write a text file with notepad. And I also tried other drives. What I found out in the meantime is that this happens only when creating a new file. Opening, editing and saving an existing file works correctly.
so you do Ctrl+N, type something and then try to save it to r: from the windows save dialog?
Exactly. The error message appears trying to use Save, Save As or (when creating multiple files), Save All.
is R: some drive created with subst or a real physical drive? I assume it is not the root drive where windows is installed?
R: is a RAM disk - so I suspected this to be the problem at first. That's why I checked on other, "real" drives (except the system drive C:), and I can reproduce the behavior.
What I'm not sure about is why VSCode is trying to run at all. When I do this from a command line (), I get an "Access is denied" there as well - which doesn't surprise me.
It actually tries to create the root path :) If you run VS Code as non-admin, it won't even let you try to save to but if you run VS Code as admin, it will let you try but fails on creating . !
Thanks, will look into it!
This looks like a bad regression in (). It relies on the EEXIST error but when reaching the root drive, it ends in EPERM. I think you touched this function last.
As of now, 0.10.8-insider build run as an administrator lets you save to D:<filenameAs far as I can see, this is truly closed.
Change:
this.getHTMLElement().classList.add('settings-editor-tree'); <del> this.style(getListStyles({ listBackground: editorBackground, listActiveSelectionBackground: editorBackground, listActiveSelectionForeground: foreground, listFocusAndSelectionBackground: editorBackground, listFocusAndSelectionForeground: foreground, listFocusBackground: editorBackground, listFocusForeground: foreground, listHoverForeground: foreground, listHoverBackground: editorBackground, listHoverOutline: editorBackground, listFocusOutline: editorBackground, listInactiveSelectionBackground: editorBackground, listInactiveSelectionForeground: foreground, listInactiveFocusBackground: editorBackground, listInactiveFocusOutline: editorBackground })); </del> <ins> this.style({ ...getListStyles({ listBackground: editorBackground, listActiveSelectionBackground: editorBackground, listActiveSelectionForeground: foreground, listFocusAndSelectionBackground: editorBackground, listFocusAndSelectionForeground: foreground, listFocusBackground: editorBackground, listFocusForeground: foreground, listHoverForeground: foreground, listHoverBackground: editorBackground, listHoverOutline: editorBackground, listFocusOutline: editorBackground, listInactiveSelectionBackground: editorBackground, listInactiveSelectionForeground: foreground, listInactiveFocusBackground: editorBackground, listInactiveFocusOutline: editorBackground, }), treeIndentGuidesStroke: undefined, treeInactiveIndentGuidesStroke: undefined, }); </ins> this.disposables.add(configurationService.onDidChangeConfiguration(e => { if (e.affectsConfiguration('workbench.list.smoothScrolling')) {

Discussion:
I opened the Settings editor, hovered over a setting, and noticed a new grey line appear to the left of the settings. This issue occurs with the default light and dark themes. !
I found that when calling , if we don't pass in the style override anymore, it will be reset to default I put this fix for notebook but I wonder if it's unexpected
Thanks for figuring that out. We shouldn't update options that are not set, that a regression. I fixed that with and updated your code to back what it was. Is different, it's about the indent guides which were disabled previously by not providing any colors. With my change we complete your colors with the default colors, which IMO is the right thing to do. is a simple fix. But I think we should not use the colors for that but the already existing option. I'm working on a follow up PR, but that needs to be reviewed by who is out today.
Change:
import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { IDebugService, IExpression, IExpressionContainer } from 'vs/workbench/contrib/debug/common/debug'; import { Expression } from 'vs/workbench/contrib/debug/common/debugModel'; <del> import { renderExpressionValue } from 'vs/workbench/contrib/debug/browser/baseDebugView'; </del> <ins> import { renderExpressionValue, replaceWhitespace } from 'vs/workbench/contrib/debug/browser/baseDebugView'; </ins> import { DomScrollableElement } from 'vs/base/browser/ui/scrollbar/scrollableElement'; import { attachStylerCallback } from 'vs/platform/theme/common/styler'; import { IThemeService } from 'vs/platform/theme/common/themeService';

Discussion:
Issue Type: <bBug</bHi. I am assigning trade.occId = occId; i.e. to a property (in this case it contains 4 spaces. In the JavaScript hover view however, the property on 'trade' reads (only one space) [btw, I copied both these values right out of the IDE view]. I've just been chasing ghosts for some time because of this discrepancy and not expecting the IDE altering assigned values when viewing objects. Update ---Alright, sorry. I am not sure how to submit the first value on GitHub with the 4 spaces between GS and 1 preserved, even when using 'code' quotes (same as the VSC issue...). So the first value is "GD....190517P00155000" when replacing spaces with dots... Thanks for VS Code otherwise :-) VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ vscode-scss0.6.2 debugger-for-chrome4.11.3 vscode-scss-formatter1.4.1 vscodeintellicode1.1.5 </details<!-- generated by issue reporter --
Can you please provide a screenshot of what you see? Also try disabling all extensions. I am not sure if such an hover is provided by out of the box typescript/javascript extension.
Hi. Please see below. I disabled all extensions besides Debugger for Chrome, which I need to set a break-point to be able to inspect values. The issue is in most obvious in the field 'occId', which in fact has 4 spaces after 'GD' and not just one as displayed. Thanks for following up. [image: ] !
Ah I see.. its an hover while debugging.
You did not attach an image. So please attach an image and some reproducable steps so we can investigate more. Thanks
It did, (please check below the quote). Anyway, your question made me come up with a better/simpler example that should make things clear. Here you go: ! Btw, Gruetzi to all you guys in Zuerich.

I'm originally from Basel :)
Thanks for the image. Cheers back to Basel :)
VSCode insiders will have the fix for this on monday. Try it out and let us know if it is ok for you. Though I verified and the fix from looks good
Thanks for the work and update. Unfortunately I can't switch from VSCode stable, so I'll take your word for it until this hits release :-)
Change:
if (otherEditorAgent) { bridgeStore.clear(); <del> _logService.info(`REMOVED bridge agent "${agentData.id}", found "${otherEditorAgent.id}"`); </del> <ins> _logService.debug(`REMOVED bridge agent "${agentData.id}", found "${otherEditorAgent.id}"`); </ins> } else if (!myEditorAgent) { bridgeStore.value = this._chatAgentService.registerDynamicAgent(agentData, this._instaService.createInstance(BridgeAgent, agentData, this._sessions, data => { this._lastResponsesFromBridgeAgent.set(data.id, data.response); })); <del> _logService.info(`ADDED bridge agent "${agentData.id}"`); </del> <ins> _logService.debug(`ADDED bridge agent "${agentData.id}"`); </ins> } };

Discussion:
Can these not be trace: <img width="1046" alt="image" src=""
Change:
multipleDefinitions?: GoToLocationValues; multipleTypeDefinitions?: GoToLocationValues; multipleDeclarations?: GoToLocationValues; <del> multipleImplemenations?: GoToLocationValues; </del> <ins> multipleImplementations?: GoToLocationValues; </ins> multipleReferences?: GoToLocationValues; }

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.41.0-insider OS Version: Windows_NT x64 10.0. Steps to Reproduce: to settings for "Implemenations" "Editor Goto Location: Multiple Implemenations" appears instead of "Editor Goto Location: Multiple Implementations" This also shows up as "editor.gotoLocation.multipleImplemenations" in "" instead of as "editor.gotoLocation.multipleImplementations" <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Change:
{ "command": "git.pushRef", "group": "navigation", <del> "when": "scmProvider == git" </del> <ins> "when": "scmProvider == git && scmHistoryItemGroupHasUpstream" }, { "command": "git.publish", "group": "navigation", "when": "scmProvider == git && !scmHistoryItemGroupHasUpstream" </ins> } ], "scm/outgoingChanges/context": [ { "command": "git.pushRef", "group": "1_modification@1", <del> "when": "scmProvider == git" </del> <ins> "when": "scmProvider == git && scmHistoryItemGroupHasUpstream" }, { "command": "git.publish", "group": "1_modification@1", "when": "scmProvider == git && !scmHistoryItemGroupHasUpstream" </ins> } ], "scm/outgoingChanges/allChanges/context": [

Discussion:
Testing I expected the action to appear on an unpublished branch, not the action. I am aware they both do the same. <img width="647" alt="Screenshot 2024-01-24 at 11 37 40" src=""
Change:
treeInactiveIndentGuidesStroke: asCssVariable(treeInactiveIndentGuidesStroke), treeStickyScrollBackground: undefined, treeStickyScrollBorder: undefined, <del> treeStickyScrollShadow: undefined, </del> <ins> treeStickyScrollShadow: asCssVariable(scrollbarShadow), </ins> tableColumnsBorder: asCssVariable(tableColumnsBorder), tableOddRowsBackgroundColor: asCssVariable(tableOddRowsBackgroundColor), };

Discussion:
Sometimes the tree sticky show shadow does not show. Make sure they use the proper overrides and that there is a default color if none is provided
are there any validation steps here?
verified- the scm sticky scroll showed on insiders, but not stable.
Change:
<del> <svg xmlns="http://www.w3.org/2000/svg" width="16" height="16" viewBox="-0.994 0 16 16" enable-background="new -0.994 0 16 16"><path fill="#C5C5C5" d="M13 6c0 1.461-.636 2.846-1.746 3.797l-5.584 4.951-1.324-1.496 5.595-4.962c.678-.582 1.061-1.413 1.061-2.29 0-1.654-1.345-3-2.997-3-.71 0-1.399.253-1.938.713l-1.521 1.287h2.448l-1.998 2h-3.996v-4l1.998-2v2.692l1.775-1.504c.899-.766 2.047-1.188 3.232-1.188 2.754 0 4.995 2.243 4.995 5z"/></svg> </del>  No newline at end of file <ins> <svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" viewBox="-0.994 0 16 16" enable-background="new -0.994 0 16 16"><path fill="#C5C5C5" d="M13 6c0 1.461-.636 2.846-1.746 3.797l-5.584 4.951-1.324-1.496 5.595-4.962c.678-.582 1.061-1.413 1.061-2.29 0-1.654-1.345-3-2.997-3-.71 0-1.399.253-1.938.713l-1.521 1.287h2.448l-1.998 2h-3.996v-4l1.998-2v2.692l1.775-1.504c.899-.766 2.047-1.188 3.232-1.188 2.754 0 4.995 2.243 4.995 5z"/></svg> </ins>  No newline at end of file

Discussion:
Looks unbalanced (especially the discard again vs. the stage action): !
While this might have fixed the icon issue in the quick diff area, now I find it uneven in the changes view where icons are typically 16px: !
This is the before/after. The after does look better: !
Yeah looks good for you. Might be my zoom level of 2 then.
Change:
import { TerminalCapabilityStore } from 'vs/platform/terminal/common/capabilities/terminalCapabilityStore'; import { assertLinkHelper, resolveLinkForTest } from 'vs/workbench/contrib/terminal/test/browser/links/linkTestUtils'; import { Terminal } from 'xterm'; <ins> import { timeout } from 'vs/base/common/async'; import { strictEqual } from 'assert'; </ins> const unixLinks = [ '/foo',

Discussion:
These flakes are a bit odd, not sure what could cause them and the failures seem a bit all over the place
I some logs that will help with debugging future failures. Closing in the meantime until a new one pops up.
Change:
quickPick.items = items; disposables.add(quickPick.onDidAccept(() => { if (quickPick.selectedItems[0] && quickPick.selectedItems[0].id) { <del> commandService.executeCommand(quickPick.selectedItems[0].id); </del> <ins> // Introduce timeout as workaround - #91661 #91740 timeout(0).then(() => commandService.executeCommand(quickPick.selectedItems[0].id!)); </ins> } quickPick.hide(); }));

Discussion:
Steps to Repro Set up settings sync - Follow instructions Turn on Sync From the gear icon, select entry Quick pick is shown. From the quick pick click on entry Quick pick with wrong selected items is shown <img width="631" alt="image" src="https://user-"Expected: <img width="632" alt="image" src="https://user-"Note: Expected is shown when you use keyboard to select entry. It happens only when you use mouse and click.
There is a change event on the checkbox from the mouse up on the entry. I don't have a fix in QuickInput currently, can we change to: That appears to let the mouse up pass without triggering the change event on the checkbox.
Is this a temp workaround and do you have plans to fix it in quick pick later?
It’s certainly a workaround. I don’t have a proper fix yet.