jiebi/CodeConvo huggingface dataset:
Change:
@IConfigurationService private readonly _configurationService: IConfigurationService ) { super(); <del> this._register({ dispose: () => { this._commandStartedListener?.dispose(); this._commandFinishedListener?.dispose(); this._clearDecorations(); } }); </del> this._attachToCommandCapability(); this._register(this._contextMenuService.onDidShowContextMenu(() => this._contextMenuVisible = true)); this._register(this._contextMenuService.onDidHideContextMenu(() => this._contextMenuVisible = false)); this._hoverDelayer = this._register(new Delayer(this._configurationService.getValue('workbench.hover.delay'))); this._configurationService.onDidChangeConfiguration(e => { <del> if (e.affectsConfiguration(TerminalSettingId.ShellIntegrationCommandIcon) || e.affectsConfiguration(TerminalSettingId.ShellIntegrationCommandIconDefault) || e.affectsConfiguration(TerminalSettingId.ShellIntegrationCommandIconError)) { </del> <ins> console.log('changed', e.affectedKeys); if (e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationIcon) || e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationIconSuccess) || e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationIconError)) { </ins> for (const decoration of this._decorations) { if (decoration[1].decoration?.element) { <del> this._applyStyles(decoration[1].decoration.element); </del> <ins> this._applyStyles(decoration[1].decoration.element, decoration[1].exitCode); </ins> } } <ins> } else if (e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationsEnabled)) { if (!this._configurationService.getValue(TerminalSettingId.ShellIntegrationDecorationsEnabled)) { this._commandStartedListener?.dispose(); this._commandFinishedListener?.dispose(); this._clearDecorations(); } </ins> } }); } private _clearDecorations(): void { <del> for (const [, decorationDisposables] of Object.entries(this._decorations)) { decorationDisposables.decoration.dispose(); dispose(decorationDisposables.disposables); </del> <ins> this._placeholderDecoration?.dispose(); this._placeholderDecoration?.marker.dispose(); for (const value of this._decorations.values()) { value.decoration.dispose(); value.decoration.marker.dispose(); dispose(value.disposables); </ins> } this._decorations.clear(); <ins> this.dispose(); </ins> } private _attachToCommandCapability(): void {

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:
} } <del> private async _onWillCreateEditSessionIdentity(workspaceFolder: vscode.WorkspaceFolder, cancellationToken: vscode.CancellationToken, publishBeforeContinueOn: 'always' | 'prompt'): Promise<void> { const cancellationPromise = createCancellationPromise(cancellationToken); await Promise.race([this._doPublish(workspaceFolder, publishBeforeContinueOn), cancellationPromise]); </del> <ins> private async _onWillCreateEditSessionIdentity(workspaceFolder: vscode.WorkspaceFolder): Promise<void> { await this._doPublish(workspaceFolder); </ins> } <del> private async _doPublish(workspaceFolder: vscode.WorkspaceFolder, publishBeforeContinueOn: 'always' | 'prompt') { </del> <ins> private async _doPublish(workspaceFolder: vscode.WorkspaceFolder) { </ins> await this.model.openRepository(path.dirname(workspaceFolder.uri.fsPath)); const repository = this.model.getRepository(workspaceFolder.uri);

Discussion:
Testing on Windows 11, latest Insiders When I selected in the publish warning, the same notification toasted again. ! ! I hit Cancel again, and I was then prompted to sign into GitHub, which I already did in the browser before getting the branch toast: ! Perhaps tied to
I realize I'm now getting duplicate toasts after any option. When I selected Allow, I got the same toast again: !

Testing Choosing Never failed: <img width="458" alt="image" src="https://user-"
Choosing Always also failed: <img width="453" alt="image" src="https://user-"
I was using a public repo:
I experience the same on Windows 11 with the repo:
Create New Codespace still fails with ContinueOn
The original issue reported here was due to the fact that we weren't properly awaiting the branch publish before invoking the codespace creation. based on our offline discussion I think you're encountering a different issue because the publish completes but the codespace creation doesn't start, and only if you aren't signed into the GitHub Codespaces extension, so I'm going to close this issue and we can file a new one to investigate the scenario you've uncovered since I can't reproduce it at the moment:

Testing I can't choose to publish and ask again next time: <img width="264" alt="image" src="https://user-"
Also: The text doesn't indicate that the Always/Never choice only applies to the current workspace folder (as I just discovered) and not to all repositories.
+1, I was about to file the same issue.
Great feedback, this leads me to think we should just have 'Yes' and 'Cancel' as the options here, because choosing 'Never' will break the Continue On flow (i.e. it's not an option that we can actually support, and per we should actually throw a and bail out of the whole flow here).
'Publish Branch' might be clearer than 'Yes'. The PR extension uses this dialog: <img width="261" alt="image" src="https://user-"
The "fix" for this is more problematic for me. I used to have this in my settings: Now every time I quit VS Code (I'm on Mac if it makes a difference), I see the dialog and I have to press "Cancel". Even worse, pressing "Cancel" seems to only close the dialog and reopen it again. can we reopen this issue and restore the setting at least? That'd be highly appreciated. Thanks.
Change:
// regexes to check for trivial glob patterns that just check for String#endsWith const T1 = /^**/*.[w.-]+$/; 						   									// **/*.something const T2 = /^**/([w.-]+)/?$/; 							   							// **/something <del> const T3 = /^{**/[*.]?[w.-]+/?(,**/[*.]?[w.-]+/?)*}$/; 						// {**/*.something,**/*.else} or {**/package.json,**/project.json} const T3_2 = /^{**/[*.]?[w.-]+(/(**)?)?(,**/[*.]?[w.-]+(/(**)?)?)*}$/; 	// Like T3, with optional trailing /** </del> <ins> const T3 = /^{**/*?[w.-]+/?(,**/*?[w.-]+/?)*}$/; 						// {**/*.something,**/*.else} or {**/package.json,**/project.json} const T3_2 = /^{**/*?[w.-]+(/(**)?)?(,**/*?[w.-]+(/(**)?)?)*}$/; 	// Like T3, with optional trailing /** </ins> const T4 = /^**((/[w.-]+)+)/?$/; 						   								// **/something/else const T5 = /^([w.-]+(/[w.-]+)*)/?$/; 						   							// something/else

Discussion:
is a very popular textmate color scheme optimised for es6 / es7 / JSX. I imported the and made the changes to the file mentioned here , however the results are quite different to the same textmate theme in sublime. ! ! Its a beautiful theme used by the likes of and I would love to see equivalent support for this theme in VSCode.
We only have a small set of themes that are included with vscode, most themes are typically put on the marketplace. Two developers have put ports of OceanicNext up so you can try them out:
Why is this issue being closed? VSCode is supposed to support textmate themes. Here is a textmate theme that is not working. There are clearly gaps in VSCode's theme support, for example the in the top import statement is not colored. Shouldn't the same textmate theme appear consistently across various editors?
You're right, I interpreted this as there's no officially supported theme but there are indeed a bunch of issues preventing full parity with the other editors. I'll leave this closed but created a bunch of issues for the main problems causing this. Thanks for the report!
same here: ! !
Change:
import { IInstantiationService } from '../../../../platform/instantiation/common/instantiation.js'; export class MultiDiffEditorViewModel extends Disposable { <del> private readonly _documents: IObservable<readonly RefCounted<IDocumentDiffItem>[]> = observableFromValueWithChangeEvent(this.model, this.model.documents); </del> <ins> private readonly _documents: IObservable<readonly RefCounted<IDocumentDiffItem>[] | 'loading'> = observableFromValueWithChangeEvent(this.model, this.model.documents); private readonly _documentsArr = derived(this, reader => { const result = this._documents.read(reader); if (result === 'loading') { return []; } return result; }); public readonly isLoading = derived(this, reader => this._documents.read(reader) === 'loading'); </ins> public readonly items: IObservable<readonly DocumentDiffItemViewModel[]> = mapObservableArrayCached( this, <del> this._documents, </del> <ins> this._documentsArr, </ins> (d, store) => store.add(this._instantiationService.createInstance(DocumentDiffItemViewModel, d, this)) <del> ) .recomputeInitiallyAndOnChange(this._store); </del> <ins> ).recomputeInitiallyAndOnChange(this._store); </ins> public readonly focusedDiffItem = derived(this, reader => this.items.read(reader).find(i => i.isFocused.read(reader))); public readonly activeDiffItem = derivedObservableWithWritableCache<DocumentDiffItemViewModel | undefined>(this,

Discussion:
open a multifile diff reload window while the diff editor stores and loads it says that there are no changes yet <img width="1178" alt="Screenshot 2024-06-21 at 09 16 43" src=""
Thanks for filing! Briefly looked into it, but fixing it is a little bit more complex than I thought. The model creation is what takes a while, and during that time the multi file diff editor just has no model. It would be better if the model creation is immediate, but it has some property, that the editor could then show.
Change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import { DisposableStore } from 'vs/base/common/lifecycle'; import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IChatAgentService, ChatAgentLocation } from 'vs/workbench/contrib/chat/common/chatAgents'; import { TerminalChatContextKeys } from 'vs/workbench/contrib/terminal/browser/terminalContribExports'; export class TerminalChatEnabler { static Id = 'terminalChat.enabler'; private readonly _ctxHasProvider: IContextKey<boolean>; private readonly _store = new DisposableStore(); constructor( @IContextKeyService contextKeyService: IContextKeyService, @IChatAgentService chatAgentService: IChatAgentService ) { this._ctxHasProvider = TerminalChatContextKeys.hasChatAgent.bindTo(contextKeyService); this._store.add(chatAgentService.onDidChangeAgents(() => { const hasTerminalAgent = Boolean(chatAgentService.getDefaultAgent(ChatAgentLocation.Terminal)); this._ctxHasProvider.set(hasTerminalAgent); })); } dispose() { this._ctxHasProvider.reset(); this._store.dispose(); } } </ins>

Discussion:
The context key used in terminal and notebook chat which is wrong because it signals that there is a chat participant for the editor location and it doesn't know anything about other locations.
It's now removed from the notebook side.
Change:
return result; } <del> function bottomUp(model: IProfileModel, topN: number, fullPaths: boolean = false) { </del> <ins> function getHeaviestLocationIds(model: IProfileModel, topN: number) { const stackSelfTime: { [locationId: number]: number } = {}; for (const node of model.nodes) { stackSelfTime[node.locationId] = (stackSelfTime[node.locationId] || 0) + node.selfTime; } const locationIds = Object.entries(stackSelfTime) .sort(([, a], [, b]) => b - a) .slice(0, topN) .map(([locationId]) => Number(locationId)); return new Set(locationIds); } function bottomUp(model: IProfileModel, topN: number, fullPaths: boolean = false) { </ins> const root = BottomUpNode.root(); <ins> const locationIds = getHeaviestLocationIds(model, topN); </ins> for (const node of model.nodes) { <del> processNode(root, node, model); root.addNode(node); </del> <ins> if (locationIds.has(node.locationId)) { processNode(root, node, model); root.addNode(node); } </ins> } const result = Object.values(root.children) .sort((a, b) => b.selfTime - a.selfTime) .slice(0, topN); const samples: BottomUpSample[] = []; for (const node of result) {

Discussion:
Recently I've been seeing a lot more native window crashes. In particular, I can reliably get a crash to happen in a minute when editing js-debug's . Here's a dump of one:
I have symbolicated the crash dump. The crash seems to occur from running out of memory. Are you able to create a memory profile?
Looks like it has to do when extension host profiling. CpuProfileAnalysis rapidly eats memory then crashes the page <img width="585" alt="Screenshot 2022-12-15 at 1 19 27 PM" src="https://user-"
you would also need to add symbols for
It's your code that I have copied Can you help me with it?
Here is the updated symbolicated crash dump. New info here:
I can easy reproduce. It looks like the model we build for bottom up profiles is just very memory intensive in some scenarios. However I also notice that we scarcely use the full bottom-up profile, unlike the profile editor, and can do more targeted analysis instead. I will prepare a PR.
Thanks
What did you do to trigger the crash?
For me, installing the plugin and opening js-debug's gulpfile for several seconds reliably does it. Verify that you see "starting to profile NOW" in the debug console, and that VS Code doesn't crash shortly afterwards when that finishes.
Change:
this.block = null; } <del> this.focusToReturn?.focus(); </del> <ins> this.blockDisposable?.dispose(); if (!!this.lastContainer && (getActiveElement() === this.lastContainer || isAncestor(getActiveElement(), this.lastContainer))) { this.focusToReturn?.focus(); } this.lastContainer = null; </ins> } }, shadowRootElement, !!shadowRootElement); }

Discussion:
click to open context menu in text editor +P to open quick open :bug: both context menu and quick open are dismissed !
re: context menu
This is not a regression so assigning to december
I'm going to pass to you for your take. Here's what I found out. When we show the command palette that causes the editor context menu to trigger the hide: This hide, focuses the editor... but in doing so, that causes the Quick Pick's didBlur to hide: which will hide the quick pick if is set to which is the default. This behavior with context menus seems to repro: Always in context menus of the editor Only with custom menus (not native menus) in the rest of the product (tree views, Account/Gear menu, etc)
Two actions here: needs to be removed or handled better (passing that to or menus should follow the logic: if ESC/selection, focus what was previously focused. If dismissed due to focus lost, don't restore focus (this goes to
my suspicion is that the editor contribution is old and unnecessary as the behavior is built-in to the menu widget. Removing it, we can centralize the logic to the menu widget.
re-opening as we still have some work to do on the custom menu side
Change:
fontFamily: fontFamily, wrappingStrategy: 'advanced', wrappingIndent: 'none', <del> padding: { top: 3, bottom: 3 }, </del> <ins> padding: { top: 2, bottom: 2 }, </ins> quickSuggestions: false, scrollbar: { alwaysConsumeMouseWheel: false }, overflowWidgetsDomNode,

Discussion:
Perhaps due to semi-opaque color being applied to multiple layers within the input: <img width="210" alt="CleanShot 2022-12-15 at 11 28 11 src="https://user-"<img width="289" alt="CleanShot 2022-12-15 at 11 28 23 src="https://user-"
The source control message input background does not seem to use color customization at all.
I saw it in there, but it's a fairly complex component under the hood and (I think) multiple layers of the component use it. Because the color is semi-opaque it's appearing brighter than it should be after mixing with one layer with another.
You can reproduce & verify that the colour is not applied to this particular input by setting color customization in your settings JSON to a bright red: Observe all other inputs having bright red backgrounds but the commit message input background still having the same background as the surrounding panel's background.
This is what I am seeing with the built-in theme, it looks like it completely blends with the panel's background. For me this is happening with all themes, built-in & third-party - the input's background inherits the panel's background and cannot be customised at all. !
It works for me. I don't see the behavior you do with a transparent background. I'm also noting that you have a different typeface used for the placeholder. That leads me to believe there is something else going on. Are you using any extensions that manipulate VS Code e.g. customize UI? <img width="314" alt="CleanShot 2022-12-15 at 13 26 22 src="https://user-"In any case this will be fixed by . I'd recommend opening up a separate issue for your specific problem.
It works for me too when I place SCM panel to the left sidebar, but when SCM panel is placed to the right sidebar then background colour theming is ignored on the input. I do not see this problem mentioned in . ! !
That one I can indeed repro. Can you file a new issue for that?
Done! Submitted as .
Change:
{ <ins> "ban-eval-calls": [ "vs/workbench/api/worker/extHostExtensionService.ts" ], "ban-function-calls": [ "vs/workbench/api/worker/extHostExtensionService.ts", "vs/workbench/contrib/notebook/browser/view/renderers/webviewPreloads.ts", "vs/workbench/services/keybinding/test/electron-browser/keyboardMapperTestUtils.ts" ], </ins> "ban-trustedtypes-createpolicy": [ <del> "**/*.ts" </del> <ins> "vs/base/browser/dom.ts", "vs/base/browser/markdownRenderer.ts", "vs/base/worker/defaultWorkerFactory.ts", "vs/base/worker/workerMain.ts", "vs/editor/browser/core/markdownRenderer.ts", "vs/editor/browser/view/domLineBreaksComputer.ts", "vs/editor/browser/view/viewLayer.ts", "vs/editor/browser/widget/diffEditorWidget.ts", "vs/editor/browser/widget/diffReview.ts", "vs/editor/standalone/browser/colorizer.ts", "vs/workbench/api/worker/extHostExtensionService.ts", "vs/workbench/contrib/notebook/browser/view/renderers/cellRenderer.ts", "vs/workbench/contrib/notebook/browser/view/renderers/webviewPreloads.ts", "vs/workbench/services/extensions/browser/webWorkerExtensionHost.ts", "vs/workbench/services/extensions/worker/extensionHostWorkerMain.ts" ], "ban-worker-calls": [ "vs/base/worker/defaultWorkerFactory.ts", "vs/workbench/services/extensions/browser/webWorkerExtensionHost.ts" </ins> ] }

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. --See for context the tsec-compile-check action currently has a many outputs, making it difficult to notice when new security-sensitive code is . by listing all of the current violations in the tsec exemption file we can ensure that the output of tsec-compile-check stays empty unless someone adds code with a new violation.
wow. chrismas-clean
Thanks for this. I believe it's again time to enable this in the CI pipelines and to bring back the tsserver integration. The only remaining worry is our aggressive TS adoption strategy which can often mean that tsec is facing TS features is doesn't understand yet.
tsec is part of our CI pipeline I also tried to configure the tsserver plugin but I couldn't get it to accept the exemptions list. I have tried with below snippet in
for visibility on the tssever plugin issue
There is a bug in the plugin. Fix is on the way.
The bug in the plugin should have been fixed in 0.1.4.
Thanks. Adopted and enabled
Change:
} submitFeedback(feedback: IFeedback, openerService: IOpenerService): void { <del> const queryString = `?${feedback.sentiment === 1 ? `hashtags=${this.combineHashTagsAsString()}&` : null}ref_src=twsrc%5Etfw&related=twitterapi%2Ctwitter&text=${encodeURIComponent(feedback.feedback)}&tw_p=tweetbutton&via=${TwitterFeedbackService.VIA_NAME}`; </del> <ins> const queryString = `?${feedback.sentiment === 1 ? `hashtags=${this.combineHashTagsAsString()}&` : ''}ref_src=twsrc%5Etfw&related=twitterapi%2Ctwitter&text=${encodeURIComponent(feedback.feedback)}&tw_p=tweetbutton&via=${TwitterFeedbackService.VIA_NAME}`; </ins> const url = TwitterFeedbackService.TWITTER_URL + queryString; openerService.open(URI.parse(url));

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: --The query parameter for "refsrc" when submitting "sad" feedback is "nullrefsrc" instead of just "refsrc" because null is erroneously concatenated. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.51.1 (user setup) OS Version: WindowsNT x64 10.0. Steps to Reproduce: the tweet feedback UI using the button in the bottom right of code. the sad face some tweet content tweet resulting URL will be something like ,twitter&text=123&twp=tweetbutton&via=code <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.684 --- <!-- score: 0.579 --<!-- potentialduplicatescomment --
Up for grab.
It's still nullref for me: ^tfw&related=twitterapi,twitter&text=Testing&twp=tweetbutton&via=code
not for me when I update insiders to latest, what's your insiders version?
It works for me now too, after updating again. /verified