jiebi/CodeConvo huggingface dataset:
Code change:
Currently when there is one suggested kernel and that's the one users are using in current document, its presentation in kernel picker is weird <img width="601" alt="image" src="https://user-"This can be simplified as a single "Selected" group at the very top <img width="601" alt="image" src="https://user-"

Related discussion:
text: return quickPickItems; } <ins> private _toQuickPick(kernel: INotebookKernel, selected: INotebookKernel | undefined) { const res = <KernelPick>{ kernel, picked: kernel.id === selected?.id, label: kernel.label, description: kernel.description, detail: kernel.detail }; if (kernel.id === selected?.id) { if (!res.description) { res.description = localize('current1', "Currently Selected"); } else { res.description = localize('current2', "{0} - Currently Selected", res.description); } } return res; } private _fillInSuggestions(quickPickItems: QuickPickInput<KernelQuickPickItem>[], suggestions: INotebookKernel[], selected: INotebookKernel | undefined) { if (!suggestions.length) { return; } if (suggestions.length === 1 && suggestions[0].id === selected?.id) { quickPickItems.push({ type: 'separator', label: localize('selectedKernels', "Selected") }); // The title is already set to "Selected" so we don't need to set it again in description, thus passing in `undefined`. quickPickItems.push(this._toQuickPick(suggestions[0], undefined)); return; } quickPickItems.push({ type: 'separator', label: localize('suggestedKernels', "Suggested") }); quickPickItems.push(...suggestions.map(kernel => this._toQuickPick(kernel, selected))); } </ins> private async _showInstallKernelExtensionRecommendation( notebookTextModel: NotebookTextModel, quickPick: IQuickPick<KernelQuickPickItem>,
Code change:
Currently when there is one suggested kernel and that's the one users are using in current document, its presentation in kernel picker is weird <img width="601" alt="image" src="https://user-"This can be simplified as a single "Selected" group at the very top <img width="601" alt="image" src="https://user-"

Related discussion:
text: } } private async _getKernelRecommendationsQuickPickItems( notebookTextModel: NotebookTextModel, extensionWorkbenchService: IExtensionsWorkbenchService,
Code change:
Currently when there is one suggested kernel and that's the one users are using in current document, its presentation in kernel picker is weird <img width="601" alt="image" src="https://user-"This can be simplified as a single "Selected" group at the very top <img width="601" alt="image" src="https://user-"

Related discussion:
text: const pascalCased = viewType.split(/[^a-z0-9]/ig).map(uppercaseFirstLetter).join(''); view?.search(`@tag:notebookKernel${pascalCased}`); } <ins> } registerAction2(class extends Action2 { constructor() { super({ id: SELECT_KERNEL_ID, category: NOTEBOOK_ACTIONS_CATEGORY, title: { value: localize('notebookActions.selectKernel', "Select Notebook Kernel"), original: 'Select Notebook Kernel' }, icon: selectKernelIcon, f1: true, menu: [{ id: MenuId.EditorTitle, when: ContextKeyExpr.and( NOTEBOOK_IS_ACTIVE_EDITOR, ContextKeyExpr.notEquals('config.notebook.globalToolbar', true) ), group: 'navigation', order: -10 }, { id: MenuId.NotebookToolbar, when: ContextKeyExpr.equals('config.notebook.globalToolbar', true), group: 'status', order: -10 }, { id: MenuId.InteractiveToolbar, when: NOTEBOOK_KERNEL_COUNT.notEqualsTo(0), group: 'status', order: -10 }], description: { description: localize('notebookActions.selectKernel.args', "Notebook Kernel Args"), args: [ { name: 'kernelInfo', description: 'The kernel info', schema: { 'type': 'object', 'required': ['id', 'extension'], 'properties': { 'id': { 'type': 'string' }, 'extension': { 'type': 'string' }, 'notebookEditorId': { 'type': 'string' } } } } ] }, }); } async run(accessor: ServicesAccessor, context?: KernelQuickPickContext): Promise<boolean> { const notebookKernelService = accessor.get(INotebookKernelService); const editorService = accessor.get(IEditorService); const productService = accessor.get(IProductService); const quickInputService = accessor.get(IQuickInputService); const labelService = accessor.get(ILabelService); const logService = accessor.get(ILogService); const paneCompositeService = accessor.get(IPaneCompositePartService); const extensionWorkbenchService = accessor.get(IExtensionsWorkbenchService); const extensionHostService = accessor.get(IExtensionService); const strategy = new KernelPickerFlatStrategy( notebookKernelService, editorService, productService, quickInputService, labelService, logService, paneCompositeService, extensionWorkbenchService, extensionHostService ); return await strategy.showQuickPick(context); } </ins> }); export class NotebooKernelActionViewItem extends ActionViewItem {
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I love that vscode had pylance for python toolchain, this is frustrating when you have a language support but an editor default that does not show syntax error. Please reconsider these samples of scenarios, Python uses indentation to delimit code blocks, which is 2 or 4 leading whitespaces. YAML uses indentation to delimit nesting level, which is also 2 or 4 leading whitespaces. Python is afaik the majority in ML community, see e.g. has 98.0% of python code, both pytorch and tensorflow has a python frontend. YAML has grown popularity comparable to json as configuration tool, e.g. a majority of linter that supports also supports . Ignoring whitespace diff actually leads to syntax error and thus broken code, it is not just a visual difference. <!-- Describe the feature you'd like. --Make this default:
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!

Related discussion:
text: "scopeName": "source.clojure", "path": "./syntaxes/clojure.tmLanguage.json" } <del> ] </del> <ins> ], "configurationDefaults": { "[clojure]": { "diffEditor.ignoreTrimWhitespace": false } } </ins> }, "repository": { "type": "git",
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I love that vscode had pylance for python toolchain, this is frustrating when you have a language support but an editor default that does not show syntax error. Please reconsider these samples of scenarios, Python uses indentation to delimit code blocks, which is 2 or 4 leading whitespaces. YAML uses indentation to delimit nesting level, which is also 2 or 4 leading whitespaces. Python is afaik the majority in ML community, see e.g. has 98.0% of python code, both pytorch and tensorflow has a python frontend. YAML has grown popularity comparable to json as configuration tool, e.g. a majority of linter that supports also supports . Ignoring whitespace diff actually leads to syntax error and thus broken code, it is not just a visual difference. <!-- Describe the feature you'd like. --Make this default:
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!

Related discussion:
text: "language": "coffeescript", "path": "./snippets/coffeescript.code-snippets" } <del> ] </del> <ins> ], "configurationDefaults": { "[coffeescript]": { "diffEditor.ignoreTrimWhitespace": false } } </ins> }, "repository": { "type": "git",
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I love that vscode had pylance for python toolchain, this is frustrating when you have a language support but an editor default that does not show syntax error. Please reconsider these samples of scenarios, Python uses indentation to delimit code blocks, which is 2 or 4 leading whitespaces. YAML uses indentation to delimit nesting level, which is also 2 or 4 leading whitespaces. Python is afaik the majority in ML community, see e.g. has 98.0% of python code, both pytorch and tensorflow has a python frontend. YAML has grown popularity comparable to json as configuration tool, e.g. a majority of linter that supports also supports . Ignoring whitespace diff actually leads to syntax error and thus broken code, it is not just a visual difference. <!-- Describe the feature you'd like. --Make this default:
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!

Related discussion:
text: "language": "fsharp", "path": "./snippets/fsharp.code-snippets" } <del> ] </del> <ins> ], "configurationDefaults": { "[fsharp]": { "diffEditor.ignoreTrimWhitespace": false } } </ins> }, "repository": { "type": "git",
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I love that vscode had pylance for python toolchain, this is frustrating when you have a language support but an editor default that does not show syntax error. Please reconsider these samples of scenarios, Python uses indentation to delimit code blocks, which is 2 or 4 leading whitespaces. YAML uses indentation to delimit nesting level, which is also 2 or 4 leading whitespaces. Python is afaik the majority in ML community, see e.g. has 98.0% of python code, both pytorch and tensorflow has a python frontend. YAML has grown popularity comparable to json as configuration tool, e.g. a majority of linter that supports also supports . Ignoring whitespace diff actually leads to syntax error and thus broken code, it is not just a visual difference. <!-- Describe the feature you'd like. --Make this default:
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!

Related discussion:
text: "configurationDefaults": { "[markdown]": { "editor.unicodeHighlight.ambiguousCharacters": false, <del> "editor.unicodeHighlight.invisibleCharacters": false </del> <ins> "editor.unicodeHighlight.invisibleCharacters": false, "diffEditor.ignoreTrimWhitespace": false </ins> } } },
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I love that vscode had pylance for python toolchain, this is frustrating when you have a language support but an editor default that does not show syntax error. Please reconsider these samples of scenarios, Python uses indentation to delimit code blocks, which is 2 or 4 leading whitespaces. YAML uses indentation to delimit nesting level, which is also 2 or 4 leading whitespaces. Python is afaik the majority in ML community, see e.g. has 98.0% of python code, both pytorch and tensorflow has a python frontend. YAML has grown popularity comparable to json as configuration tool, e.g. a majority of linter that supports also supports . Ignoring whitespace diff actually leads to syntax error and thus broken code, it is not just a visual difference. <!-- Describe the feature you'd like. --Make this default:
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!

