jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: 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 {
Code change:
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

Related discussion:
text: return extHostTerminalService.getDefaultShell(false); }, get isTelemetryEnabled() { <del> return extHostTelemetry.getTelemetryEnabled(); </del> <ins> return extHostTelemetry.getTelemetryConfiguration(); </ins> }, get onDidChangeTelemetryEnabled(): Event<boolean> { return extHostTelemetry.onDidChangeTelemetryEnabled; }, <ins> get telemetryConfiguration(): vscode.TelemetryConfiguration { checkProposedApiEnabled(extension, 'telemetry'); return extHostTelemetry.getTelemetryDetails(); }, get onDidChangeTelemetryConfiguration(): Event<vscode.TelemetryConfiguration> { checkProposedApiEnabled(extension, 'telemetry'); return extHostTelemetry.onDidChangeTelemetryConfiguration; }, </ins> get isNewAppInstall() { const installAge = Date.now() - new Date(initData.telemetryInfo.firstSessionDate).getTime(); return isNaN(installAge) ? false : installAge < 1000 * 60 * 60 * 24; // install age is less than a day
Code change:
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

Related discussion:
text: import { IRemoteConnectionData, RemoteAuthorityResolverErrorCode, ResolverResult, TunnelDescription } from 'vs/platform/remote/common/remoteAuthorityResolver'; import { ProvidedPortAttributes, TunnelCreationOptions, TunnelOptions, TunnelProviderFeatures } from 'vs/platform/remote/common/tunnel'; import { ClassifiedEvent, GDPRClassification, StrictPropertyCheck } from 'vs/platform/telemetry/common/gdprTypings'; <del> import { ITelemetryInfo } from 'vs/platform/telemetry/common/telemetry'; </del> <ins> import { ITelemetryInfo, TelemetryLevel } from 'vs/platform/telemetry/common/telemetry'; </ins> import { ICreateContributedTerminalProfileOptions, IProcessProperty, IShellLaunchConfigDto, ITerminalEnvironment, ITerminalLaunchError, ITerminalProfile, TerminalLocation } from 'vs/platform/terminal/common/terminal'; import { ThemeColor, ThemeIcon } from 'vs/platform/theme/common/themeService'; import { IExtensionIdWithVersion } from 'vs/platform/extensionManagement/common/extensionStorage';
Code change:
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

Related discussion:
text: } export interface ExtHostTelemetryShape { <del> $initializeTelemetryEnabled(enabled: boolean): void; $onDidChangeTelemetryEnabled(enabled: boolean): void; </del> <ins> $initializeTelemetryLevel(level: TelemetryLevel): void; $onDidChangeTelemetryLevel(level: TelemetryLevel): void; </ins> } export interface ITerminalLinkDto {
Code change:
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

Related discussion:
text: import { createDecorator } from 'vs/platform/instantiation/common/instantiation'; import { Event, Emitter } from 'vs/base/common/event'; import { ExtHostTelemetryShape } from 'vs/workbench/api/common/extHost.protocol'; <ins> import { TelemetryLevel } from 'vs/platform/telemetry/common/telemetry'; import type { TelemetryConfiguration } from 'vscode'; </ins> export class ExtHostTelemetry implements ExtHostTelemetryShape { private readonly _onDidChangeTelemetryEnabled = new Emitter<boolean>(); readonly onDidChangeTelemetryEnabled: Event<boolean> = this._onDidChangeTelemetryEnabled.event; <del> private _enabled: boolean = false; </del> <ins> private readonly _onDidChangeTelemetryConfiguration = new Emitter<TelemetryConfiguration>(); readonly onDidChangeTelemetryConfiguration: Event<TelemetryConfiguration> = this._onDidChangeTelemetryConfiguration.event; </ins> <del> getTelemetryEnabled(): boolean { return this._enabled; </del> <ins> private _level: TelemetryLevel = TelemetryLevel.NONE; private _oldTelemetryEnablement: boolean | undefined; getTelemetryConfiguration(): boolean { return this._level === TelemetryLevel.USAGE; } getTelemetryDetails(): TelemetryConfiguration { return { isCrashEnabled: this._level >= TelemetryLevel.CRASH, isErrorsEnabled: this._level >= TelemetryLevel.ERROR, isUsageEnabled: this._level >= TelemetryLevel.USAGE }; </ins> } <del> $initializeTelemetryEnabled(enabled: boolean): void { this._enabled = enabled; </del> <ins> $initializeTelemetryLevel(level: TelemetryLevel): void { this._level = level; </ins> } <del> $onDidChangeTelemetryEnabled(enabled: boolean): void { this._enabled = enabled; this._onDidChangeTelemetryEnabled.fire(enabled); </del> <ins> $onDidChangeTelemetryLevel(level: TelemetryLevel): void { this._oldTelemetryEnablement = this.getTelemetryConfiguration(); this._level = level; if (this._oldTelemetryEnablement !== this.getTelemetryConfiguration()) { this._onDidChangeTelemetryEnabled.fire(this.getTelemetryConfiguration()); } this._onDidChangeTelemetryConfiguration.fire(this.getTelemetryDetails()); </ins> } }
Code change:
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

Related discussion:
text: scmValidation: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.scmValidation.d.ts', tabs: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.tabs.d.ts', taskPresentationGroup: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.taskPresentationGroup.d.ts', <ins> telemetry: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.telemetry.d.ts', </ins> terminalDataWriteEvent: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.terminalDataWriteEvent.d.ts', terminalDimensions: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.terminalDimensions.d.ts', terminalDisablePersistence: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.terminalDisablePersistence.d.ts',
Code change:
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

Related discussion:
text: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare module 'vscode' { export interface TelemetryConfiguration { /** * Whether or not usage telemetry collection is allowed */ isUsageEnabled: boolean; /** * Whether or not crash error telemetry collection is allowed */ isErrorsEnabled: boolean; /** * Whether or not crash report collection is allowed */ isCrashEnabled: boolean; } export namespace env { /** * Indicates what telemetry is enabled / disabled * Can be observed to determine what telemetry the extension is allowed to send */ export const telemetryConfiguration: TelemetryConfiguration; /** * An {@link Event} which fires when the collectable state of telemetry changes * Returns a {@link TelemetryConfiguration} object */ export const onDidChangeTelemetryConfiguration: Event<TelemetryConfiguration | undefined>; } } </ins>
Code change:
Testing When browsing themes while offline, I didn't get any message that I could not connect to the marketplace and/or could not retrieve themes, with the only visible feedback being that the theme search would instantly return with an empty quickpick. It would be nice if this information could be surfaced somehow.
Verified: !

Related discussion:
text: private readonly _marketplaceThemes: ThemeItem[] = []; private _searchOngoing: boolean = false; <ins> private _searchError: string | undefined = undefined; </ins> private readonly _onDidChange = new Emitter<void>(); private _tokenSource: CancellationTokenSource | undefined;
Code change:
Testing When browsing themes while offline, I didn't get any message that I could not connect to the marketplace and/or could not retrieve themes, with the only visible feedback being that the theme search would instantly return with an empty quickpick. It would be nice if this information could be surfaced somehow.
Verified: !

Related discussion:
text: return this._marketplaceThemes; } <del> public get isSearching(): boolean { return this._searchOngoing; } </del> public get onDidChange() { return this._onDidChange.event; }
Code change:
Testing When browsing themes while offline, I didn't get any message that I could not connect to the marketplace and/or could not retrieve themes, with the only visible feedback being that the theme search would instantly return with an empty quickpick. It would be nice if this information could be surfaced somehow.
Verified: !

Related discussion:
text: } catch (e) { if (!isCancellationError(e)) { this.logService.error(`Error while searching for themes:`, e); <ins> this._searchError = 'message' in e ? e.message : String(e); </ins> } } finally { this._searchOngoing = false;
Code change:
Testing When browsing themes while offline, I didn't get any message that I could not connect to the marketplace and/or could not retrieve themes, with the only visible feedback being that the theme search would instantly return with an empty quickpick. It would be nice if this information could be surfaced somehow.
Verified: !

Related discussion:
text: this.onDidChange(() => { let items = this.themes; <del> if (this.isSearching) { </del> <ins> if (this._searchOngoing) { </ins> items = items.concat({ label: '$(sync~spin) Searching for themes...', id: undefined, alwaysShow: true }); <ins> } else if (items.length === 0 && this._searchError) { items = [{ label: `$(error) ${localize('search.error', 'Error while searching for themes: {0}', this._searchError)}`, id: undefined, alwaysShow: true }]; </ins> } const activeItemId = quickpick.activeItems[0]?.id; const newActiveItem = activeItemId ? items.find(i => isItem(i) && i.id === activeItemId) : undefined;
Code change:
Are all these settings still "experimental"? This seems like a mature feature !
This is a good point. I believe the wording is used to indicate the functionality has some quirks. We will see if thinks it's fine to remove it.
Yep let's do it, I think we just didn't remember to remove

Related discussion:
text: default: true }, [TerminalSettingId.LocalEchoLatencyThreshold]: { <del> description: localize('terminal.integrated.localEchoLatencyThreshold', "Experimental: length of network delay, in milliseconds, where local edits will be echoed on the terminal without waiting for server acknowledgement. If '0', local echo will always be on, and if '-1' it will be disabled."), </del> <ins> description: localize('terminal.integrated.localEchoLatencyThreshold', "Length of network delay, in milliseconds, where local edits will be echoed on the terminal without waiting for server acknowledgement. If '0', local echo will always be on, and if '-1' it will be disabled."), </ins> type: 'integer', minimum: -1, default: 30,
Code change:
Are all these settings still "experimental"? This seems like a mature feature !
This is a good point. I believe the wording is used to indicate the functionality has some quirks. We will see if thinks it's fine to remove it.
Yep let's do it, I think we just didn't remember to remove

Related discussion:
text: default: 'auto' }, [TerminalSettingId.LocalEchoExcludePrograms]: { <del> description: localize('terminal.integrated.localEchoExcludePrograms', "Experimental: local echo will be disabled when any of these program names are found in the terminal title."), </del> <ins> description: localize('terminal.integrated.localEchoExcludePrograms', "Local echo will be disabled when any of these program names are found in the terminal title."), </ins> type: 'array', items: { type: 'string',
Code change:
Are all these settings still "experimental"? This seems like a mature feature !
This is a good point. I believe the wording is used to indicate the functionality has some quirks. We will see if thinks it's fine to remove it.
Yep let's do it, I think we just didn't remember to remove

Related discussion:
text: default: DEFAULT_LOCAL_ECHO_EXCLUDE, }, [TerminalSettingId.LocalEchoStyle]: { <del> description: localize('terminal.integrated.localEchoStyle', "Experimental: terminal style of locally echoed text; either a font style or an RGB color."), </del> <ins> description: localize('terminal.integrated.localEchoStyle', "Terminal style of locally echoed text; either a font style or an RGB color."), </ins> default: 'dim', oneOf: [ {
Code change:
<!-- 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 (disabling Emmet) <!-- 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.62.3 OS Version: - Ubuntu 21.10 Steps to Reproduce: a .js file which is denoted a React file by VSCode part of the coding implement state for a counter with the following simple line: getting as far as typing I wish to just exit the square brackets however Emmet takes the first position tab results in an HTML string appearing, see pictures Question: How do I move Emmet down the list of suggestions in Autocomplete for a React file, I am using other extensions like TabOut (to get out of the square brackets without any autocomplete) which would be more appropriate. ! ! ! !
This issue heavily affect the react users.
Verification steps: a JSX file. . should not be an Emmet suggestion.
/verified

Related discussion:
text: documentation?: string; } <del> function testHtmlCompletionProvider(contents: string, expectedItems: TestCompletionItem[]): Thenable<any> { </del> <ins> function testCompletionProvider(fileExtension: string, contents: string, expectedItems: TestCompletionItem[] | undefined): Thenable<boolean> { </ins> const cursorPos = contents.indexOf('|'); <del> const htmlContents = contents.slice(0, cursorPos) + contents.slice(cursorPos + 1); </del> <ins> const slicedContents = contents.slice(0, cursorPos) + contents.slice(cursorPos + 1); </ins> <del> return withRandomFileEditor(htmlContents, 'html', async (editor, _doc) => { </del> <ins> return withRandomFileEditor(slicedContents, fileExtension, async (editor, _doc) => { </ins> const selection = new Selection(editor.document.positionAt(cursorPos), editor.document.positionAt(cursorPos)); editor.selection = selection; const cancelSrc = new CancellationTokenSource();
Code change:
I was trying to copying a new setting in the problems hover and it was extremely painful to do so: https://user-
This is editor hover and hence assigning to
FWIW this works fine for me on Windows.

Related discussion:
text: private readonly _hoverOperation: HoverOperation<IHoverPart>; private _currentResult: HoverResult | null = null; <del> private _isChangingDecorations: boolean = false; </del> constructor( private readonly _editor: ICodeEditor,
Code change:
I was trying to copying a new setting in the problems hover and it was extremely painful to do so: https://user-
This is editor hover and hence assigning to
FWIW this works fine for me on Windows.

Related discussion:
text: const messages = (result.hasLoadingMessage ? this._addLoadingMessage(result.value) : result.value); this._withResult(new HoverResult(this._computer.anchor, messages, result.isComplete)); })); <del> this._register(this._editor.onDidChangeModelDecorations(() => { if (this._isChangingDecorations) { return; } this._onModelDecorationsChanged(); })); </del> this._register(dom.addStandardDisposableListener(this._widget.getDomNode(), 'keydown', (e) => { if (e.equals(KeyCode.Escape)) { this.hide();
Code change:
I was trying to copying a new setting in the problems hover and it was extremely painful to do so: https://user-
This is editor hover and hence assigning to
FWIW this works fine for me on Windows.

Related discussion:
text: })); } <del> private _onModelDecorationsChanged(): void { if (this._widget.position) { // The decorations have changed and the hover is visible, // we need to recompute the displayed text this._hoverOperation.cancel(); if (!this._widget.isColorPickerVisible) { // TODO@Michel ensure that displayed text for other decorations is computed even if color picker is in place this._hoverOperation.start(HoverStartMode.Delayed); } } } </del> /** * Returns true if the hover shows now or will show. */