jiebi/CodeConvo huggingface dataset:
Change:
private registerListeners(): void { // Storage <del> this._register(this.storageService.onWillSaveState(() => this.saveState())); </del> <ins> this._register(this.storageService.onWillSaveState(e => this.saveState(e))); </ins> // Listen to visible editor changes this._register(this.editorService.onDidVisibleEditorsChange(() => this.onDidVisibleEditorsChange()));

Discussion:
zen mode vscode, start vscode that zen mode properly is not restored excepted centered layout. Centered layout should also be inactive (since is )
acutally your change from that commit caused this. You removed that the zen mode gets out of zen mode when you are exiting. Let me look into a fix
the idea is to only write to local storage from and not . Is writing any data to local storage? If not, this change seems fine.
it is writing data to local storage. I just need to write it before the workbench goes down. So I will react on instead of . That event will only get fired once before the workbench shuts down?
yeah currently that is right. In the future when we decide to store state more periodically we might decide to call this method more often though to preserve state even if Code is crashing. I do not understand why you have to leave Zen mode on shutdown because you will restore it on the next startup, no? Given that, I suggest to NOT leave Zen mode on shutdown but rather simply NOT restore it on next startup. Isn't that easier?
thanks for clarification. I can not simply NOT restore it on next startup since the subsets of zen mode will have written state to storage. Example: User enters zen mode -zen mode tells Sidebar hide yourself. Sidebar writes that into storage Next vscode start -zen mode is not restored, Sidebar is still hidden because he wrote into storage once we activated zen mode. Due to how the feature is designed it needs to explicitly tell the underlying parts to hide or show. We could change this, but that would require that every underlying part is aware of zen mode which might overcomplicate things. Suggestions on how to tackle this are also welcome Thanks
got it. I pushed a change so that carries a with a reason you can ask for. On shutdown that reason will be set and so you can do the same things as before. As long as you are not running async code that accesses storage late, things should be fine. The goal should be that storage layer gets accessed either: when changes happen (e.g. workbench layout does that) or (which currently only fires on shutdown but might fire periodically later)
this works.

However there was a corner case for the reload since we were restoring zen mode always on reload and in your event i was not getting if it is a reload or regular shutdown Though fixed it by not auto restoring zen mode on reload. I think this is perfectly fine. Users should set zenMode.restore to true if they want this
thank you
Change:
}, { "name": "Class Variable", <del> "scope": "variable.other, variable.js, punctuation.separator.variable", </del> <ins> "scope": "variable.js, punctuation.separator.variable", </ins> "settings": { "fontStyle": "n    ttt", "foreground": "#6089B4"

Discussion:
VSCode Version: 1.13.0 OS Version: Mint 18 Steps to Reproduce: to print `this.someMethod(); You can see, that "this" is colorless. It's so bad, because I need with this highlight when I work with classes. For example comparsion between VS code(left) and Sublime (right). Also highlight for arguments sometimes is in place, sometimes is not. !
You can install extension for this. I recommended or
This is not a bug in the grammar. Other themes colorize just fine: ! Monokai does not however
Change:
this.providerRegistration = vscode.workspace.registerEditSessionIdentityProvider('file', this); vscode.workspace.onWillCreateEditSessionIdentity((e) => { <del> const publishBeforeContinueOn = vscode.workspace.getConfiguration('git').get<'never' | 'always' | 'prompt'>('publishBeforeContinueOn', 'prompt'); if (publishBeforeContinueOn !== 'never') { e.waitUntil(this._onWillCreateEditSessionIdentity(e.workspaceFolder, e.token, publishBeforeContinueOn)); } </del> <ins> e.waitUntil(this._onWillCreateEditSessionIdentity(e.workspaceFolder)); </ins> }); }

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:
'default': 'file', 'enum': [ 'file', <del> 'modifications' </del> <ins> 'modifications', 'modificationsIfAvailable' </ins> ], 'enumDescriptions': [ nls.localize({ key: 'everything', comment: ['This is the description of an option'] }, "Format the whole file."), nls.localize({ key: 'modification', comment: ['This is the description of an option'] }, "Format modifications (requires source control)."), <ins> nls.localize({ key: 'modificationIfAvailable', comment: ['This is the description of an option'] }, "Will attempt to format modifications only (requires source control). If source control can't be used, then the whole file will be formatted."), </ins> ], 'markdownDescription': nls.localize('formatOnSaveMode', "Controls if format on save formats the whole file or only modifications. Only applies when `#editor.formatOnSave#` is enabled."), 'scope': ConfigurationScope.LANGUAGE_OVERRIDABLE,

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. --It would be nice to have either a toggle or a third option (or even just have this as default behavior for "modifications" mode of format on save) that tells VS Code to format the entire file on save if version control is unavailable. I find it annoying to have to configure every new repository workspace I make to use modifications instead of my User setting of file. Perhaps there is already an extension for this that I've not found yet. Either way, code for thought.
Actually, I've had a look into the code-base and it looks fairly easy to do, so I'll add the third option approach myself and create a PR. Up to you legends what you do with it tho
Change:
})); } <ins> async getExistingTunnel(remoteHost: string, remotePort: number): Promise<RemoteTunnel | undefined> { if (isAllInterfaces(remoteHost) || isLocalhost(remoteHost)) { remoteHost = LOCALHOST_ADDRESSES[0]; } const existing = this.getTunnelFromMap(remoteHost, remotePort); if (existing) { ++existing.refcount; return existing.value; } return undefined; } </ins> openTunnel(addressProvider: IAddressProvider | undefined, remoteHost: string | undefined, remotePort: number, localPort?: number, elevateIfNeeded: boolean = false, privacy?: string, protocol?: string): Promise<RemoteTunnel | undefined> | undefined { this.logService.trace(`ForwardedPorts: (TunnelService) openTunnel request for ${remoteHost}:${remotePort} on local port ${localPort}.`); if (!addressProvider) {

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. --I'm using the 'Remote - SSH' extension. Suppose I set up static forwarding in my local : So port 3000 is statically forwarded to port 3000. Now if I output a link to the terminal (from within the remote), when this link is 'Command + Clicked', vscode opens in the browser - the wrong port, because it's auto-forwarded to the next available port. It feels like if static forwarding for this port is already set up, it could always infer that no auto port forwarding is needed and hence open in the browser at port 3000. The setting does not help in this case. Thanks :)
does the SSH extension use () to ensure that statically forwarded ports like this show in the ports view?
Yes
Thanks for confirming!
This looks like it will be a larger change. Moving to September.
Hi. Just encountered this problem today. I am using VSCode Docker remotes with Docker Desktop. One of my containers is running minio. There is a static port forward configured in that looks like this: My application sometimes prints out a full URL to the integrated terminal that looks like Clicking that link to open it in my web browser causes VSCode to dynamically forward a brand new port and rewrite the URL replacing the 9000 with something like . I would actually be ok with that, but that URL with the new port number doesn't even work. The original one does work. My situation sounds basically the same as OP, only using Docker remote instead of SSH remote. Just wanted to share my use case to verify it is actually the same issue and that whatever solution comes will solve it for both of us. I also want to say this feature was very unexpected. Personally, I think it should be off by default. URLs should be opened exactly as they are written. Please provide at least a setting so I can always open URLs from integrated terminal exactly as they appear. The back of my mind also wonders if there could be any potential security implication of rewriting URLs this way. Thanks.
Change:
import { IBreakpoint, IDebugService, IDebugSession } from 'vs/workbench/contrib/debug/common/debug'; import { IPreferencesService } from 'vs/workbench/services/preferences/common/preferences'; import { URI } from 'vs/base/common/uri'; <del> import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </del> <ins> import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </ins> const GUTTER_INLINE_CHAT_OPAQUE_ICON = registerIcon('inline-chat-opaque', Codicon.sparkle, localize('startInlineChatOpaqueIcon', 'Icon which spawns the inline chat from the gutter. It is half opaque by default and becomes completely opaque on hover.')); const GUTTER_INLINE_CHAT_TRANSPARENT_ICON = registerIcon('inline-chat-transparent', Codicon.sparkle, localize('startInlineChatTransparentIcon', 'Icon which spawns the inline chat from the gutter. It is transparent by default and becomes opaque on hover.')); export class InlineChatDecorationsContribution extends Disposable implements IEditorContribution { <del> private _ctxToolbarIconEnabled: IContextKey<boolean>; </del> private _currentBreakpoints: readonly IBreakpoint[] = []; private _gutterDecorationID: string | undefined; private _inlineChatKeybinding: string | undefined;

Discussion:
We have as explicit context key which is driven with the . This is all fine but actually not needed. Any configuration is automatically a context key when prefixed with - , the setting is and you can use as context key
That's useful, thank you I didn't know
Change:
import { equals } from 'vs/base/common/objects'; import { IEditSessionIdentityService } from 'vs/platform/workspace/common/editSessions'; import { ThemeIcon } from 'vs/platform/theme/common/themeService'; <ins> import { IOutputService } from 'vs/workbench/services/output/common/output'; import * as Constants from 'vs/workbench/contrib/logs/common/logConstants'; </ins> registerSingleton(IEditSessionsLogService, EditSessionsLogService); registerSingleton(IEditSessionsStorageService, EditSessionsWorkbenchService);

Discussion:
Testing ! It would be nice if that text is a hyperlink which opens the output channel, similar to above: !
/verified
Change:
import { ICodeEditor, IEditorMouseEvent, MouseTargetType } from 'vs/editor/browser/editorBrowser'; import { registerEditorContribution, EditorContributionInstantiation } from 'vs/editor/browser/editorExtensions'; import { IEditorContribution } from 'vs/editor/common/editorCommon'; <del> import { IMenuService, MenuId } from 'vs/platform/actions/common/actions'; </del> <ins> import { IMenuService, MenuId, MenuItemAction, SubmenuItemAction } from 'vs/platform/actions/common/actions'; </ins> import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IContextMenuService } from 'vs/platform/contextview/browser/contextView'; import { TextEditorSelectionSource } from 'vs/platform/editor/common/editor';

Discussion:
configure "testing.defaultGutterClickAction": "contextMenu", open a test file and click on a test icon a context menu opens but the test commands aren't atop <img width="356" alt="Screenshot 2023-03-31 at 15 41 37" src="https://user-"
Change:
return configuredUseWindowControlsOverlay; } <del> return true; // enabled by default </del> <ins> return false; // disable by default </ins> } export interface IPath<T = IEditorOptions> extends IPathData<T> {

