jiebi/CodeConvo huggingface dataset:
Code change:
<!-- 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. -- introduces which controls when we attempt to restore an edit session for the current workspace. The user still has to remember to store their edit session or use the explicit Continue Working On trigger. In order to make it harder to lose edit sessions across , , , and RemoteHub on desktop, we should introduce a setting with initial setting values and . When set to , we'll attempt to store the current edit session (if any) before a workbench unload. This will only really reliably work in desktop because in web we cannot run long running tasks in the onbeforeunload handler (, tracked in ). To mitigate this we should also explore introducing an option to continuously sync edit sessions. That first requires tolerance of edit sessions originating from multiple VS Code clients concurrently.
On , we do have a service worker which is used primarily for caching. Service workers can outlive their associated pages, and can be synchronously 'd to like other workers. Perhaps we can use that service worker (or a new one) to allow the workbench to send information to save before it unloads.

Related discussion:
text: @IQuickInputService private readonly quickInputService: IQuickInputService, @ICommandService private commandService: ICommandService, @IContextKeyService private readonly contextKeyService: IContextKeyService, <del> @IFileDialogService private readonly fileDialogService: IFileDialogService </del> <ins> @IFileDialogService private readonly fileDialogService: IFileDialogService, @ILifecycleService private readonly lifecycleService: ILifecycleService </ins> ) { super();
Code change:
<!-- 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. -- introduces which controls when we attempt to restore an edit session for the current workspace. The user still has to remember to store their edit session or use the explicit Continue Working On trigger. In order to make it harder to lose edit sessions across , , , and RemoteHub on desktop, we should introduce a setting with initial setting values and . When set to , we'll attempt to store the current edit session (if any) before a workbench unload. This will only really reliably work in desktop because in web we cannot run long running tasks in the onbeforeunload handler (, tracked in ). To mitigate this we should also explore introducing an option to continuously sync edit sessions. That first requires tolerance of edit sessions originating from multiple VS Code clients concurrently.
On , we do have a service worker which is used primarily for caching. Service workers can outlive their associated pages, and can be synchronously 'd to like other workers. Perhaps we can use that service worker (or a new one) to allow the workbench to send information to save before it unloads.

Related discussion:
text: this.shouldShowViewsContext = EDIT_SESSIONS_SHOW_VIEW.bindTo(this.contextKeyService); this._register(this.fileService.registerProvider(EditSessionsFileSystemProvider.SCHEMA, new EditSessionsFileSystemProvider(this.editSessionsWorkbenchService))); <ins> this.lifecycleService.onWillShutdown((e) => e.join(this.autoStoreEditSession(), { id: 'autoStoreEditSession', label: localize('autoStoreEditSession', 'Storing current edit session...') })); } private async autoStoreEditSession() { if (this.configurationService.getValue('workbench.experimental.editSessions.autoStore') === 'onShutdown') { await this.progressService.withProgress({ location: ProgressLocation.Window, type: 'syncing', title: localize('store edit session', 'Storing edit session...') }, async () => this.storeEditSession(false)); } </ins> } private registerViews() {
Code change:
<!-- 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. -- introduces which controls when we attempt to restore an edit session for the current workspace. The user still has to remember to store their edit session or use the explicit Continue Working On trigger. In order to make it harder to lose edit sessions across , , , and RemoteHub on desktop, we should introduce a setting with initial setting values and . When set to , we'll attempt to store the current edit session (if any) before a workbench unload. This will only really reliably work in desktop because in web we cannot run long running tasks in the onbeforeunload handler (, tracked in ). To mitigate this we should also explore introducing an option to continuously sync edit sessions. That first requires tolerance of edit sessions originating from multiple VS Code clients concurrently.
On , we do have a service worker which is used primarily for caching. Service workers can outlive their associated pages, and can be synchronously 'd to like other workers. Perhaps we can use that service worker (or a new one) to allow the workbench to send information to save before it unloads.

Related discussion:
text: Registry.as<IConfigurationRegistry>(Extensions.Configuration).registerConfiguration({ ...workbenchConfigurationNodeBase, 'properties': { <ins> 'workbench.experimental.editSessions.autoStore': { enum: ['onShutdown', 'off'], enumDescriptions: [ localize('autoStore.onShutdown', "Automatically store current edit session on window close."), localize('autoStore.off', "Never attempt to automatically store an edit session.") ], 'type': 'string', 'tags': ['experimental', 'usesOnlineServices'], 'default': 'off', 'markdownDescription': localize('autoStore', "Controls whether to automatically store an available edit session for the current workspace."), }, </ins> 'workbench.experimental.editSessions.enabled': { 'type': 'boolean', 'tags': ['experimental', 'usesOnlineServices'],
Code change:
<!-- 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. -- introduces which controls when we attempt to restore an edit session for the current workspace. The user still has to remember to store their edit session or use the explicit Continue Working On trigger. In order to make it harder to lose edit sessions across , , , and RemoteHub on desktop, we should introduce a setting with initial setting values and . When set to , we'll attempt to store the current edit session (if any) before a workbench unload. This will only really reliably work in desktop because in web we cannot run long running tasks in the onbeforeunload handler (, tracked in ). To mitigate this we should also explore introducing an option to continuously sync edit sessions. That first requires tolerance of edit sessions originating from multiple VS Code clients concurrently.
On , we do have a service worker which is used primarily for caching. Service workers can outlive their associated pages, and can be synchronously 'd to like other workers. Perhaps we can use that service worker (or a new one) to allow the workbench to send information to save before it unloads.

Related discussion:
text: import { Event } from 'vs/base/common/event'; import { IViewDescriptorService } from 'vs/workbench/common/views'; import { ITextModelService } from 'vs/editor/common/services/resolverService'; <ins> import { ILifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycle'; </ins> const folderName = 'test-folder'; const folderUri = URI.file(`/${folderName}`);
Code change:
<!-- 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. -- introduces which controls when we attempt to restore an edit session for the current workspace. The user still has to remember to store their edit session or use the explicit Continue Working On trigger. In order to make it harder to lose edit sessions across , , , and RemoteHub on desktop, we should introduce a setting with initial setting values and . When set to , we'll attempt to store the current edit session (if any) before a workbench unload. This will only really reliably work in desktop because in web we cannot run long running tasks in the onbeforeunload handler (, tracked in ). To mitigate this we should also explore introducing an option to continuously sync edit sessions. That first requires tolerance of edit sessions originating from multiple VS Code clients concurrently.
On , we do have a service worker which is used primarily for caching. Service workers can outlive their associated pages, and can be synchronously 'd to like other workers. Perhaps we can use that service worker (or a new one) to allow the workbench to send information to save before it unloads.

Related discussion:
text: // Stub out all services instantiationService.stub(IEditSessionsLogService, logService); instantiationService.stub(IFileService, fileService); <ins> instantiationService.stub(ILifecycleService, new class extends mock<ILifecycleService>() { override onWillShutdown = Event.None; }); </ins> instantiationService.stub(INotificationService, new TestNotificationService()); instantiationService.stub(IEditSessionsWorkbenchService, new class extends mock<IEditSessionsWorkbenchService>() { }); instantiationService.stub(IProgressService, ProgressService);
Code change:
Looking into adding additional separators that are more common, so that all the additional refactorings are not just clumped under From comment: I was wondering if you would consider adding 2 code action classes that are I think quite common: (Inline) (Move) This would be super valuable for the extension that I'm developing (P42 JavaScript Assistant), but I think also for other extensions. Afaik the TS language server also has actions for example. Originally posted by in
Hey , the new code action widget looks great, and I really like the new code action grouping, I'm wondering if we can define custom code action groups besides the pre-defined groups. ! you can see the java extension contributes a code action (in the light bulb) named "add Javadoc" and it's now under "More Actions..." menu. If we can define a new group like "Sources" via extension, it would be great and more clear that we can put this action in that group.
We have an extension that publishes some code actions. With the latest VSCode, our actions are grouped under 'More Actions...' which in our context is not ideal. We would prefer to be able to define our own grouping for our actions (in extension parlance, I think this means to be able to create our own ). Thanks!

Related discussion:
text: const codeActionGroups = Object.freeze<CodeActionGroup[]>([ { kind: CodeActionKind.QuickFix, title: localize('codeAction.widget.id.quickfix', 'Quick Fix...') }, <del> { kind: CodeActionKind.Extract, title: localize('codeAction.widget.id.extract', 'Extract...'), icon: { codicon: Codicon.wrench } }, { kind: CodeActionKind.Convert, title: localize('codeAction.widget.id.convert', 'Convert...'), icon: { codicon: Codicon.zap, color: 'var(--vscode-editorLightBulbAutoFix-foreground)' } }, { kind: CodeActionKind.SurroundWith, title: localize('codeAction.widget.id.surround', 'Surround With...'), icon: { codicon: Codicon.symbolArray } }, { kind: CodeActionKind.Source, title: localize('codeAction.widget.id.source', 'Source Action...'), icon: { codicon: Codicon.lightBulb, color: 'var(--vscode-editorLightBulb-foreground)' } }, </del> <ins> { kind: CodeActionKind.RefactorExtract, title: localize('codeAction.widget.id.extract', 'Extract...'), icon: { codicon: Codicon.wrench } }, { kind: CodeActionKind.RefactorInline, title: localize('codeAction.widget.id.inline', 'Inline...'), icon: { codicon: Codicon.wrench } }, { kind: CodeActionKind.RefactorRewrite, title: localize('codeAction.widget.id.convert', 'Rewrite...'), icon: { codicon: Codicon.wrench } }, { kind: CodeActionKind.RefactorMove, title: localize('codeAction.widget.id.move', 'Move...'), icon: { codicon: Codicon.wrench } }, { kind: CodeActionKind.SurroundWith, title: localize('codeAction.widget.id.surround', 'Surround With...'), icon: { codicon: Codicon.symbolSnippet } }, { kind: CodeActionKind.Source, title: localize('codeAction.widget.id.source', 'Source Action...'), icon: { codicon: Codicon.symbolFile } }, </ins> uncategorizedCodeActionGroup, ]);
Code change:
Looking into adding additional separators that are more common, so that all the additional refactorings are not just clumped under From comment: I was wondering if you would consider adding 2 code action classes that are I think quite common: (Inline) (Move) This would be super valuable for the extension that I'm developing (P42 JavaScript Assistant), but I think also for other extensions. Afaik the TS language server also has actions for example. Originally posted by in
Hey , the new code action widget looks great, and I really like the new code action grouping, I'm wondering if we can define custom code action groups besides the pre-defined groups. ! you can see the java extension contributes a code action (in the light bulb) named "add Javadoc" and it's now under "More Actions..." menu. If we can define a new group like "Sources" via extension, it would be great and more clear that we can put this action in that group.
We have an extension that publishes some code actions. With the latest VSCode, our actions are grouped under 'More Actions...' which in our context is not ideal. We would prefer to be able to define our own grouping for our actions (in extension parlance, I think this means to be able to create our own ). Thanks!

Related discussion:
text: public static readonly Empty = new CodeActionKind(''); public static readonly QuickFix = new CodeActionKind('quickfix'); public static readonly Refactor = new CodeActionKind('refactor'); <del> public static readonly Extract = CodeActionKind.Refactor.append('extract'); public static readonly Convert = CodeActionKind.Refactor.append('rewrite'); </del> <ins> public static readonly RefactorExtract = CodeActionKind.Refactor.append('extract'); public static readonly RefactorInline = CodeActionKind.Refactor.append('inline'); public static readonly RefactorMove = CodeActionKind.Refactor.append('move'); public static readonly RefactorRewrite = CodeActionKind.Refactor.append('rewrite'); </ins> public static readonly Source = new CodeActionKind('source'); public static readonly SourceOrganizeImports = CodeActionKind.Source.append('organizeImports'); public static readonly SourceFixAll = CodeActionKind.Source.append('fixAll');
Code change:
! Only seems to appear if I resize the terminal such that a is on its own line.
Cannot repro: !
I can still reproduce this? For example cat this file to your terminal Then drag until a quote is the only thing on one of the lines. This causes the link detection to detect everything below that quote.
Couldn't repro on Windows but I do see some offset problem after the resizes: ! Probably an issue with reflow (mac/Linux)
In tried on my mac and I still can't reproduce: !
Still able to reproduce this, have passed repo steps regarding the private repo offline.
Still struggling to repro, I did notice sometimes it's off by 1 or 2 cells in either direction like this though: <img width="852" alt="Screenshot 2022-12-22 at 5 08 03 pm" src="https://user-"
This happens because of line caching, hovering a wrapped line and then resizing it a little such that the line is still there, the line range will be off: <img width="866" alt="Screenshot 2022-12-22 at 5 12 44 pm" src="https://user-"
That one repro's upstream: <img width="793" alt="Screenshot 2022-12-27 at 6 24 10 am" src="https://user-"Since I can't repro your actual issue I'll fix this and see if that's the underlying issue.
Can still repro this building OSS. Note you do not need to resize the terminal for this to occur if it's already the correct size when you run the task.
Update cannot repro when debugging. So odd
Update again, I can repro this again in insiders. Not sure why debugging is different.
Still can't reproduce so closing as unactionable until there's a solid repro. Insiders: <img width="632" alt="Screenshot 2023-05-08 at 6 43 07 am" src="https://user-"OSS: <img width="637" alt="Screenshot 2023-05-08 at 6 44 55 am" src="https://user-"OSS debugging: <img width="633" alt="Screenshot 2023-05-08 at 6 46 16 am" src="https://user-"cat this file:

Related discussion:
text: "vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "8.0.0", <del> "xterm": "5.2.0-beta.2", "xterm-addon-canvas": "0.4.0-beta.1", "xterm-addon-search": "0.11.0-beta.7", </del> <ins> "xterm": "5.2.0-beta.10", "xterm-addon-canvas": "0.4.0-beta.6", "xterm-addon-search": "0.11.0", </ins> "xterm-addon-serialize": "0.9.0", <del> "xterm-addon-unicode11": "0.5.0-beta.5", "xterm-addon-webgl": "0.15.0-beta.1", "xterm-headless": "5.2.0-beta.2", </del> <ins> "xterm-addon-unicode11": "0.5.0", "xterm-addon-webgl": "0.15.0-beta.4", "xterm-headless": "5.2.0-beta.10", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },
Code change:
! Only seems to appear if I resize the terminal such that a is on its own line.
Cannot repro: !
I can still reproduce this? For example cat this file to your terminal Then drag until a quote is the only thing on one of the lines. This causes the link detection to detect everything below that quote.
Couldn't repro on Windows but I do see some offset problem after the resizes: ! Probably an issue with reflow (mac/Linux)
In tried on my mac and I still can't reproduce: !
Still able to reproduce this, have passed repo steps regarding the private repo offline.
Still struggling to repro, I did notice sometimes it's off by 1 or 2 cells in either direction like this though: <img width="852" alt="Screenshot 2022-12-22 at 5 08 03 pm" src="https://user-"
This happens because of line caching, hovering a wrapped line and then resizing it a little such that the line is still there, the line range will be off: <img width="866" alt="Screenshot 2022-12-22 at 5 12 44 pm" src="https://user-"
That one repro's upstream: <img width="793" alt="Screenshot 2022-12-27 at 6 24 10 am" src="https://user-"Since I can't repro your actual issue I'll fix this and see if that's the underlying issue.
Can still repro this building OSS. Note you do not need to resize the terminal for this to occur if it's already the correct size when you run the task.
Update cannot repro when debugging. So odd
Update again, I can repro this again in insiders. Not sure why debugging is different.
Still can't reproduce so closing as unactionable until there's a solid repro. Insiders: <img width="632" alt="Screenshot 2023-05-08 at 6 43 07 am" src="https://user-"OSS: <img width="637" alt="Screenshot 2023-05-08 at 6 44 55 am" src="https://user-"OSS debugging: <img width="633" alt="Screenshot 2023-05-08 at 6 46 16 am" src="https://user-"cat this file:

Related discussion:
text: "tas-client-umd": "0.1.6", "vscode-oniguruma": "1.7.0", "vscode-textmate": "8.0.0", <del> "xterm": "5.2.0-beta.2", "xterm-addon-canvas": "0.4.0-beta.1", "xterm-addon-search": "0.11.0-beta.7", "xterm-addon-unicode11": "0.5.0-beta.5", "xterm-addon-webgl": "0.15.0-beta.1" </del> <ins> "xterm": "5.2.0-beta.10", "xterm-addon-canvas": "0.4.0-beta.6", "xterm-addon-search": "0.11.0", "xterm-addon-unicode11": "0.5.0", "xterm-addon-webgl": "0.15.0-beta.4" </ins> } }
Code change:
In the following dialog that appears: <img width="696" alt="image" src="https://user-"in and opening a protocol url, the 'Install VS Code Insiders' button should route to a new link for installing insiders specifically rather than just Install VS Code Insiders should not dismiss the dialog, so that the user can return and try again cc
likely a separate issue: Was not sure how this modal was arrived at, so I clicked the remote indicator and I only saw an option to download VS Code - not Insider's as I'd expect. !
I then did the flow and saw the dialogue. Clicking on the button took me to the Insider's download correctly. !

Related discussion:
text: invokeProtocolHandler(); <del> // We cannot know whether the protocol handler succeeded. // Display guidance in case it did not, e.g. the app is not installed locally. if (matchesScheme(href, this.productService.urlProtocol)) { </del> <ins> const showProtocolUrlOpenedDialog = async () => { </ins> const showResult = await this.dialogService.show( Severity.Info, localize('openExternalDialogTitle', "All done. You can close this tab now."),
Code change:
In the following dialog that appears: <img width="696" alt="image" src="https://user-"in and opening a protocol url, the 'Install VS Code Insiders' button should route to a new link for installing insiders specifically rather than just Install VS Code Insiders should not dismiss the dialog, so that the user can return and try again cc
likely a separate issue: Was not sure how this modal was arrived at, so I clicked the remote indicator and I only saw an option to download VS Code - not Insider's as I'd expect. !
I then did the flow and saw the dialogue. Clicking on the button took me to the Insider's download correctly. !

Related discussion:
text: if (showResult.choice === 0) { invokeProtocolHandler(); } else if (showResult.choice === 1) { <del> await this.openerService.open(URI.parse(`http://aka.ms/vscode-install`)); </del> <ins> // Route the user to the appropriate install link await this.openerService.open(URI.parse( this.productService.quality === 'stable' ? `http://aka.ms/vscode-install` : `http://aka.ms/vscode-install-insiders` )); // Re-show the dialog so that the user can come back after installing and try again showProtocolUrlOpenedDialog(); </ins> } <ins> }; // We cannot know whether the protocol handler succeeded. // Display guidance in case it did not, e.g. the app is not installed locally. if (matchesScheme(href, this.productService.urlProtocol)) { await showProtocolUrlOpenedDialog(); </ins> } }