jiebi/CodeConvo huggingface dataset:
Change:
import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { getSimpleEditorOptions, getSimpleCodeEditorWidgetOptions } from 'vs/workbench/contrib/codeEditor/browser/simpleEditorOptions'; import { IDecorationOptions } from 'vs/editor/common/editorCommon'; <del> import { transparent, editorForeground, inputBorder } from 'vs/platform/theme/common/colorRegistry'; </del> <ins> import { transparent, editorForeground } from 'vs/platform/theme/common/colorRegistry'; </ins> import { ICodeEditorService } from 'vs/editor/browser/services/codeEditorService'; import { FocusSessionActionViewItem } from 'vs/workbench/contrib/debug/browser/debugActionViewItems'; import { CompletionContext, CompletionList, CompletionProviderRegistry, CompletionItem, completionKindFromString, CompletionItemKind, CompletionItemInsertTextRule } from 'vs/editor/common/modes';

Discussion:
I stumbled over and saw that there are still many colors hard-coded. Also while at the .css file, it's good practice to qualify all rules with (or ) now that the workbench can be embedded in the web.
Thanks for great feedback. There was some unused CSS, like the .annotation in the repl, so I removed that. I have also now qualifed all with . There is still one hard coded color for in repl, but I believe tackled this with his great PR. Though I might be mistaken?
I did, indeed, add colour contribution points to the REPL as part of but eventually you asked me to defer those until later, I do not remember the reason precisely... So the REPL is still not theme-able, unfortunately.
thanks for refreshing my memory. In case you would like to contribute that part of your PR we are open to accept it now :D From the I only see a need for color, not sure if there is more.
I am working on this now. I am taking it a step further, though, and adding theming to most of the REPL elements (errors, warnings, infos, source filenames etc.). Basically I want the whole REPL view to be fully customisable.
To verify, make sure you can customise the following colors in the debug console. You can use the setting :
Change:
set currentHistoryItemGroup(value: SourceControlHistoryItemGroup | undefined) { this._currentHistoryItemGroup = value; this._onDidChangeCurrentHistoryItemGroup.fire(); <del> this.logger.trace('GitHistoryProvider:onDidRunGitStatus - currentHistoryItemGroup:', JSON.stringify(value)); </del> } private historyItemDecorations = new Map<string, FileDecoration>();