Discussion:
This happened to me: Then, having disabled the experience altogether, I still have this tall version of the WCO: !

<!-- 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.71.0 OS Version: Windows 10 BEFORE UPDATING: ! AFTER UPDATING: ! Steps to Reproduce: vscode to version 1.71.0 decides to move the closing button location
Are you using a right-to-left language for your OS? Mitigation: Disable the setting and reload the window.
yes, I am using an RTL language for my OS but this has never been an issue in previous versions. edit: I tried your suggestion of disabling and it was indeed disabled by default in v1.70.2 but was enabled by default in v1.71.0
I'm curious whether native Windows apps show their controls at top-left when using an RTL language?
This is expected since the controls are drawn natively by the runtime rather than the application drawing it before . Other native windows application also move the controls to for RTL languages. We should adjust the rest of titlebar contents to match this behavior.
! This is what Google Chrome title bar looks like if that answers your question ! And windows file explorer Edit: Whoever set this issue as win11, I'm using windows 10...
I have the same bug. How can I solve this problem?
Disable the setting
I don't think VS Code should move the titlebar contents if it is still displaying the text in English. In the screenshot below, I have VS Code, Notepad++, Paint, and Outlook loaded, and Paint is the only one with both RTL text and mirrored controls. ! P.S. I can't read Farsi.