Related discussion:
text: "scopeName": "text.pug", "path": "./syntaxes/pug.tmLanguage.json" } <del> ] </del> <ins> ], "configurationDefaults": { "[jade]": { "diffEditor.ignoreTrimWhitespace": false } } </ins> }, "repository": { "type": "git",
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I love that vscode had pylance for python toolchain, this is frustrating when you have a language support but an editor default that does not show syntax error. Please reconsider these samples of scenarios, Python uses indentation to delimit code blocks, which is 2 or 4 leading whitespaces. YAML uses indentation to delimit nesting level, which is also 2 or 4 leading whitespaces. Python is afaik the majority in ML community, see e.g. has 98.0% of python code, both pytorch and tensorflow has a python frontend. YAML has grown popularity comparable to json as configuration tool, e.g. a majority of linter that supports also supports . Ignoring whitespace diff actually leads to syntax error and thus broken code, it is not just a visual difference. <!-- Describe the feature you'd like. --Make this default:
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!

Related discussion:
text: "scopeName": "source.regexp.python", "path": "./syntaxes/MagicRegExp.tmLanguage.json" } <del> ] </del> <ins> ], "configurationDefaults": { "[python]": { "diffEditor.ignoreTrimWhitespace": false } } </ins> }, "scripts": { "update-grammar": "node ../node_modules/vscode-grammar-updater/bin MagicStack/MagicPython grammars/MagicPython.tmLanguage ./syntaxes/MagicPython.tmLanguage.json grammars/MagicRegExp.tmLanguage ./syntaxes/MagicRegExp.tmLanguage.json"
Code change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I love that vscode had pylance for python toolchain, this is frustrating when you have a language support but an editor default that does not show syntax error. Please reconsider these samples of scenarios, Python uses indentation to delimit code blocks, which is 2 or 4 leading whitespaces. YAML uses indentation to delimit nesting level, which is also 2 or 4 leading whitespaces. Python is afaik the majority in ML community, see e.g. has 98.0% of python code, both pytorch and tensorflow has a python frontend. YAML has grown popularity comparable to json as configuration tool, e.g. a majority of linter that supports also supports . Ignoring whitespace diff actually leads to syntax error and thus broken code, it is not just a visual difference. <!-- Describe the feature you'd like. --Make this default:
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!

Related discussion:
text: "[yaml]": { "editor.insertSpaces": true, "editor.tabSize": 2, <del> "editor.autoIndent": "advanced" </del> <ins> "editor.autoIndent": "advanced", "diffEditor.ignoreTrimWhitespace": false </ins> }, "[dockercompose]": { "editor.insertSpaces": true,
Code change:
Steps to repro: a new instance of VS Code (no extension installed) an ipynb file running a cell out of extension installation suggestion Cell is still "running" and cannot stop execution (Expected: Cell execution is stopped or can be stopped by clicking )

Related discussion:
text: } } })); <ins> disposables.add(quickPick.onDidHide(() => { quickPick.dispose(); resolve(false); })); </ins> this._calculdateKernelSources(editor).then(quickPickItems => { quickPick.items = quickPickItems; if (quickPick.items.length > 0) {
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: import { memoize } from 'vs/base/common/decorators'; import { onUnexpectedError } from 'vs/base/common/errors'; import { MarkdownString } from 'vs/base/common/htmlContent'; <del> import { Disposable, dispose, disposeIfDisposable, IDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { dispose, disposeIfDisposable, IDisposable } from 'vs/base/common/lifecycle'; </ins> import * as env from 'vs/base/common/platform'; import severity from 'vs/base/common/severity'; import { noBreakWhitespace } from 'vs/base/common/strings';
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 LazyBreakpointEditorContribution extends Disposable implements IBreakpointEditorContribution { private _contrib: IBreakpointEditorContribution | undefined; constructor(editor: ICodeEditor, @IInstantiationService instantiationService: IInstantiationService) { super(); const listener = editor.onDidChangeModel(() => { if (editor.hasModel()) { listener.dispose(); this._contrib = this._register(instantiationService.createInstance(BreakpointEditorContribution, editor)); } }); } showBreakpointWidget(lineNumber: number, column: number | undefined, context?: BreakpointWidgetContext | undefined): void { this._contrib?.showBreakpointWidget(lineNumber, column, context); } closeBreakpointWidget(): void { this._contrib?.closeBreakpointWidget(); } getContextMenuActionsAtPosition(lineNumber: number, model: ITextModel): IAction[] { return this._contrib?.getContextMenuActionsAtPosition(lineNumber, model) ?? []; } } class BreakpointEditorContribution implements IBreakpointEditorContribution { </del> <ins> export class BreakpointEditorContribution implements IBreakpointEditorContribution { </ins> private breakpointHintDecoration: string | null = null; private breakpointWidget: BreakpointWidget | undefined;
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: import { IEditorContribution } from 'vs/editor/common/editorCommon'; import { IModelDecorationOptions, IModelDeltaDecoration, OverviewRulerLane, TrackedRangeStickiness } from 'vs/editor/common/model'; import { localize } from 'vs/nls'; <del> import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; </del> import { ILogService } from 'vs/platform/log/common/log'; import { registerColor } from 'vs/platform/theme/common/colorRegistry'; import { registerThemingParticipant, themeColorFromId, ThemeIcon } from 'vs/platform/theme/common/themeService';