Discussion:
No steps yet, but it happened twice today that I have seen stale decorations, e.g after pull <img width="1367" alt="Screenshot 2024-02-14 at 12 26 08" src=""
Change:
'aria-label': localize('settings', "Settings"), })), this.viewState)); <ins> this.tocTreeDisposed = false; </ins> this._register(this.tocTree.onDidFocus(() => { this._currentFocusContext = SettingsFocusContext.TableOfContents;

Discussion:
Found this in devtools, I played a bit with settings: <img width="1904" alt="image" src="https://user-"
Let me know if you can repro and find out the issue is deep in the list/tree.
Got you repro steps! the workbench window rather small. into 2x2 editor layout, so you get even smaller editors <kbdCmd ,</kbdto open the Settings Editor in one of the editor groups for <kbdCmd W</kbdto close the Settings Editor That exception shows up!
I just closed two other duplicates of this. There are repro steps since June. Let's see if we can drive this to a fix. Let me know if you believe it's deep down in the list/tree.
Change:
return JSON.stringify(testInput); } <del> deserialize(instantiationService: IInstantiationService, serializedEditorInput: string): EditorInput { </del> <ins> deserialize(instantiationService: IInstantiationService, serializedEditorInput: string): EditorInput | undefined { if (TestEditorInputFactory.disableDeserialize) { return undefined; } </ins> let testInput: ISerializedTestInput = JSON.parse(serializedEditorInput); return new TestEditorInput(testInput.id);

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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. --I'm unsure how I got into this state, but I can't close VS Code or reload the window. Stack sohwn when I try to exit:
I cannot explain this, it seems the editor tabs model think there is an editor that does not exist anymore. Needs steps to get any further.
Upon second thought, this can maybe happen if an editor fails to serialize on shutdown. Given we have quite a few new editors, maybe this happens more often now. Marking as candidate to look into and guard against this condition.
Yea, if I recall correctly this happened after I had been playing around with notebooks/custom editors in that window.
if you can try to reproduce, it would still be great to have steps
I have a feeling this could well be notebooks given how the always returns data but the may not. //cc to check if that is a problem. If you know for a fact that you cannot serialize the notebook, please already signal that by returning from the method.
this, I guess we just need to return !(input instanceof NotebookEditorInput)`?
To clarify: it is perfectly valid to return in either of the 2 methods. I pushed a fix to handle this properly on my end. I just wanted to point out that it is always better to return early (from the ) to reduce the data we store in SQLite.
But my that the notebook editor input factory is only called with "my" inputs is valid, right? Or should I assume that it is called with any kind of input and return undefined then?
yeah that assumption is right, you will only be called for inputs you register the factory for.
I don't think anyone has a consistent repro for this, so I will mark it as verified unless I run into it again.
Change:
} ]; <ins> const directives390: Directive[] = [ ...directives, { value: '@ts-expect-error', description: localize( 'ts-expect-error', "Suppresses @ts-check errors on the next line of a file, expecting at least one to exist.") } ]; </ins> class DirectiveCommentCompletionProvider implements vscode.CompletionItemProvider { <ins> private readonly directives: Directive[]; </ins> constructor( private readonly client: ITypeScriptServiceClient, <del> ) { } </del> <ins> ) { this.directives = client.apiVersion.gte(API.v390) ? directives390 : directives; } </ins> public provideCompletionItems( document: vscode.TextDocument,

Discussion:
Following up on microsoft/TypeScript, is now a valid completion directive. It should be recommended over in the editor walkthrough that mentions comment directives.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.668 --<!-- potentialduplicatescomment --
Change:
const config = workspace.getConfiguration('git', Uri.file(this.repository.root)); const showActionButton = config.get<{ publish: boolean }>('showActionButton', { publish: true }); <del> // Branch does have an upstream, commit/merge is in progress, or the button is disabled if (this.state.HEAD?.upstream || this.state.isCommitInProgress || this.state.isMergeInProgress || !showActionButton.publish) { return undefined; } </del> <ins> // Branch does have an upstream, commit/merge/rebase is in progress, or the button is disabled if (this.state.HEAD?.upstream || this.state.isCommitInProgress || this.state.isMergeInProgress || this.state.isRebaseInProgress || !showActionButton.publish) { return undefined; } </ins> return { command: {

Discussion:
Testing [ ] Update label accordingly (deferred) [x] Remove secondary actions
Pushing this out to the next milestone as there are some things I need to investigate first related to the rebase flow.
Decided to keep the "Commit" label for the button to keep things simple. Will change it if needed, based on customer feedback.
Change:
callstack: callstack.join('n') }; this._telemetryService.publicLog2<TelemetrySampleData, TelemetrySampleDataClassification>('prof.freeze.sample', data); <del> console.log(data); </del> } } }

Discussion:
Refs Looks like there are two items that need investigation, 1) The long tasks reported by the auto profiler 2) Does the profiler output interact negatively with integration tests 3) Unrelated: should the auto profiler be enabled in CI ? Will it create noise in the telemetry ? If we want to keep the profiler enabled in CI should we then store the generated cpuprofile as pipeline artifacts.
Yeah I think the profiler should probably not run in our CI and/or tests. What is more interesting is megabytes of logs being created as part of the run all containing this exception: <img width="1499" alt="image" src="https://user-"But it is hard to say if its caused by profiling or not.
There is a forgotten but the rest is using the log service and should be proper. I kinda like that idea. I haven't seen an impact on runtime performance from profiling. Given we can store them as artifacts and given we can signal to the outside that this happened I see value in find issues quickly
Also note that we will disable automatic profiling for stable again
We store pipeline artefacts in the folder relative to the source root (logs, crash reports), so profiles could go there too, provided profiling does not make the CI more flaky. A task to publish artefacts looks like this:
Another run hitting the root issue.
i plead innocent, my changes are out: no more renderer profiling, no more lone
Same ton of in the logs
sorry, my PR to disable profiling go stuck in the pipeline (). Second attempt is on its way
I believe the EPIPE error is happening because // is writing to a closed or a closed stream. I was having a similar error in my application () and solved it by attaching error listeners to and : This NodeJS issue helped me track down the problem:
Is this issue still valid after got merged in?
Haven't seen this in while, can be closed.
Change:
properties: { [InlineChatConfigKeys.Mode]: { description: localize('mode', "Configure if changes crafted with inline chat are applied directly to the document or are previewed first."), <del> default: EditMode.LivePreview, </del> <ins> default: EditMode.Live, </ins> type: 'string', <del> enum: [EditMode.LivePreview, EditMode.Preview, EditMode.Live], </del> <ins> enum: [EditMode.Live, EditMode.Preview], </ins> markdownEnumDescriptions: [ <del> localize('mode.livePreview', "Changes are applied directly to the document and are highlighted visually via inline or side-by-side diffs. Ending a session will keep the changes."), localize('mode.preview', "Changes are previewed only and need to be accepted via the apply button. Ending a session will discard the changes."), </del> localize('mode.live', "Changes are applied directly to the document, can be highlighted via inline diffs, and accepted/discarded by hunks. Ending a session will keep the changes."), <ins> localize('mode.preview', "Changes are previewed only and need to be accepted via the apply button. Ending a session will discard the changes."), </ins> ], tags: ['experimental'] },

Discussion:
We believe is better than livePreview and therefore the default should change. Also we want to retire livePreview gracefully, e.g remove the option and then the implementation
Verify that defaults to
Change:
import { RawContextKey } from 'vs/platform/contextkey/common/contextkey'; import { workbenchConfigurationNodeBase, Extensions as WorkbenchExtensions, IConfigurationMigrationRegistry, ConfigurationKeyValuePairs, ConfigurationMigration } from 'vs/workbench/common/configuration'; import { AccessibilitySignal } from 'vs/platform/accessibilitySignal/browser/accessibilitySignalService'; <del> import { ISpeechService, SPEECH_LANGUAGES, SPEECH_LANGUAGE_CONFIG } from 'vs/workbench/contrib/speech/common/speechService'; </del> <ins> import { AccessibilityVoiceSettingId, ISpeechService, SPEECH_LANGUAGES } from 'vs/workbench/contrib/speech/common/speechService'; </ins> import { Disposable } from 'vs/base/common/lifecycle'; import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { Event } from 'vs/base/common/event';

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Related For migrating towards ESM in VSCode, it seems the tsconfig option could be useful, ensuring that imports are compatible with ESM. For example, this typescript code transpiled to javascript would cause a runtime error because of the export: The rule would enforce a type only import for : Enabling the tsconfig option in VSCode, it seems these files would need to adjusted:
We reverted this because we learnt, albeit very late, that it has disabled inlining of const enums. See
Change:
}, "main": "./out/cssServerMain", "dependencies": { <del> "vscode-css-languageservice": "^4.1.0", </del> <ins> "vscode-css-languageservice": "^4.1.1", </ins> "vscode-languageserver": "^6.1.1" }, "devDependencies": {

Discussion:
<!-- Please read our Rules of Conduct: --<!-- 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.43.0 OS Version: macOS 10.15.3 Steps to Reproduce: ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Same issue after updating to 1.43.0
I experience the same issue in: Version: 1.44.0-insider Commit: Date: 2020-03-11T09:19:54.444Z Electron: 7.1.11 Chrome: 78.0.3904.130 12.8.1 V8: 7.8.279.23-electron.0 OS: Linux x64 5.3.0-40-generic !
Does this have anything to do with the recent change in less?
caused by
PR created, to review (and merge, if ok)
To verify open a 'less' file with content and check that there's a color decorator
Change:
"--vscode-editorStickyScroll-scrollableWidth", "--vscode-editorStickyScroll-foldingOpacityTransition", "--window-border-color", <ins> "--vscode-parameterHintsWidget-editorFontFamily", "--vscode-parameterHintsWidget-editorFontFamilyDefault", </ins> "--workspace-trust-check-color", "--workspace-trust-selected-color", "--workspace-trust-unselected-color",

Discussion:
I got the default font rendered in the parameter hint widget. It looks alien compared to the rest of the hover widget UI. Steps: chat sample line 21 type the following: will see the parameter hints with a weird font (default system?) ! fyi
I haven't been able to reproduce this Are you still seeing this issue? Does it only show up with specific functions?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Yes, I still see this. I see this for all parameter hovers. I have nailed this down to be due to this setting I got a new mac, so most likely I do not have Fira Code installed. So the Editor seems to fall back nicely to a good default font, and Parameter Hints falls back to a non coding font. Which looks like the gist of this bug. I will reopen this so you can chime in. Thanks
Change:
} } } } this.diagnosticsCollection.set(document.uri, diagnostics); });

Discussion:
Following the addition of implicit activation events in the November release, we'd like to provide lint warnings via the extension-editing extension when an extension declares activation events which are already implied by its declared contributions.
cc as a heads up--we previously discussed this in and at the time agreed that a simple warning for the reserved/internal event was sufficient. We've since updated the docs and extension samples to mention that you don't need to explicitly list many events anymore. In discussion with Kai, the next step to round out this work and make extension authors aware of the new behavior is to provide lint warnings for all redundant events in the extension-editing extension. Let me know if you have any questions or concerns.
Change:
dependencies: is-number "^7.0.0" <del> typescript@5.1.3: version "5.1.3" resolved "https://registry.yarnpkg.com/typescript/-/typescript-5.1.3.tgz#8d84219244a6b40b6fb2b33cc1c062f715b9e826" integrity sha512-XH627E9vkeqhlZFQuL+UsyAXEnibT0kWR2FWONlr4sTjvxyJYnyefgrkyECLzM5NenmKzRAy2rR/OlYLA1HkZw== </del> <ins> typescript@5.1.6: version "5.1.6" resolved "https://registry.yarnpkg.com/typescript/-/typescript-5.1.6.tgz#02f8ac202b6dad2c0dd5e0913745b47a37998274" integrity sha512-zaWCozRZ6DLEWAWFrVDz1H6FVXzUSfTy5FUMWsQlU8Ym5JP9eO4xkTIROFCQvhQf61z6O/G6ugw3SgAnvvm+HA== </ins> vscode-grammar-updater@^1.1.0: version "1.1.0"

Discussion:
Track picking up
To verify, just open a TS file and click on the language status to check that the bundled TS version is 5.1.6
Change:
} } <ins> export class ResetCloseWithConflictsChoice extends Action2 { constructor() { super({ id: 'mergeEditor.resetCloseWithConflictsChoice', category: mergeEditorCategory, title: { value: localize( 'mergeEditor.resetChoice', 'Reset Choice for 'Close with Conflicts'' ), original: 'Reset Choice for 'Close with Conflicts'', }, f1: true, }); } run(accessor: ServicesAccessor): void { accessor.get(IStorageService).remove(StorageCloseWithConflicts, StorageScope.PROFILE); } } </ins> // this is an API command export class AcceptMerge extends MergeEditorAction2 { constructor() {

Discussion:
a conflict file in 3 way merge the 3 way merge editor Notice dialog ! I do not think we have a need for this dialog any more since we are no longer removing the conflict markers. Thus the user can just close this dialog, there is no data loss? Similarly when the user closes the old editor with conflict markers we do not prompt. fyi
I don't have an opinion about this.
I would leave it for the clarity it creates, however I am open for a "don't ask again" option
"Don't ask again" works for me, especially since I just noticed that when some conflicts get resolved the dialog is "smarter". Would don't ask again write in storage or a setting? I am fine going loco and writing to storage (so users can not revert). Though if all the other "don't ask again" write in settings then I guess I am fine with that.
+1 for "Don't ask again"
Fyi there is a very practical use case for the dialog: if you run with and use VSCode as Git merge editor, you may actually want to resolve the conflicts before closing the editor because Git somewhat expects you to do so. On top of that, given , we currently cannot pass back an exit code to Git, so it helps showing a dialog to avoid returning back to Git with merge conflicts still in the file. Besides, we show a similar dialog when you try to stage a file that has merge conflicts from the SCM view: !
thanks for providing more info, I missed that case. Though I think it does not conflict with our idea to add "Don't Ask Again".
Can we tell the merge editor if it was opened in a modal context (like with --wait)?
Currently not, an editor has no knowledge that it is being utilised for . There is plumbing around the editor where we observe the opened editor for being closed and then delete the wait marker file. Can we get more user feedback on this before jumping onto a conclusion?
Verify that there is an option to not be asked again there is a "Reset Choice for Close with Conflicts" commands in the F1 list <img width="1405" alt="Screenshot 2022-11-25 at 15 24 27" src="https://user-"
Adding verified since this works as expected. Noticed one minor "glitch".

"Don't ask again" Cancel The "Don't ask again" choice will be preserved. It should probably be only preserved if I click on "Close with Conflicts". I am not supper passionate about this, but let me know if you would like me to file an issue
Change:
if (lang && lang.toLocaleLowerCase() === 'json5') { lang = 'json'; } <ins> if (lang && lang.toLocaleLowerCase() === 'c#') { lang = 'cs'; } </ins> if (lang && hljs.getLanguage(lang)) { try { return `<div>${hljs.highlight(lang, str, true).value}</div>`;

Discussion:
Currently, as far as I am aware, the only accepted language identifiers for C# code blocks in the markdown preview are and . Other markdown previewers, like github and gitlab issue trackers, supports a third alternative: , as the following: csharp public int M() =2; //works everywhere c# public int M() =2; //doesn't work in vscode markdown preview My feature is request is for vscode to allow the mentioned alternative identifier. I also noticed something strange: the identifier works inside the editor, but not in the preview. I'd call this an inconsistency. !
Change:
*--------------------------------------------------------------------------------------------*/ import { onUnexpectedError } from 'vs/base/common/errors'; <ins> import { Event } from 'vs/base/common/event'; </ins> import { Disposable, DisposableMap } from 'vs/base/common/lifecycle'; import { URI } from 'vs/base/common/uri'; import { generateUuid } from 'vs/base/common/uuid';

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.59.1 OS Version: Win10 Bug description: WebviewPanel.viewColumn does not update when the column is changed by closing all files in a previous column. Steps to Reproduce: file in column 1 a WebviewPanel in column 2 file in column 1, shifting the WebviewPanel in column 2 into column 1 WebviewPanel.viewColumn Expected Result: WebviewPanel.viewColumn is correctly updated to reflect column 1 Actual Result: WebviewPanel.viewColumn says it is in column 2 until the user performs a tab action like opening or switching tabs.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.647 --- <!-- score: 0.556 --- <!-- score: 0.478 --<!-- potentialduplicates_comment --
<!-- 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!