jiebi/CodeConvo huggingface dataset:
Change:
event.stopPropagation(); } })); <del> this.toDispose.push(attachStylerCallback(this.themeService, { selectBorder }, colors => { </del> <ins> this.toDispose.push(attachStylerCallback(this.themeService, { selectBorder, selectBackground }, colors => { </ins> this.container.style.border = colors.selectBorder ? `1px solid ${colors.selectBorder}` : ''; selectBoxContainer.style.borderLeft = colors.selectBorder ? `1px solid ${colors.selectBorder}` : ''; <ins> this.start.style.backgroundColor = colors.selectBackground ? `${colors.selectBackground}` : ''; </ins> })); this.debugService.getConfigurationManager().getDynamicProviders().then(providers => { this.providers = providers;

Discussion:
I played around with to set the background color of the dropdown widget. It works fine in the panel area but e.g. not for the debug dropdown. That makes me wonder if we possibly have code in debug land that overrides this because the debug view is in the side bar. That is probably not a good idea given you can move views around. !
Same for remote explorer, so it is maybe more generic: ! //cc
You are correct we use the sidebar_background for the debug I thought the issue is that we also have a green play button which is part of this and we did not want to custmoise it becuase the Green play might not look good on the customised background. As for the remote explorer I have no clue.
I think the remote one is covered via
That one was probably a copy paste mistake from debug land :)
last milestone and I saw this differentiation and assumed it was intentional that all sidebar dropdowns do not honor the theme color. this meant that if you drag terminal or output to the sidebar (in their own viewlet), they will also skip using the theme color for dropdown
I am opening this for a PR. Code pointer The debug select box should listen to style changes and also style the background of the Green Play button.
Adding lable bug so we get this verified.
Change:
// Recommend prerelease if not on Stable. const isStable = productService.quality === 'stable'; try { <del> const [extension] = await extensionGalleryService.getExtensions([{ id: extensionId, preRelease: !isStable }], CancellationToken.None); if (extension) { recommendedExtensionsGalleryInfo[key] = extension; </del> <ins> const extensions = await raceTimeout(extensionGalleryService.getExtensions([{ id: extensionId, preRelease: !isStable }], CancellationToken.None), EXTENSION_FETCH_TIMEOUT_MS); if (extensions?.length === 1) { recommendedExtensionsGalleryInfo[key] = extensions[0]; </ins> } else { // same as network connection fail. we do not want a blank settings page: https://github.com/microsoft/vscode/issues/195722 // so instead of returning partial data we return undefined here

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.89.0 OS Version: Linux x64 6.6.26-1-MANJARO Steps to Reproduce: VS Code. Developer Tools and watch Network requests. VS Code, open Settings. that Settings will not display any settings until the requests to are completed. reading the results of the queries, observe that this request is related to the absolutely despicable advertisement for GitHub Copilot_, to detect if it's already installed (or something) in order to show the ad in the Settings UI and that you are now even more incensed that something which should work immediately was taking 7 seconds or longer due to the fact that we are now living through a dystopia. Then quickly get over it and start considering a move to a different editor or a fork. Please choose one of the following suggestions: remove the GitHub Copilot advertisement from the Settings UI. waiting for network requests in order to show the Settings UI. this issue and ignore this unquestionably sane plea to help battle the enfecalization of this beloved product.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
The AUR hasn't been updated with 1.89.1 yet but looking at the resolved issues I don't see any related to this.
I have a 1-second timeout per network request. In other words, the delays should now have an upper limit on their duration.
Change:
"typescript.tsserver.experimentalAutoBuild": "Enables experimental auto build. Requires 1.9 dev or 2.x tsserver version and a restart of VS Code after changing it.", "typescript.validate.enable": "Enable/disable TypeScript validation.", "typescript.format.enable": "Enable/disable default TypeScript formatter.", <ins> "typescript.tryAcceptSelectedSuggestionOnDot": "Accept current suggestion when a dot is typed", </ins> "javascript.format.enable": "Enable/disable default JavaScript formatter.", "format.insertSpaceAfterCommaDelimiter": "Defines space handling after a comma delimiter.", "format.insertSpaceAfterSemicolonInForStatements": " Defines space handling after a semicolon in a for statement.",

Discussion:
VSCode Version: Code 1.8.1 (, 2016-12-19T14:49:23.350Z) OS Version: Windows_NT ia32 10.0. Extensions: Steps to Reproduce: from npm with typings to import a relative path downwards( import Person from '../person' for instance ). The import will suggest "" as it includes a '.' character or something.
in general please include snippets and screenshots that illustrate the problem and provide precise steps with snippets, screenshots that illustrates a problem (see our ).
Sorry, i provided a video now, it includes full editor and you can see the structure there. The is standard, so is with saved and Steps to reproduce is: init install --init in a folder, () containing a class: in a subfolder () to import a relative path to File1. When you're going to type a relative step back (../), it will autocorrect to "" instead of ".." as shown in the video. If anything more is needed, please let me know. hope this make things a bit clearer
thanks for the additional info.
Short update, it does not seem to happen when running js. i thought it might due to the automatic type acquisition, but it works as intended, for me at least.
me too
this looks like an issue we've seen before...
Fix reverted ,
Picked up improved fix with
Change:
return this.model.collapseAll(elements, recursive); } <del> public collapseDeepestExpandedLevel(): WinJS.Promise { return this.model.collapseDeepestExpandedLevel(); } </del> public toggleExpansion(element: any, recursive: boolean = false): WinJS.Promise { return this.model.toggleExpansion(element, recursive); }

Discussion:
introduced a  API to the tree via I'm pretty sure that method's implementation can be achieved outside the tree itself. There are , and methods on it. If so, please remove the API method and implement on the search usage side.
This was to the tree with the idea in mind that it would be useful elsewhere like the file explorer. And in fact I'd really like to have the same behavior on the file explorer. So moving it into search code is not the right thing to do but it could go into some TreeHelper class outside of the tree itself.
No need to overload with classes. A simple util function would do.
I don't think this is actually achievable outside the tree itself with the current tree API. It needs to calculate the tree depth to collapse to, and the navigator from just returns elements of the tree without the context of where they are in the tree. IMO, it makes sense for this method to stay on the tree since it's coupled with the tree's data
Good point. But this is really only used for search. I don't really buy into the generic usefulness of this as an API call, which needs to be maintained for the entire tree's lifecycle. As far as I am aware, search trees can only go 2/3 levels deep, depending on whether there are multiple folders in the workspace or not. That knowledge is kept in the search's tree user; the same entity knows exactly what it should collapse or otherwise. Can't it just call the right calls?
Change:
private static readonly _name = 'pluginHostTelemetry'; <del> private _oldTelemetryEnabledValue: boolean | undefined; </del> constructor( extHostContext: IExtHostContext, @ITelemetryService private readonly _telemetryService: ITelemetryService, @IConfigurationService private readonly _configurationService: IConfigurationService, <del> @IEnvironmentService private readonly _environmenService: IEnvironmentService, </del> <ins> @IEnvironmentService private readonly _environmentService: IEnvironmentService, </ins> @IProductService private readonly _productService: IProductService ) { super(); this._proxy = extHostContext.getProxy(ExtHostContext.ExtHostTelemetry); <del> if (supportsTelemetry(this._productService, this._environmenService)) { </del> <ins> if (supportsTelemetry(this._productService, this._environmentService)) { </ins> this._register(this._configurationService.onDidChangeConfiguration(e => { if (e.affectsConfiguration(TELEMETRY_SETTING_ID) || e.affectsConfiguration(TELEMETRY_OLD_SETTING_ID)) { <del> const telemetryEnabled = this.telemetryEnabled; // Since changing telemetryLevel from "off" => "error" doesn't change the isEnabled state // We shouldn't fire a change event if (telemetryEnabled !== this._oldTelemetryEnabledValue) { this._oldTelemetryEnabledValue = telemetryEnabled; this._proxy.$onDidChangeTelemetryEnabled(this.telemetryEnabled); } </del> <ins> this._proxy.$onDidChangeTelemetryLevel(this.telemetryLevel); </ins> } })); } <del> this._proxy.$initializeTelemetryEnabled(this.telemetryEnabled); </del> <ins> this._proxy.$initializeTelemetryLevel(this.telemetryLevel); </ins> } <del> private get telemetryEnabled(): boolean { if (!supportsTelemetry(this._productService, this._environmenService)) { return false; </del> <ins> private get telemetryLevel(): TelemetryLevel { if (!supportsTelemetry(this._productService, this._environmentService)) { return TelemetryLevel.NONE; </ins> } <del> return getTelemetryLevel(this._configurationService) === TelemetryLevel.USAGE; </del> <ins> return getTelemetryLevel(this._configurationService); </ins> } $publicLog(eventName: string, data: any = Object.create(null)): void {

Discussion:
The current API does not expose the same level of internal granularity as the user setting allows. This proposal is to expose the telemetry levels. The current and can still be used a simpler API and this one can be considered more advanced and granular. Extension authors cannot just observe the user setting as this will lead to doing the wrong thing.
Another possibility is that we could collect an array of acceptable levels if we're worried about the possibility that the levels will not continue to be progressive but a permissions system instead. I.e. collecting errors and crashes would have be an array . None wouldn't really make sense in this context and would probably go away in favor of an empty array.
This is implemented but will remain in the proposed state for awhile for testing
Closing in favor of
Change:
return; } <del> await openerService.open(range ? uri.with({ fragment: `L${range.startLineNumber}:${range.startColumn}` }) </del> <ins> await openerService.open(position ? uri.with({ fragment: `L${position.lineNumber}:${position.column}` }) </ins> : uri ); }

Discussion:
Using the test-provider-sample, adding newlines on a line marked as a test duplicates the test icon: ! It sorts itself out on the next update (at least in the sample, I'm still investigating to figure out if there's another issue, or that's in my extension). But it still looks bad - especially if a language is debouncing edits and/or discovery may be slow.. You can make the issue more pronounced (as I did for the GIF) by updating the test-provider-sample to have a delay in its updates:
I was able to repro the full issue I'm seeing in Dart (where the icons never disappear) using the sample too: ! My changes to the sample are here: I changed it so that tests can span multiple lines (since the original code split on lines then searched each line) and use the full range as the for the test. Now when pressing in the test, the original issue (VS Code duplicate the icons) still occurs, but also after the updates, since the range computed by the provider doesn't change from the range VS Code currently has (at least that's my guess), there's no update to the gutter icons so they no longer get cleaned up.
That's correct, we let the editor do its default decoration tracking until an update is received from the extension. for testing decorations, I already set , but is there a similar option to avoid extending the range over lines when edited? Or, alternatively, a way to only apply the glyphMarginClassName to the first line of the range. Reference:
You can create two decorations per test. One which has a range, a hover message, etc. And another one which renders the glyph margin with a collapsed range (perhaps the start position of the range). If you use for the second one, given it begins as a collapsed range, it will never grow, it will always remain a collapsed range.
Change:
i = lineWidth.newIndex; } maxCols = Math.min(maxCols, Constants.MaxSupportedCols); <del> if (maxCols > this.maxCols) { this._fixedCols = maxCols; await this._addScrollbar(); } </del> <ins> this._fixedCols = maxCols; await this._addScrollbar(); </ins> } this.focus(); }

Discussion:
Testing have fixed with on in a narrow terminal type select , existing text is re-rendered correctly select again, :bug: no effect https://user-
I'm having trouble reproducing this
could be related to the (now fixed) problem of losing terminal focus, since that's a precondition for the action to run
Change:
// Init winpty compat and link handler after process creation as they rely on the // underlying process OS this._processManager.onProcessReady((processTraits) => { <ins> // If links are ready, do not re-create the manager. if (this._areLinksReady) { return; } </ins> if (this._processManager.os === OperatingSystem.Windows) { xterm.setOption('windowsMode', processTraits.requiresWindowsMode || false); // Force line data to be sent when the cursor is moved, the main purpose for

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. --Version: 1.61.0 Commit: Date: 2021-10-07T18:11:58.853Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: the Terminal Sample from the vscode-extension-sample repository the a task that reuses a terminal. For example, I used a user task like: On the first run of the task the 'link' text will create a hover link correctly. If you re-run the task so the terminal has 2 (or more) runs of the task in the same terminal then the link will fail to detect correctly. Adding a breakpoint to there appears to be 1 call per execution of the task in the terminal. I think when the terminal is re-used it re-registers the link provider and if two link providers have overlapping links they both seem to fail (which is a known issue but due to this bug all link providers start failing if tasks are run multiple times).
Putting a breakpoint in the registerLinkProvider call for xterm (here ) I see multiple copies of all of the link providers: <img width="574" alt="Screen Shot 2021-10-12 at 9 15 30 AM" src="https://user-"
Change:
}); } <del> run(accessor: ServicesAccessor, editor: ICodeEditor): void { </del> <ins> run(accessor: ServicesAccessor): void { </ins> const outerEditor = getOuterEditorFromDiffEditor(accessor); if (!outerEditor || !outerEditor.hasModel()) {

Discussion:
Found while working on a file tracked by git and make two distinct changes in separate lines the same file on the other side the dirty diff gutter marker on each of the editors to open the dirty diff views the outer editor on the right-hand side the action on the left-hand side dirty diff editor The right-hand side dirty diff editor jumps to the next change !
Change:
"fontCharacter": "E074", "fontColor": "#cc3e44" }, <del> "_rmd_light": { "fontColor": "#498ba7" }, "_rmd": { "fontColor": "#519aba" }, </del> "_rollup_light": { "fontCharacter": "E075", "fontColor": "#b8383d"

Discussion:
accepted a couple of update PRs recently. Can you please sync extensions/theme-seti/icons? Meanwhile, I noticed that file was falsely classified as type file. I am not sure if that's a real issue in the latest vscode release candidate, or just a non-reproducible problem caused by some peculiarity in my vscode dev env. Can you please take a look?
Also something worth mentioning is that WebP images lack the image icon whereas WebM videos does indeed have the video icon. Adding lines: and does indeed solves the issue.
can you please file a separate issue? Thanks.
NP sir .
thanks! While testing your PR, can you also please check the icon for file? There shouldn't be no icon assigned to it. Otherwise, that's a regression and I am happy to file an issue.
we don't have any references to files in our seti-ui directory and nearly all of our code is pulled directly from the seti repo, so i'm unsure where this is coming from. Please file a separate issue and can look into it. EDIT: after looking into this, it appears that files are : ! And we have refs for mod files in our built-in xml extension: So there is a clash there. I'd suggest you make a request on the seti-ui theme to set files to a go icon so there are no conflicts.
Verification steps: ensure that the following updates are reflected in the file explorer for file icons: use the new logo files point to the R icon files point to the TypeScript icon !
Change:
// import * as path from 'path'; // import * as fs from 'fs'; // import { fileURLToPath } from 'url'; <ins> // import { createRequire } from 'node:module'; </ins> // <ins> // const require = createRequire(import.meta.url); </ins> // const module = { exports: {} }; // const __dirname = path.dirname(fileURLToPath(import.meta.url)); // ESM-uncomment-end

Discussion:
We lost changes that where ESM relevant. I am trying to fix it in our ESM branch, maybe backport it from there: The old code also had this line, which I am not sure is needed: cc
Sorry about that. Is this for Monaco or the esm work? I'd love to get a point where we can just have this as a normal dependency instead of copying it into our sources. Marked now publishes both a commonjs and esm builds too. Is there some way VS Code could use Marked as a normal dependency in a way that would also work for Monaco? If I recall we've tried to avoid adding real dependencies to Monaco
I only noticed for our work, not sure about Monaco ESM. Would be great to get it working again on .
I think the ESM work will unblock this. esbuild will be able to bring in and include node modules into our bundle, the AMD bundler we currently use can only bundle AMD modules and not commonjs modules.
I would have hoped that the Monaco Editor checks would have caught this. Is there something we should improve there?
For monaco-editor-core, these are the only tests: It does not test markdown features.
Change:
break; } } <ins> const { iconDefinitions, iconFontDefinitions } = data; if (Array.isArray(iconDefinitions) && isObject(iconFontDefinitions)) { const restoredIconDefinitions = new Map<string, IconDefinition>(); for (const entry of iconDefinitions) { const { id, fontCharacter, fontId } = entry; if (isString(id) && isString(fontCharacter)) { if (isString(fontId)) { const iconFontDefinition = IconFontDefinition.fromJSONObject(iconFontDefinitions[fontId]); if (iconFontDefinition) { restoredIconDefinitions.set(id, { fontCharacter, font: { id: fontId, definition: iconFontDefinition } }); } } else { restoredIconDefinitions.set(id, { fontCharacter }); } } } theme.iconThemeDocument = { iconDefinitions: restoredIconDefinitions }; } </ins> return theme; } catch (e) { return undefined;

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 <!-- 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.0 OS Version: Windows 11 21H2 Steps to Reproduce: a window another window with and observe that product icon themes don't load immediately and you are shown the default ones for a short while. https://user- The video above contains an example of this issue happening. If it matters, I am using the Fluent Icons product icon theme.
Why does this have the feature request label? This is a bug.
Change:
export const selectForeground = registerColor('dropdown.foreground', { dark: '#F0F0F0', light: null, hcDark: Color.white, hcLight: foreground }, nls.localize('dropdownForeground', "Dropdown foreground.")); export const selectBorder = registerColor('dropdown.border', { dark: selectBackground, light: '#CECECE', hcDark: contrastBorder, hcLight: contrastBorder }, nls.localize('dropdownBorder', "Dropdown border.")); <del> export const checkboxBackground = registerColor('checkbox.background', { dark: selectBackground, light: selectBackground, hcDark: selectBackground, hcLight: selectBackground }, nls.localize('checkbox.background', "Background color of checkbox widget.")); export const checkboxForeground = registerColor('checkbox.foreground', { dark: selectForeground, light: selectForeground, hcDark: selectForeground, hcLight: selectForeground }, nls.localize('checkbox.foreground', "Foreground color of checkbox widget.")); export const checkboxBorder = registerColor('checkbox.border', { dark: selectBorder, light: selectBorder, hcDark: selectBorder, hcLight: selectBorder }, nls.localize('checkbox.border', "Border color of checkbox widget.")); </del> export const buttonForeground = registerColor('button.foreground', { dark: Color.white, light: Color.white, hcDark: Color.white, hcLight: Color.white }, nls.localize('buttonForeground', "Button foreground color.")); export const buttonSeparator = registerColor('button.separator', { dark: transparent(buttonForeground, .4), light: transparent(buttonForeground, .4), hcDark: transparent(buttonForeground, .4), hcLight: transparent(buttonForeground, .4) }, nls.localize('buttonSeparator', "Button separator color.")); export const buttonBackground = registerColor('button.background', { dark: '#0E639C', light: '#007ACC', hcDark: null, hcLight: '#0F4A85' }, nls.localize('buttonBackground', "Button background color."));

Discussion:
With default Dark+ theme: !
Hi, I want to work on this, and I think is the file that needs to be changed, could you please advise on this? Thanks!