jiebi/CodeConvo huggingface dataset:
Code change:
In , the comparison functions , , , and have misleading descriptions. For example, says "Check if is before this position." I think it would be more clear to say something like "Check if this position is before ", as that is when is returned. Likewise for the other three.

Related discussion:
text: isAfter(other: Position): boolean; /** <del> * Check if `other` is after or equal to this position. </del> <ins> * Check if this position is after or equal to `other`. </ins> * * @param other A position. * @return `true` if position is on a greater line
Code change:
In , the comparison functions , , , and have misleading descriptions. For example, says "Check if is before this position." I think it would be more clear to say something like "Check if this position is before ", as that is when is returned. Likewise for the other three.

Related discussion:
text: isAfterOrEqual(other: Position): boolean; /** <del> * Check if `other` equals this position. </del> <ins> * Check if this position is equal to `other`. </ins> * * @param other A position. * @return `true` if the line and character of the given position are equal to
Code change:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

Related discussion:
text: import { toDisposable, DisposableStore, dispose } from 'vs/base/common/lifecycle'; import { StableEditorScrollState } from 'vs/editor/browser/core/editorState'; import { ICodeEditor, MouseTargetType, IViewZoneChangeAccessor, IActiveCodeEditor } from 'vs/editor/browser/editorBrowser'; <del> import { registerEditorContribution } from 'vs/editor/browser/editorExtensions'; </del> <ins> import { registerEditorContribution, EditorCommand, ServicesAccessor } from 'vs/editor/browser/editorExtensions'; </ins> import { IEditorContribution } from 'vs/editor/common/editorCommon'; import { IModelDecorationsChangeAccessor } from 'vs/editor/common/model'; import { CodeLensProviderRegistry, CodeLens } from 'vs/editor/common/modes';
Code change:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

Related discussion:
text: import { EditorOption } from 'vs/editor/common/config/editorOptions'; import * as dom from 'vs/base/browser/dom'; import { hash } from 'vs/base/common/hash'; <ins> import { IQuickInputService, IQuickPickItem, IQuickPickSeparator } from 'vs/platform/quickinput/common/quickInput'; </ins> export class CodeLensContribution implements IEditorContribution {
Code change:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

Related discussion:
text: } }); } <ins> public getLenses(): CodeLensWidget[] { return this._lenses; } } export class ShowLensesInCurrentLineCommand extends EditorCommand { public runEditorCommand(accessor: ServicesAccessor, editor: ICodeEditor, args: any): void | Promise<void> { const quickInputService = accessor.get(IQuickInputService); const commandService = accessor.get(ICommandService); const notificationService = accessor.get(INotificationService); const lineNumber = editor.getSelection()?.positionLineNumber; const codelensController = editor.getContribution(CodeLensContribution.ID) as CodeLensContribution; const activeLensesWidgets = codelensController.getLenses().filter(lens => lens.getLineNumber() === lineNumber); const commandArguments: Map<string, any[] | undefined> = new Map(); const items: (IQuickPickItem | IQuickPickSeparator)[] = []; activeLensesWidgets.forEach(widget => { widget.getItems().forEach(codelens => { const command = codelens.symbol.command; if (!command) { return; } items.push({ id: command.id, label: command.title }); commandArguments.set(command.id, command.arguments); }); }); // We dont want an empty picker if (!items.length) { return; } quickInputService.pick(items, { canPickMany: false }).then(item => { const id = item.id!; commandService.executeCommand(id, ...(commandArguments.get(id) || [])).catch(err => notificationService.error(err)); }); } </ins> } registerEditorContribution(CodeLensContribution.ID, CodeLensContribution); <ins> const showLensesInCurrentLineCommand = new ShowLensesInCurrentLineCommand({ id: 'codelens.showLensesInCurrentLine', precondition: undefined }); showLensesInCurrentLineCommand.register(); </ins>
Code change:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

Related discussion:
text: } } } <ins> getItems(): CodeLensItem[] { return this._data; } </ins> } registerThemingParticipant((theme, collector) => {
Code change:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

Related discussion:
text: import { CancellationToken } from 'vs/base/common/cancellation'; import { IQuickPickItem, IPickOptions, IInputOptions, IQuickNavigateConfiguration, IQuickPick, IQuickInputButton, IInputBox, QuickPickInput } from 'vs/base/parts/quickinput/common/quickInput'; <del> export { IQuickPickItem, IPickOptions, IInputOptions, IQuickNavigateConfiguration, IQuickPick, IQuickInput, IQuickInputButton, IInputBox, IQuickPickItemButtonEvent, QuickPickInput, IQuickPickSeparator, IKeyMods } from 'vs/base/parts/quickinput/common/quickInput'; </del> <ins> export * from 'vs/base/parts/quickinput/common/quickInput'; </ins> export const IQuickInputService = createDecorator<IQuickInputService>('quickInputService');
Code change:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

Related discussion:
text: import { IPartService, Position } from 'vs/workbench/services/part/common/partService'; const SPLIT_PANE_MIN_SIZE = 120; <ins> const TERMINAL_MIN_USEFUL_SIZE = 250; </ins> class SplitPaneContainer { private _height: number;
Code change:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

Related discussion:
text: configHelper: ITerminalConfigHelper, shellLaunchConfig: IShellLaunchConfig ): ITerminalInstance { <ins> const newTerminalSize = ((this._panelPosition === Position.BOTTOM ? this._container.clientWidth : this._container.clientHeight) / (this._terminalInstances.length + 1)); if (newTerminalSize < TERMINAL_MIN_USEFUL_SIZE) { return undefined; } </ins> const instance = this._terminalService.createInstance( terminalFocusContextKey, configHelper,
Code change:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

Related discussion:
text: } protected abstract _showTerminalCloseConfirmation(): TPromise<boolean>; <ins> protected abstract _showNotEnoughSpaceToast(): void; </ins> public abstract createTerminal(shell?: IShellLaunchConfig, wasNewTerminalAction?: boolean): ITerminalInstance; public abstract createTerminalRenderer(name: string): ITerminalInstance; public abstract createInstance(terminalFocusContextKey: IContextKey<boolean>, configHelper: ITerminalConfigHelper, container: HTMLElement, shellLaunchConfig: IShellLaunchConfig, doCreateProcess: boolean): ITerminalInstance;
Code change:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

Related discussion:
text: } const instance = tab.split(this._terminalFocusContextKey, this.configHelper, shellLaunchConfig); <del> this._initInstanceListeners(instance); this._onInstancesChanged.fire(); </del> <ins> if (instance) { this._initInstanceListeners(instance); this._onInstancesChanged.fire(); </ins> <del> this._terminalTabs.forEach((t, i) => t.setVisible(i === this._activeTabIndex)); </del> <ins> this._terminalTabs.forEach((t, i) => t.setVisible(i === this._activeTabIndex)); } else { this._showNotEnoughSpaceToast(); } </ins> } protected _initInstanceListeners(instance: ITerminalInstance): void {
Code change:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

Related discussion:
text: this._terminalTabs = []; this._configHelper = this._instantiationService.createInstance(TerminalConfigHelper); ipc.on('vscode:openFiles', (_event: any, request: IOpenFileRequest) => { // if the request to open files is coming in from the integrated terminal (identified though // the termProgram variable) and we are instructed to wait for editors close, wait for the
Code change:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

Related discussion:
text: }).then(res => !res.confirmed); } <ins> protected _showNotEnoughSpaceToast(): void { this._notificationService.warn(nls.localize('terminal.minWidth', "Not enough space to split terminal.")); } </ins> public setContainers(panelContainer: HTMLElement, terminalContainer: HTMLElement): void { this._configHelper.panelContainer = panelContainer; this._terminalContainer = terminalContainer;
Code change:
Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!

Related discussion:
text: import { ModelDecorationMinimapOptions } from 'vs/editor/common/model/textModel'; import { Selection } from 'vs/editor/common/core/selection'; import { Color } from 'vs/base/common/color'; <ins> import { GestureEvent, EventType, Gesture } from 'vs/base/browser/touch'; </ins> function getMinimapLineHeight(renderMinimap: RenderMinimap): number { if (renderMinimap === RenderMinimap.Large) {
Code change:
Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!

Related discussion:
text: return Math.round(desiredSliderPosition / this._computedSliderRatio); } <ins> public getDesiredScrollTopFromTouchLocation(pageY: number): number { return Math.round((pageY - this.sliderHeight / 2) / this._computedSliderRatio); } </ins> public static create( options: MinimapOptions, viewportStartLineNumber: number,
Code change:
Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!

Related discussion:
text: private readonly _mouseDownListener: IDisposable; private readonly _sliderMouseMoveMonitor: GlobalMouseMoveMonitor<IStandardMouseMoveEventData>; private readonly _sliderMouseDownListener: IDisposable; <ins> private readonly _sliderTouchStartListener: IDisposable; private readonly _sliderTouchMoveListener: IDisposable; private readonly _sliderTouchEndListener: IDisposable; </ins> private _options: MinimapOptions; private _lastRenderData: RenderData | null; private _selections: Selection[] = []; private _selectionColor: Color | undefined; private _renderDecorations: boolean = false; <ins> private _gestureInProgress: boolean = false; </ins> private _buffers: MinimapBuffers | null; constructor(context: ViewContext) {
Code change:
Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!

Related discussion:
text: ); } }); <ins> Gesture.addTarget(this._domNode.domNode); this._sliderTouchStartListener = dom.addDisposableListener(this._domNode.domNode, EventType.Start, (e: GestureEvent) => { e.preventDefault(); e.stopPropagation(); if (this._lastRenderData) { this._slider.toggleClassName('active', true); this._gestureInProgress = true; this.scrollDueToTouchEvent(e); } }); this._sliderTouchMoveListener = dom.addStandardDisposableListener(this._domNode.domNode, EventType.Change, (e: GestureEvent) => { e.preventDefault(); e.stopPropagation(); if (this._lastRenderData && this._gestureInProgress) { this.scrollDueToTouchEvent(e); } }); this._sliderTouchEndListener = dom.addStandardDisposableListener(this._domNode.domNode, EventType.End, (e: GestureEvent) => { e.preventDefault(); e.stopPropagation(); this._gestureInProgress = false; this._slider.toggleClassName('active', false); }); } private scrollDueToTouchEvent(touch: GestureEvent) { const startY = this._domNode.domNode.getBoundingClientRect().top; const scrollTop = this._lastRenderData!.renderedLayout.getDesiredScrollTopFromTouchLocation(touch.pageY - startY); this._context.viewLayout.setScrollPositionNow({ scrollTop: scrollTop }); </ins> } public dispose(): void { this._mouseDownListener.dispose(); this._sliderMouseMoveMonitor.dispose(); this._sliderMouseDownListener.dispose(); <ins> this._sliderTouchStartListener.dispose(); this._sliderTouchMoveListener.dispose(); this._sliderTouchEndListener.dispose(); </ins> super.dispose(); }