jiebi/CodeConvo huggingface dataset:
Code change:
Ah, sorry for the breakage... I believe asking for both is the best option for now but I can also add a "migration" path into the implementation, e.g use when seeing Originally posted by in

Related discussion:
text: /** * A symbol tree input is the entry point for populating the references viewlet. <del> * Inputs must be anchored at a code location, they must have a title, and they </del> <ins> * Inputs must be anchored at a code location, they must have a title, and they </ins> * must resolve to a model. */ export interface SymbolTreeInput<T> {
Code change:
Ah, sorry for the breakage... I believe asking for both is the best option for now but I can also add a "migration" path into the implementation, e.g use when seeing Originally posted by in

Related discussion:
text: readonly location: vscode.Location; /** <del> * Resolve this input to a model that contains the actual data. When there are no result </del> <ins> * Resolve this input to a model that contains the actual data. When there are no result </ins> * than `undefined` or `null` should be returned. */ resolve(): vscode.ProviderResult<SymbolTreeModel<T>>; /** * This function is called when re-running from history. The symbols tree has tracked <del> * the original location of this input and that is now passed to this input. The </del> <ins> * the original location of this input and that is now passed to this input. The </ins> * implementation of this function should return a clone where the `location`-property * uses the provided `location` <del> * </del> <ins> * </ins> * @param location The location at which the new input should be anchored. * @returns A new input which location is anchored at the position. */
Code change:
Ah, sorry for the breakage... I believe asking for both is the best option for now but I can also add a "migration" path into the implementation, e.g use when seeing Originally posted by in

Related discussion:
text: navigation?: SymbolItemNavigation<T>; /** <del> * Optional support for editor highlights. WHen implemented, the editor will highlight </del> <ins> * Optional support for editor highlights. WHen implemented, the editor will highlight </ins> * symbol ranges in the source code. */ highlights?: SymbolItemEditorHighlights<T>;
Code change:
Ah, sorry for the breakage... I believe asking for both is the best option for now but I can also add a "migration" path into the implementation, e.g use when seeing Originally posted by in

Related discussion:
text: import { combinedDisposable } from 'vs/base/common/lifecycle'; import { checkProposedApiEnabled, ExtensionIdentifierSet, isProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; import { DebugConfigurationProviderTriggerKind } from 'vs/workbench/contrib/debug/common/debug'; <ins> import { equalsIgnoreCase } from 'vs/base/common/strings'; </ins> export interface IExtensionRegistries { mine: ExtensionDescriptionRegistry;
Code change:
Ah, sorry for the breakage... I believe asking for both is the best option for now but I can also add a "migration" path into the implementation, e.g use when seeing Originally posted by in

Related discussion:
text: const extensions: typeof vscode.extensions = { getExtension(extensionId: string, includeFromDifferentExtensionHosts?: boolean): vscode.Extension<any> | undefined { <ins> if (equalsIgnoreCase(extensionId, 'ms-vscode.references-view')) { extHostApiDeprecation.report(`The extension 'ms-vscode.references-view' has been renamed.`, extension, `Use 'vscode.references-view' instead.`); extensionId = 'vscode.references-view'; } </ins> if (!isProposedApiEnabled(extension, 'extensionsAny')) { includeFromDifferentExtensionHosts = false; }
Code change:
I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc

Related discussion:
text: ) ); export const unhandledConflictMinimapOverViewRulerColor = registerColor( 'mergeEditor.conflict-unhandled.minimapOverViewRuler', {
Code change:
I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc

Related discussion:
text: const range = modifiedBaseRange.getInputRange(this.inputNumber); if (range && !range.isEmpty) { const blockClassNames = ['merge-editor-block']; const isHandled = model.isHandled(modifiedBaseRange).read(reader); if (isHandled) { blockClassNames.push('handled'); } if (modifiedBaseRange === activeModifiedBaseRange) { <del> blockClassNames.push('active'); </del> <ins> blockClassNames.push('focused'); </ins> } <del> blockClassNames.push('input' + this.inputNumber); </del> <ins> const inputClassName = this.inputNumber === 1 ? 'input1' : 'input2'; blockClassNames.push(inputClassName); </ins> result.push({ range: range.toInclusiveRange()!, options: { isWholeLine: true, blockClassName: blockClassNames.join(' '), <del> description: 'Base Range Projection', </del> <ins> description: 'Merge Editor', </ins> minimap: { position: MinimapPosition.Gutter, color: { id: isHandled ? handledConflictMinimapOverViewRulerColor : unhandledConflictMinimapOverViewRulerColor },
Code change:
I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc

Related discussion:
text: const inputDiffs = modifiedBaseRange.getInputDiffs(this.inputNumber); for (const diff of inputDiffs) { <ins> const range = diff.outputRange.toInclusiveRange(); if (range) { result.push({ range, options: { className: `merge-editor-diff ${inputClassName}`, description: 'Merge Editor', isWholeLine: true, } }); } </ins> if (diff.rangeMappings) { for (const d of diff.rangeMappings) { result.push({ range: d.outputRange, options: { <del> className: `merge-editor-diff-input1`, description: 'Base Range Projection' </del> <ins> className: `merge-editor-diff-word ${inputClassName}`, description: 'Merge Editor' </ins> } }); }
Code change:
I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc

Related discussion:
text: blockClassNames.push('handled'); } if (modifiedBaseRange === activeModifiedBaseRange) { <del> blockClassNames.push('active'); </del> <ins> blockClassNames.push('focused'); </ins> } blockClassNames.push('result');
Code change:
I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc

Related discussion:
text: }); } } <ins> for (const diff of m.rights) { const range = diff.outputRange.toInclusiveRange(); if (range) { result.push({ range, options: { className: `merge-editor-diff result`, description: 'Merge Editor', isWholeLine: true, } }); } if (diff.rangeMappings) { for (const d of diff.rangeMappings) { result.push({ range: d.outputRange, options: { className: `merge-editor-diff-word result`, description: 'Merge Editor' } }); } } } </ins> } return result; });
Code change:
I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc

Related discussion:
text: flex-grow: 0; } <del> .monaco-editor .merge-accept-conflict-glyph { cursor: pointer; } .merge-editor-modified-base-range-input1 { background-color: var(--vscode-mergeEditor-modifiedBaseRange-input1); } .merge-editor-diff-input1 { background-color: var(--vscode-mergeEditor-diff-input1); } .merge-editor-modified-base-range-input2 { background-color: var(--vscode-mergeEditor-modifiedBaseRange-input2); } .merge-editor-diff-input2 { background-color: var(--vscode-mergeEditor-diff-input2); } .merge-editor-modified-base-range-combination { background-color: var(--vscode-mergeEditor-modifiedBaseRange-combination); </del> <ins> .merge-editor-diff { background-color: var(--vscode-mergeEditor-diff); </ins> } <del> .merge-editor-modified-base-range { background-color: var(--vscode-mergeEditor-diff); </del> <ins> .merge-editor-diff-word { background-color: var(--vscode-mergeEditor-diff-word); </ins> } .merge-editor-block { <del> border: 2px solid rgba(255, 166, 0, 0.479); </del> <ins> border: 2px solid var(--vscode-mergeEditor-conflictBorder-unhandledUnfocused); </ins> } <del> .merge-editor-block.active { border: 2px solid orange; </del> <ins> .merge-editor-block.focused { border: 2px solid var(--vscode-mergeEditor-conflictBorder-unhandledFocused); </ins> } .merge-editor-block.handled { <del> border: 2px solid rgba(134, 134, 134, 0.285); </del> <ins> border: 2px solid var(--vscode-mergeEditor-conflictBorder-handledUnfocused); </ins> } <del> .merge-editor-block.handled.active { border: 2px solid rgb(134, 134, 134, 0.8); } .merge-editor-block.handled.active { border: 2px solid rgba(193, 193, 193, 0.8); </del> <ins> .merge-editor-block.handled.focused { border: 2px solid var(--vscode-mergeEditor-conflictBorder-handledFocused); </ins> } .gutter-item {
Code change:
I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc

Related discussion:
text: background-color: var(--vscode-checkbox-border); } <del> .checkbox-background { </del> <ins> .merge-accept-gutter-marker .checkbox-background { </ins> background: var(--vscode-editor-background); }
Code change:
Testing !
That's actually a description of what clicking the button will do. This was as designed but maybe has a better idea?
Same feedback from in
The "..." in "Show Command Actions..." tells me it's clickable. Just removing the "..." would help, but it still looks like something I want to click on.

Related discussion:
text: return; } this._hoverDelayer.trigger(() => { <del> let hoverContent = `${localize('terminalPromptContextMenu', "Show Command Actions")}...`; </del> <ins> let hoverContent = `${localize('terminalPromptContextMenu', "Show Command Actions")}`; </ins> hoverContent += 'nn---nn'; if (command.genericMarkProperties) { if (command.genericMarkProperties.hoverMessage) {
Code change:
Testing !
I just noticed that is not localized and is not meant for display. That means that "Label" was not a good name for that function, but we can either just remove the state or find the code that drives the state label in the callstack.
Actually, it seems that only displays , , or , which is probably not super useful to the user anyways. It seems like the info like is only available on each thread, and a debug session can have multiple threads. Perhaps we should just remove the state for now.

Related discussion:
text: import { IQuickPickSeparator } from 'vs/platform/quickinput/common/quickInput'; import { IViewsService } from 'vs/workbench/common/views'; import { DEBUG_CONSOLE_QUICK_ACCESS_PREFIX, SELECT_AND_START_ID } from 'vs/workbench/contrib/debug/browser/debugCommands'; <del> import { getStateLabel, IDebugService, IDebugSession, REPL_VIEW_ID } from 'vs/workbench/contrib/debug/common/debug'; </del> <ins> import { IDebugService, IDebugSession, REPL_VIEW_ID } from 'vs/workbench/contrib/debug/common/debug'; </ins> export class DebugConsoleQuickAccess extends PickerQuickAccessProvider<IPickerQuickAccessItem> {
Code change:
Testing !
I just noticed that is not localized and is not meant for display. That means that "Label" was not a good name for that function, but we can either just remove the state or find the code that drives the state label in the callstack.
Actually, it seems that only displays , , or , which is probably not super useful to the user anyways. It seems like the info like is only available on each thread, and a debug session can have multiple threads. Perhaps we should just remove the state for now.

Related discussion:
text: if (highlights) { return { label, <del> description: getStateLabel(session.state), </del> highlights: { label: highlights }, accept: (keyMod, event) => { this._debugService.focusStackFrame(undefined, undefined, session, { explicit: true });
Code change:
Testing Current: ! Proposal: !
Spoke with and I have submitted to add the file icon association to seti-ui repository.

Related discussion:
text: "git": { "name": "seti-ui", "repositoryUrl": "https://github.com/jesseweed/seti-ui", <del> "commitHash": "6b83574de165123583d6d8d5b3b6c91f04b7153d" </del> <ins> "commitHash": "4dd6c27e1f5aed8068c2451dbaf0db3364545937" </ins> } }, "version": "0.1.0"
Code change:
Testing Current: ! Proposal: !
Spoke with and I have submitted to add the file icon association to seti-ui repository.

Related discussion:
text: "dockerfile": "_docker_light", "ignore": "_git_light", "fsharp": "_f-sharp_light", <ins> "git-commit": "_git_light", </ins> "go": "_go2_light", "groovy": "_grails_light", "handlebars": "_mustache_light",
Code change:
Testing Current: ! Proposal: !
Spoke with and I have submitted to add the file icon association to seti-ui repository.

Related discussion:
text: "npm-debug.log": "_npm_ignored_light" } }, <del> "version": "https://github.com/jesseweed/seti-ui/commit/6b83574de165123583d6d8d5b3b6c91f04b7153d" </del> <ins> "version": "https://github.com/jesseweed/seti-ui/commit/4dd6c27e1f5aed8068c2451dbaf0db3364545937" </ins> }  No newline at end of file
Code change:
Testing When I use cmd+up/down to navigate between POIs in task output, the blue box renders for a second on the item I have selected, but then disappears. I didn't understand what was happening to the focus border.
that is by design.
This has come up before, I think you had an idea to improve this?
I had the same experience in where I was on a slow machine. I think I had suggested just using a line on the side (like our activity bar) that remains until your focus changes: <img src="https://user-"
To the left of the command decorations? ! I like how visible the outline is when jumping between commands, so we could keep that as is and just also show the persistent line? !
yea I'd be open to trying that out, I think using both might be a bit overkill but just having the single line can also be hard to notice.

Related discussion:
text: .terminal-scroll-highlight { left: 0; right: 0; <ins> border-left: 5px solid #ffffff; border-left-width: 5px !important; } .terminal-scroll-highlight-outline { </ins> border: 1px solid #ffffff; }
Code change:
Testing When I use cmd+up/down to navigate between POIs in task output, the blue box renders for a second on the item I have selected, but then disappears. I didn't understand what was happening to the focus border.
that is by design.
This has come up before, I think you had an idea to improve this?
I had the same experience in where I was on a slow machine. I think I had suggested just using a line on the side (like our activity bar) that remains until your focus changes: <img src="https://user-"
To the left of the command decorations? ! I like how visible the outline is when jumping between commands, so we could keep that as is and just also show the persistent line? !
yea I'd be open to trying that out, I think using both might be a bit overkill but just having the single line can also be hard to notice.

Related discussion:
text: // Clear the current marker so successive focus/selection actions are performed from the // bottom of the buffer this._currentMarker = Boundary.Bottom; <ins> this._navigationDecoration?.dispose(); this._navigationDecoration = undefined; </ins> this._selectionStart = null; }
Code change:
Testing When I use cmd+up/down to navigate between POIs in task output, the blue box renders for a second on the item I have selected, but then disappears. I didn't understand what was happening to the focus border.
that is by design.
This has come up before, I think you had an idea to improve this?
I had the same experience in where I was on a slow machine. I think I had suggested just using a line on the side (like our activity bar) that remains until your focus changes: <img src="https://user-"
To the left of the command decorations? ! I like how visible the outline is when jumping between commands, so we could keep that as is and just also show the persistent line? !
yea I'd be open to trying that out, I think using both might be a bit overkill but just having the single line can also be hard to notice.

Related discussion:
text: if (markerIndex < 0) { this._currentMarker = Boundary.Top; this._terminal.scrollToTop(); <ins> this.clearMarker(); </ins> return; }
Code change:
Testing When I use cmd+up/down to navigate between POIs in task output, the blue box renders for a second on the item I have selected, but then disappears. I didn't understand what was happening to the focus border.
that is by design.
This has come up before, I think you had an idea to improve this?
I had the same experience in where I was on a slow machine. I think I had suggested just using a line on the side (like our activity bar) that remains until your focus changes: <img src="https://user-"
To the left of the command decorations? ! I like how visible the outline is when jumping between commands, so we could keep that as is and just also show the persistent line? !
yea I'd be open to trying that out, I think using both might be a bit overkill but just having the single line can also be hard to notice.

Related discussion:
text: if (markerIndex >= this._getCommandMarkers().length) { this._currentMarker = Boundary.Bottom; this._terminal.scrollToBottom(); <ins> this.clearMarker(); </ins> return; }
Code change:
Testing When I use cmd+up/down to navigate between POIs in task output, the blue box renders for a second on the item I have selected, but then disappears. I didn't understand what was happening to the focus border.
that is by design.
This has come up before, I think you had an idea to improve this?
I had the same experience in where I was on a slow machine. I think I had suggested just using a line on the side (like our activity bar) that remains until your focus changes: <img src="https://user-"
To the left of the command decorations? ! I like how visible the outline is when jumping between commands, so we could keep that as is and just also show the persistent line? !
yea I'd be open to trying that out, I think using both might be a bit overkill but just having the single line can also be hard to notice.

Related discussion:
text: }); this._navigationDecoration = decoration; if (decoration) { <del> const isRendered = false; </del> <ins> let renderedElement: HTMLElement | undefined; </ins> decoration.onRender(element => { <del> if (!isRendered) { // TODO: Remove when https://github.com/xtermjs/xterm.js/issues/3686 is fixed if (!element.classList.contains('xterm-decoration-overview-ruler')) { element.classList.add('terminal-scroll-highlight'); </del> <ins> if (!renderedElement) { renderedElement = element; element.classList.add('terminal-scroll-highlight', 'terminal-scroll-highlight-outline'); if (this._terminal?.element) { element.style.marginLeft = `-${getComputedStyle(this._terminal.element).paddingLeft}`; </ins> } } });
Code change:
Testing When I use cmd+up/down to navigate between POIs in task output, the blue box renders for a second on the item I have selected, but then disappears. I didn't understand what was happening to the focus border.
that is by design.
This has come up before, I think you had an idea to improve this?
I had the same experience in where I was on a slow machine. I think I had suggested just using a line on the side (like our activity bar) that remains until your focus changes: <img src="https://user-"
To the left of the command decorations? ! I like how visible the outline is when jumping between commands, so we could keep that as is and just also show the persistent line? !
yea I'd be open to trying that out, I think using both might be a bit overkill but just having the single line can also be hard to notice.

Related discussion:
text: }); // Number picked to align with symbol highlight in the editor timeout(350).then(() => { <del> decoration.dispose(); </del> <ins> if (renderedElement) { renderedElement.classList.remove('terminal-scroll-highlight-outline'); } </ins> }); } }
Code change:
Testing Clone a git repository Open git repository in VS Code desktop Make a change to one or more files Invoke the command You are presented with an empty picker <img width="736" alt="image" src="https://user-"

Related discussion:
text: } }, "enabledApiProposals": [ <del> "contribShareMenu" </del> <ins> "contribShareMenu", "contribEditSessions" </ins> ], "contributes": { "commands": [
Code change:
Testing Clone a git repository Open git repository in VS Code desktop Make a change to one or more files Invoke the command You are presented with an empty picker <img width="736" alt="image" src="https://user-"

Related discussion:
text: { "command": "github.copyVscodeDevLink", "title": "Copy vscode.dev Link" <del> }, { "command": "github.copyVscodeDevLinkFile", "title": "Copy vscode.dev Link" </del> <ins> }, { "command": "github.copyVscodeDevLinkFile", "title": "Copy vscode.dev Link" }, { "command": "github.openOnVscodeDev", "title": "Open on vscode.dev" } ], "continueEditSession": [ { "command": "github.openOnVscodeDev", "when": "github.hasGitHubRepo" </ins> } ], "menus": {
Code change:
Testing Clone a git repository Open git repository in VS Code desktop Make a change to one or more files Invoke the command You are presented with an empty picker <img width="736" alt="image" src="https://user-"

Related discussion:
text: { "command": "github.copyVscodeDevLinkFile", "when": "false" <ins> }, { "command": "github.openOnVscodeDev", "when": "false" </ins> } ], "file/share": [
Code change:
Testing Clone a git repository Open git repository in VS Code desktop Make a change to one or more files Invoke the command You are presented with an empty picker <img width="736" alt="image" src="https://user-"

Related discussion:
text: } } <ins> async function openVscodeDevLink(gitAPI: GitAPI): Promise<vscode.Uri | undefined> { try { const permalink = getPermalink(gitAPI, true, 'https://vscode.dev/github'); return permalink ? vscode.Uri.parse(permalink) : undefined; } catch (err) { vscode.window.showErrorMessage(err.message); return undefined; } } </ins> export function registerCommands(gitAPI: GitAPI): vscode.Disposable { const disposables = new DisposableStore();
Code change:
Testing Clone a git repository Open git repository in VS Code desktop Make a change to one or more files Invoke the command You are presented with an empty picker <img width="736" alt="image" src="https://user-"

Related discussion:
text: return copyVscodeDevLink(gitAPI, false); })); <ins> disposables.add(vscode.commands.registerCommand('github.openOnVscodeDev', async () => { return openVscodeDevLink(gitAPI); })); </ins> return disposables; }