jiebi/CodeConvo huggingface dataset:
Code change:
With I went over most editor contributions (50+) and adopted idle value instantiation where I could reason that they would still work correctly. But some editor contributions interact in more complex ways, sometimes with each other, and I wasn't sure. Hence, this issue. I would like to ask that all calls explicitly use . If a contribution uses eager, a reason should be written as a comment next to it. There are multiple options available: Some things to keep in mind when changing an editor contribution to something else than : the contribution will not be created necessarily before a text model is attached. Normally, a contribution is created so early, at a point when the editor has no models. So it is safe for a contribution to simply use to check if the contribution needs to do anything. When being instantiated later, it is possible that the contribution will be created at a time when the editor already has a model, so the contribution should be prepared to deal with that in the ctor. if a contribution needs to be activated via editor events (pasting, typing, mouse events), then most likely you can use . if a contribution is mostly driven by actions or commands, then the contribution will be instantiated when the first action that needs it is executed, so it is safe to use . if a contribution is only driven by actions or commands, it is safe to use . Anyways, here's the remaining list of contributions for which I wasn't sure what would be correct:
Replacing me with who took over quick pick.

Related discussion:
text: return result; } <del> export class LazyCallStackEditorContribution extends Disposable { constructor(editor: ICodeEditor, @IInstantiationService instantiationService: IInstantiationService) { super(); const listener = editor.onDidChangeModel(() => { if (editor.hasModel()) { listener.dispose(); this._register(instantiationService.createInstance(CallStackEditorContribution, editor)); } }); } } class CallStackEditorContribution extends Disposable implements IEditorContribution { </del> <ins> export class CallStackEditorContribution extends Disposable implements IEditorContribution { </ins> private decorations = this.editor.createDecorationsCollection(); constructor(
Code change:
With I went over most editor contributions (50+) and adopted idle value instantiation where I could reason that they would still work correctly. But some editor contributions interact in more complex ways, sometimes with each other, and I wasn't sure. Hence, this issue. I would like to ask that all calls explicitly use . If a contribution uses eager, a reason should be written as a comment next to it. There are multiple options available: Some things to keep in mind when changing an editor contribution to something else than : the contribution will not be created necessarily before a text model is attached. Normally, a contribution is created so early, at a point when the editor has no models. So it is safe for a contribution to simply use to check if the contribution needs to do anything. When being instantiated later, it is possible that the contribution will be created at a time when the editor already has a model, so the contribution should be prepared to deal with that in the ctor. if a contribution needs to be activated via editor events (pasting, typing, mouse events), then most likely you can use . if a contribution is mostly driven by actions or commands, then the contribution will be instantiated when the first action that needs it is executed, so it is safe to use . if a contribution is only driven by actions or commands, it is safe to use . Anyways, here's the remaining list of contributions for which I wasn't sure what would be correct:
Replacing me with who took over quick pick.

Related discussion:
text: helpEntries: [{ description: nls.localize('tasksQuickAccessHelp', "Show All Debug Consoles"), commandId: SELECT_DEBUG_CONSOLE_ID }] }); <del> registerEditorContribution('editor.contrib.callStack', LazyCallStackEditorContribution, EditorContributionInstantiation.Eager); registerEditorContribution(BREAKPOINT_EDITOR_CONTRIBUTION_ID, LazyBreakpointEditorContribution, EditorContributionInstantiation.Eager); registerEditorContribution(EDITOR_CONTRIBUTION_ID, LazyDebugEditorContribution, EditorContributionInstantiation.Eager); </del> <ins> registerEditorContribution('editor.contrib.callStack', CallStackEditorContribution, EditorContributionInstantiation.AfterFirstRender); registerEditorContribution(BREAKPOINT_EDITOR_CONTRIBUTION_ID, BreakpointEditorContribution, EditorContributionInstantiation.AfterFirstRender); registerEditorContribution(EDITOR_CONTRIBUTION_ID, DebugEditorContribution, EditorContributionInstantiation.BeforeFirstInteraction); </ins> const registerDebugCommandPaletteItem = (id: string, title: ICommandActionTitle, when?: ContextKeyExpression, precondition?: ContextKeyExpression) => { MenuRegistry.appendMenuItem(MenuId.CommandPalette, {
Code change:
With I went over most editor contributions (50+) and adopted idle value instantiation where I could reason that they would still work correctly. But some editor contributions interact in more complex ways, sometimes with each other, and I wasn't sure. Hence, this issue. I would like to ask that all calls explicitly use . If a contribution uses eager, a reason should be written as a comment next to it. There are multiple options available: Some things to keep in mind when changing an editor contribution to something else than : the contribution will not be created necessarily before a text model is attached. Normally, a contribution is created so early, at a point when the editor has no models. So it is safe for a contribution to simply use to check if the contribution needs to do anything. When being instantiated later, it is possible that the contribution will be created at a time when the editor already has a model, so the contribution should be prepared to deal with that in the ctor. if a contribution needs to be activated via editor events (pasting, typing, mouse events), then most likely you can use . if a contribution is mostly driven by actions or commands, then the contribution will be instantiated when the first action that needs it is executed, so it is safe to use . if a contribution is only driven by actions or commands, it is safe to use . Anyways, here's the remaining list of contributions for which I wasn't sure what would be correct:
Replacing me with who took over quick pick.

Related discussion:
text: return result; } <del> export class LazyDebugEditorContribution extends Disposable implements IDebugEditorContribution { private _contrib: IDebugEditorContribution | undefined; constructor(editor: ICodeEditor, @IInstantiationService instantiationService: IInstantiationService) { super(); const listener = editor.onDidChangeModel(() => { if (editor.hasModel()) { listener.dispose(); this._contrib = this._register(instantiationService.createInstance(DebugEditorContribution, editor)); } }); } showHover(position: Position, focus: boolean): Promise<void> { return this._contrib ? this._contrib.showHover(position, focus) : Promise.resolve(); } addLaunchConfiguration(): Promise<any> { return this._contrib ? this._contrib.addLaunchConfiguration() : Promise.resolve(); } closeExceptionWidget(): void { this._contrib?.closeExceptionWidget(); } } </del> export class DebugEditorContribution implements IDebugEditorContribution { private toDispose: IDisposable[];
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 <!-- 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: Version: 1.73.1 (system setup) Commit: Date: 2022-11-09T04:27:29.066Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No OS Version: Windows 11 Steps to Reproduce: a volume in Window that contains a git repo directly in the root of the volume (in my case it is an NFS share hosted on my NAS, but this also happens if it is simply an empty disk drive too) the root directory in VS Code and go to the Source Control window that it shows the diffs, but all the folders contain the volume letter at the beginning of the folders/files and the diff previews don't work !
<!-- 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!
I do see this message even though I created the volumes: !
I think you can capture that in a new issue, but you should be able to open files from the diff if you trust the repo
Yes. You can open files. But since this is I removed my
author-verification-requested's can still be verified by team members (and often are if we don't get responses in time for endgame). It's just a helpful label so the bot can post a message and start the process asking the author to do the verification.
Looks good! It works for me! Thanks so much for fixing this! :) /verified

Related discussion:
text: ), ); if (networkPath !== undefined) { <ins> // If the repository is at the root of the mapped drive then we // have to append `` (ex: D:) otherwise the path is not valid. const isDriveRoot = pathEquals(repoUri.fsPath, networkPath); </ins> return path.normalize( repoUri.fsPath.replace( networkPath, <del> `${letter.toLowerCase()}:${networkPath.endsWith('') ? '' : ''}` </del> <ins> `${letter.toLowerCase()}:${isDriveRoot || networkPath.endsWith('') ? '' : ''}` </ins> ), ); }
Code change:
I just now noticed how the progress bar was a the very end of the quick pick but not below input box, I think it should be below input box because the progress is for what I typed. Steps: have some history entries in Cmd+P picker be on a slow OS (Windows) start to type and notice progress bar is below the history entries //cc
Seems like this might have been a regression at some point. for relocating it back near the input.
I like where it is now. To me it says "the results are still populating".
The reason I do not like it: the progress bar is at a non-deterministic location depending on the number of items the progress bar indicator is away from the location that triggers it (the input box)

Related discussion:
text: .quick-input-titlebar { display: flex; align-items: center; <ins> border-top-left-radius: 5px; /* match border radius of quick input widget */ border-top-right-radius: 5px; </ins> } .quick-input-left-action-bar {
Code change:
I just now noticed how the progress bar was a the very end of the quick pick but not below input box, I think it should be below input box because the progress is for what I typed. Steps: have some history entries in Cmd+P picker be on a slow OS (Windows) start to type and notice progress bar is below the history entries //cc
Seems like this might have been a regression at some point. for relocating it back near the input.
I like where it is now. To me it says "the results are still populating".
The reason I do not like it: the progress bar is at a non-deterministic location depending on the number of items the progress bar indicator is away from the location that triggers it (the input box)

Related discussion:
text: .quick-input-header { display: flex; <del> padding: 8px 6px 0px 6px; margin-bottom: -2px; </del> <ins> padding: 8px 6px 6px 6px; </ins> } .quick-input-widget.hidden-input .quick-input-header {
Code change:
I just now noticed how the progress bar was a the very end of the quick pick but not below input box, I think it should be below input box because the progress is for what I typed. Steps: have some history entries in Cmd+P picker be on a slow OS (Windows) start to type and notice progress bar is below the history entries //cc
Seems like this might have been a regression at some point. for relocating it back near the input.
I like where it is now. To me it says "the results are still populating".
The reason I do not like it: the progress bar is at a non-deterministic location depending on the number of items the progress bar indicator is away from the location that triggers it (the input box)

Related discussion:
text: .quick-input-list { line-height: 22px; <del> margin-top: 6px; padding: 1px; </del> } .quick-input-widget.hidden-input .quick-input-list {
Code change:
I just now noticed how the progress bar was a the very end of the quick pick but not below input box, I think it should be below input box because the progress is for what I typed. Steps: have some history entries in Cmd+P picker be on a slow OS (Windows) start to type and notice progress bar is below the history entries //cc
Seems like this might have been a regression at some point. for relocating it back near the input.
I like where it is now. To me it says "the results are still populating".
The reason I do not like it: the progress bar is at a non-deterministic location depending on the number of items the progress bar indicator is away from the location that triggers it (the input box)

Related discussion:
text: const message = dom.append(extraContainer, $(`#${this.idPrefix}message.quick-input-message`)); <ins> const progressBar = new ProgressBar(container, this.styles.progressBar); progressBar.getContainer().classList.add('quick-input-progress'); </ins> const list = this._register(new QuickInputList(container, this.idPrefix + 'list', this.options)); this._register(list.onChangedAllVisibleChecked(checked => { checkAll.checked = checked;
Code change:
I just now noticed how the progress bar was a the very end of the quick pick but not below input box, I think it should be below input box because the progress is for what I typed. Steps: have some history entries in Cmd+P picker be on a slow OS (Windows) start to type and notice progress bar is below the history entries //cc
Seems like this might have been a regression at some point. for relocating it back near the input.
I like where it is now. To me it says "the results are still populating".
The reason I do not like it: the progress bar is at a non-deterministic location depending on the number of items the progress bar indicator is away from the location that triggers it (the input box)

Related discussion:
text: } })); <del> const progressBar = new ProgressBar(container, this.styles.progressBar); progressBar.getContainer().classList.add('quick-input-progress'); </del> const focusTracker = dom.trackFocus(container); this._register(focusTracker); this._register(dom.addDisposableListener(container, dom.EventType.FOCUS, e => {
Code change:
Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.

Related discussion:
text: class GitHubGistProfileContentHandler implements vscode.ProfileContentHandler { readonly name = vscode.l10n.t('GitHub'); <ins> readonly description = vscode.l10n.t('gist'); </ins> private _octokit: Promise<Octokit> | undefined; private getOctokit(): Promise<Octokit> {
Code change:
Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.

Related discussion:
text: this.proxy = context.getProxy(ExtHostContext.ExtHostProfileContentHandlers); } <del> async $registerProfileContentHandler(id: string, name: string, extensionId: string): Promise<void> { </del> <ins> async $registerProfileContentHandler(id: string, name: string, description: string | undefined, extensionId: string): Promise<void> { </ins> this.registeredHandlers.set(id, this.userDataProfileImportExportService.registerProfileContentHandler(id, { name, <ins> description, </ins> extensionId, saveProfile: async (name: string, content: string, token: CancellationToken) => { const result = await this.proxy.$saveProfile(id, name, content, token);
Code change:
Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.

Related discussion:
text: } export interface MainThreadProfileContentHandlersShape { <del> $registerProfileContentHandler(id: string, name: string, extensionId: string): Promise<void>; </del> <ins> $registerProfileContentHandler(id: string, name: string, description: string | undefined, extensionId: string): Promise<void>; </ins> $unregisterProfileContentHandler(id: string): Promise<void>; }
Code change:
Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.

Related discussion:
text: } this.handlers.set(id, handler); <del> this.proxy.$registerProfileContentHandler(id, handler.name, extension.identifier.value); </del> <ins> this.proxy.$registerProfileContentHandler(id, handler.name, handler.description, extension.identifier.value); </ins> return toDisposable(() => { this.handlers.delete(id);
Code change:
Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.

Related discussion:
text: if (this.profileContentHandlers.size === 1) { return this.profileContentHandlers.values().next().value; } <del> const linkHandlers: { id: string; label: string }[] = []; const fileHandlers: { id: string; label: string }[] = []; for (const [id, profileContentHandler] of this.profileContentHandlers) { if (profileContentHandler.extensionId) { linkHandlers.push({ id, label: profileContentHandler.name }); } else { fileHandlers.push({ id, label: profileContentHandler.name }); } } </del> const options: QuickPickItem[] = []; <del> if (linkHandlers.length) { options.push({ label: localize('link', "link"), type: 'separator' }); options.push(...linkHandlers); } if (fileHandlers.length) { options.push({ label: localize('file', "file"), type: 'separator' }); options.push(...fileHandlers); </del> <ins> for (const [id, profileContentHandler] of this.profileContentHandlers) { options.push({ id, label: profileContentHandler.name, description: profileContentHandler.description }); </ins> } <del> const result = await this.quickInputService.pick(options, </del> <ins> const result = await this.quickInputService.pick(options.reverse(), </ins> { title: localize('select profile content handler', "Export '{0}' profile as...", name), hideInput: true