open setting by search about uncheck it.
I agree. I was under the impression this bug also affected users who had RTL display language set in VSCode. Native applications I had tested was when application also had the same display language as the system. I can confirm the alignment behavior of WCO when application has LTR while system has RTL.
As suggested above, disabling window.experimental.windowControlsOverlay.enabled solved the issue.
Change:
githubAccessToken }, dataOverrides); <ins> if (issueReporterData.extensionId) { const extensionExists = extensionData.some(extension => extension.id === issueReporterData.extensionId); if (!extensionExists) { console.error(`Extension with ID ${issueReporterData.extensionId} does not exist.`); } } </ins> if (issueReporterData.extensionId && this.extensionIdentifierSet.has(issueReporterData.extensionId)) { ipcRenderer.send(`vscode:triggerReporterMenuResponse:${issueReporterData.extensionId}`, issueReporterData); this.extensionIdentifierSet.delete(new ExtensionIdentifier(issueReporterData.extensionId));

Discussion:
Testing I had the arg For and clicking "Create on GitHub" did nothing. I would expect an error to log in the console for this so that devs know what has happened.
Did this log anything in the console? (ie, or something like that)
I didn't see anything in the debug console.
Technically, it's a valid URI, but it doesn't resolve to a valid endpoint.

Testing <img alt="image" src=""For this, I put an invalid , and as expected, the field in the issue reporter is not set to a specific extension. However, I'd appreciate a warning log in the debug console that warns devs that they have an invalid
Change:
); renderDisposables.add(this.codeActionList.value.onDidChangeSelection(e => this._onListSelection(e))); <ins> renderDisposables.add(this._editor.onDidLayoutChange(e => this.hideCodeActionWidget())); </ins> // Populating the list widget and tracking enabled options. inputArray.forEach((item, index) => {

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/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: OS Version: Type: Bug Using editor.experimental.useCustomCodeActionMenu, the menu doesn't match up with the colors of enabled/disabled options or the background of the other context menus

Type: <bBug</bmenu the window Bug The widget ends up being incorrectly positioned: <img width="672" alt="Screen Shot 2022-07-21 at 1 24 17 PM" src="https://user-"VS Code version: Code - Insiders 1.70.0-insider (Universal) (, 2022-07-21T05:17:20.056Z) OS version: Darwin x64 21.5.0 Modes: <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
suite('Workbench - TerminalProfiles', () => { suite('detectAvailableProfiles', () => { if (isWindows) { <del> suite('detectAvailableWindowsProfiles', async () => { test('should detect Git Bash and provide login args', async () => { </del> <ins> suite.skip('detectAvailableWindowsProfiles', async () => { test.skip('should detect Git Bash and provide login args', async () => { </ins> const _paths = [`C:Program FilesGitbinbash.exe`]; const config: ITestTerminalConfig = { profiles: {

Discussion:
fixed with
To verify on Windows: a new terminal profile with source set to powershell a -NoProfile arg sure it launches a no profile pwsh session
Change:
const pick = _createPick(session, filter, debugService, viewsService, commandService); if (pick) { debugConsolePicks.push(pick); <ins> if (session.getId() === currSession?.getId()) { activeItems.push(pick); } </ins> } } });

Discussion:
Testing Placeholder could be more concise, for example "Search for debug session by name" -"Search debug session by name" !
Would it be better to have "Search debug sessions by name"? I noticed that the loaded script view says "Search loaded scripts by name". <img width="754" alt="image" src="https://user-"
The plural makes sense to me :) Thanks