jiebi/CodeConvo huggingface dataset:
Code change:
Testing In the screenshot below, "Chat: Insert at Cursor" should be "Chat: Insert into New File" !

Related discussion:
text: if (insertIntoNewFileKb) { hint += localize('insertIntoNewFile', " - Insert the code block into a new file ({0}).n", insertIntoNewFileKb); } else { <del> hint += localize('insertIntoNewFileNoKb', " - Insert the code block into a new file by configuring a keybinding for the Chat: Insert at Cursor command.n"); </del> <ins> hint += localize('insertIntoNewFileNoKb', " - Insert the code block into a new file by configuring a keybinding for the Chat: Insert into New File command.n"); </ins> } if (runInTerminalKb) { hint += localize('runInTerminal', " - Run the code block in the terminal ({0}).n", runInTerminalKb);
Code change:
Testing In the screenshot below, "Chat: Insert at Cursor" should be "Chat: Insert into New File" !

Related discussion:
text: let goToSymbolHint = ''; if (providerHasSymbols) { if (goToSymbolKb) { <del> goToSymbolHint = localize('goToSymbolHint', 'Go to a symbol ({0})', goToSymbolKb); </del> <ins> goToSymbolHint = localize('goToSymbolHint', 'Go to a symbol ({0}).', goToSymbolKb); </ins> } else { goToSymbolHint = localize('goToSymbolHintNoKb', 'To go to a symbol, configure a keybinding for the command Go To Symbol in Accessible View'); }
Code change:
Testing to filter e.g. Python Notice the non-extension entries remain at top Maybe this was by design, but I don't understand it. If I type python, don't I want to quickly select a python related entry?

Related discussion:
text: // Add default items const productLabel = this.productService.nameLong; const marketPlaceLabel = localize("reportExtensionMarketplace", "Extension Marketplace"); <del> issuePicksConst.push( { label: productLabel, ariaLabel: productLabel, accept: () => this.commandService.executeCommand('workbench.action.openIssueReporter', { issueSource: IssueSource.VSCode }) }, { label: marketPlaceLabel, ariaLabel: marketPlaceLabel, accept: () => this.commandService.executeCommand('workbench.action.openIssueReporter', { issueSource: IssueSource.Marketplace }) }, { type: 'separator', label: localize('extensions', "Extensions") } ); </del> <ins> const productFilter = matchesFuzzy(filter, productLabel, true); const marketPlaceFilter = matchesFuzzy(filter, marketPlaceLabel, true); // Add product pick if product filter matches if (productFilter) { issuePicksConst.push({ label: productLabel, ariaLabel: productLabel, highlights: { label: productFilter }, accept: () => this.commandService.executeCommand('workbench.action.openIssueReporter', { issueSource: IssueSource.VSCode }) }); } // Add marketplace pick if marketplace filter matches if (marketPlaceFilter) { issuePicksConst.push({ label: marketPlaceLabel, ariaLabel: marketPlaceLabel, highlights: { label: marketPlaceFilter }, accept: () => this.commandService.executeCommand('workbench.action.openIssueReporter', { issueSource: IssueSource.Marketplace }) }); } issuePicksConst.push({ type: 'separator', label: localize('extensions', "Extensions") }); </ins> // creates menu from contributed const menu = this.menuService.createMenu(MenuId.IssueReporter, this.contextKeyService);
Code change:
Note that both of these scenarios used to work. In the terminal inine chat, run a command like which yields just a chat message response. Try to tab to it. one cannot Run a command like which yields a code block response. Try to use to go from the input box to a code block response and vice versa. one cannot
Note that the keybindings are important because it's annoying as a SR /keyboard only user to have to tab through a bunch of things to reach the response.
This works for me, I do the following with success cmd+i, paste , press Enter wait for the response press tab repeatedly and reach the response
the tabbing part works for me in today's insider's
I'm able to spam Ctrl+Up on Windows to focus between the inputbox and the chat response, but I'm not able to spam Ctrl+Down to do the same. I'm unable to use either shortcut to focus from the inputbox directly into a code block within the chat response. Let me know if the behaviour is as expected or if there's some other steps I can follow.
I haven't tried windows yet. This won't directly focus the code editor, just the response.
this works on mac, could you pls try on windows?
The behavior seems wrong now and is quite disorienting: Input: ctrl+up will focus the response list ctrl+down will focus the response list Response list: ctrl+up does nothing ctrl+down does nothing Response code block: ctrl+up focuses the input ctrl+down focuses the response list I would expect: Input: ctrl+up does nothing ctrl+down will focus the response code block Response list: ctrl+up focuses the input Not sure? Response code block: ctrl+up focuses the input ctrl+down focuses the next code block, otherwise not sure
This issue was about cmdCtrl+up/down going between the response list and the input. This is unexpected, but unlikely to be attempted by the user IMO. Input: ctrlCmd+up will focus the response list This works on mac. Not sure why it doesn't on windows. Response list: ctrlCmd+up does nothing I didn't implement this yet, but can in April. Response code block: ctrl+up focuses the input ctrl+down focuses the response list
verified that this does work. I'm making a new issue about focusing the code block(s) and the bug with in the input focusing the list

Related discussion:
text: return; } const contr = TerminalChatController.activeChatWidget || TerminalChatController.get(activeInstance); <del> contr?.chatWidget?.focusResponse(); </del> <ins> contr?.chatWidget?.inlineChatWidget.chatWidget.focusLastMessage(); </ins> } });
Code change:
Note that both of these scenarios used to work. In the terminal inine chat, run a command like which yields just a chat message response. Try to tab to it. one cannot Run a command like which yields a code block response. Try to use to go from the input box to a code block response and vice versa. one cannot
Note that the keybindings are important because it's annoying as a SR /keyboard only user to have to tab through a bunch of things to reach the response.
This works for me, I do the following with success cmd+i, paste , press Enter wait for the response press tab repeatedly and reach the response
the tabbing part works for me in today's insider's
I'm able to spam Ctrl+Up on Windows to focus between the inputbox and the chat response, but I'm not able to spam Ctrl+Down to do the same. I'm unable to use either shortcut to focus from the inputbox directly into a code block within the chat response. Let me know if the behaviour is as expected or if there's some other steps I can follow.
I haven't tried windows yet. This won't directly focus the code editor, just the response.
this works on mac, could you pls try on windows?
The behavior seems wrong now and is quite disorienting: Input: ctrl+up will focus the response list ctrl+down will focus the response list Response list: ctrl+up does nothing ctrl+down does nothing Response code block: ctrl+up focuses the input ctrl+down focuses the response list I would expect: Input: ctrl+up does nothing ctrl+down will focus the response code block Response list: ctrl+up focuses the input Not sure? Response code block: ctrl+up focuses the input ctrl+down focuses the next code block, otherwise not sure
This issue was about cmdCtrl+up/down going between the response list and the input. This is unexpected, but unlikely to be attempted by the user IMO. Input: ctrlCmd+up will focus the response list This works on mac. Not sure why it doesn't on windows. Response list: ctrlCmd+up does nothing I didn't implement this yet, but can in April. Response code block: ctrl+up focuses the input ctrl+down focuses the response list
verified that this does work. I'm making a new issue about focusing the code block(s) and the bug with in the input focusing the list

Related discussion:
text: focus(): void { this._inlineChatWidget.focus(); } <del> focusResponse(): void { const responseElement = this._inlineChatWidget.domNode.querySelector(ChatElementSelectors.ResponseEditor) || this._inlineChatWidget.domNode.querySelector(ChatElementSelectors.ResponseMessage); if (responseElement instanceof HTMLElement) { responseElement.focus(); } } </del> hasFocus(): boolean { return this._inlineChatWidget.hasFocus(); }
Code change:
Note that both of these scenarios used to work. In the terminal inine chat, run a command like which yields just a chat message response. Try to tab to it. one cannot Run a command like which yields a code block response. Try to use to go from the input box to a code block response and vice versa. one cannot
Note that the keybindings are important because it's annoying as a SR /keyboard only user to have to tab through a bunch of things to reach the response.
This works for me, I do the following with success cmd+i, paste , press Enter wait for the response press tab repeatedly and reach the response
the tabbing part works for me in today's insider's
I'm able to spam Ctrl+Up on Windows to focus between the inputbox and the chat response, but I'm not able to spam Ctrl+Down to do the same. I'm unable to use either shortcut to focus from the inputbox directly into a code block within the chat response. Let me know if the behaviour is as expected or if there's some other steps I can follow.
I haven't tried windows yet. This won't directly focus the code editor, just the response.
this works on mac, could you pls try on windows?
The behavior seems wrong now and is quite disorienting: Input: ctrl+up will focus the response list ctrl+down will focus the response list Response list: ctrl+up does nothing ctrl+down does nothing Response code block: ctrl+up focuses the input ctrl+down focuses the response list I would expect: Input: ctrl+up does nothing ctrl+down will focus the response code block Response list: ctrl+up focuses the input Not sure? Response code block: ctrl+up focuses the input ctrl+down focuses the next code block, otherwise not sure
This issue was about cmdCtrl+up/down going between the response list and the input. This is unexpected, but unlikely to be attempted by the user IMO. Input: ctrlCmd+up will focus the response list This works on mac. Not sure why it doesn't on windows. Response list: ctrlCmd+up does nothing I didn't implement this yet, but can in April. Response code block: ctrl+up focuses the input ctrl+down focuses the response list
verified that this does work. I'm making a new issue about focusing the code block(s) and the bug with in the input focusing the list

Related discussion:
text: } } <del> const enum ChatElementSelectors { ResponseEditor = '.chatMessageContent textarea', ResponseMessage = '.chatMessageContent', } </del>
Code change:
using Default Light + theme run peek references <img width="978" alt="Screenshot 2024-03-26 at 17 30 37" src=""

Related discussion:
text: // Import the effects we need import { Color } from 'vs/base/common/color'; <del> import { registerColor, darken, lighten, ifDefinedThenElse, transparent } from 'vs/platform/theme/common/colorUtils'; </del> <ins> import { registerColor, darken, lighten, transparent } from 'vs/platform/theme/common/colorUtils'; </ins> // Import the colors we need import { foreground, contrastBorder, activeContrastBorder, focusBorder, iconForeground } from 'vs/platform/theme/common/colors/baseColors';
Code change:
using Default Light + theme run peek references <img width="978" alt="Screenshot 2024-03-26 at 17 30 37" src=""

Related discussion:
text: nls.localize('highlight', 'List/Tree foreground color of the match highlights when searching inside the list/tree.')); export const listFocusHighlightForeground = registerColor('list.focusHighlightForeground', <del> { dark: listHighlightForeground, light: ifDefinedThenElse(listActiveSelectionBackground, listHighlightForeground, '#BBE7FF'), hcDark: listHighlightForeground, hcLight: listHighlightForeground }, </del> <ins> { dark: listHighlightForeground, light: listHighlightForeground, hcDark: listHighlightForeground, hcLight: listHighlightForeground }, </ins> nls.localize('listFocusHighlightForeground', 'List/Tree foreground color of the match highlights on actively focused items when searching inside the list/tree.')); export const listInvalidItemForeground = registerColor('list.invalidItemForeground',
Code change:
Sometimes the default width for inline chat seems very wide: <img width="854" alt="image" src=""Maybe it could grow while typing and or allow to be resized.
decided against dynamic and going with a more reasonable default width of 360px

Related discussion:
text: import { Emitter, Event } from 'vs/base/common/event'; import { DisposableStore } from 'vs/base/common/lifecycle'; import { IPosition, Position } from 'vs/editor/common/core/position'; <del> import { clamp } from 'vs/base/common/numbers'; </del> import { renderLabelWithIcons } from 'vs/base/browser/ui/iconLabel/iconLabels'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { inlineChatBackground } from 'vs/workbench/contrib/inlineChat/common/inlineChat';
Code change:
Sometimes the default width for inline chat seems very wide: <img width="854" alt="image" src=""Maybe it could grow while typing and or allow to be resized.
decided against dynamic and going with a more reasonable default width of 360px

Related discussion:
text: import { Range } from 'vs/editor/common/core/range'; import { ServiceCollection } from 'vs/platform/instantiation/common/serviceCollection'; import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; <ins> import { EditorOption } from 'vs/editor/common/config/editorOptions'; </ins> export class InlineChatContentWidget implements IContentWidget {
Code change:
Sometimes the default width for inline chat seems very wide: <img width="854" alt="image" src=""Maybe it could grow while typing and or allow to be resized.
decided against dynamic and going with a more reasonable default width of 360px

Related discussion:
text: beforeRender(): IDimension | null { <del> const contentWidth = this._editor.getLayoutInfo().contentWidth; const minWidth = Math.round(contentWidth * 0.38); const maxWidth = Math.round(contentWidth * 0.82); const width = clamp(220, minWidth, maxWidth); </del> <ins> const maxHeight = this._widget.input.inputEditor.getOption(EditorOption.lineHeight) * 5; </ins> const inputEditorHeight = this._widget.inputEditor.getContentHeight(); <del> this._widget.inputEditor.layout(new dom.Dimension(width, inputEditorHeight)); </del> <ins> this._widget.inputEditor.layout(new dom.Dimension(360, Math.min(maxHeight, inputEditorHeight))); </ins> // const actualHeight = this._widget.inputPartHeight; // return new dom.Dimension(width, actualHeight);
Code change:
Sometimes the default width for inline chat seems very wide: <img width="854" alt="image" src=""Maybe it could grow while typing and or allow to be resized.
decided against dynamic and going with a more reasonable default width of 360px

Related discussion:
text: display: none; } <ins> .monaco-workbench .inline-chat-content-widget.interactive-session .interactive-session { max-width: unset; } </ins> .monaco-workbench .inline-chat-content-widget.interactive-session .interactive-input-part .interactive-execute-toolbar { margin-bottom: 1px; }
Code change:
Testing Sometimes when I hovered over the button it would show the hover of that button over the button. When moving down to the button it would close the editor hover sometimes because the mouse would move over the hover. This could be solved by setting an anchor for the and hovers

Related discussion:
text: import { Codicon } from 'vs/base/common/codicons'; import { ThemeIcon } from 'vs/base/common/themables'; import { onUnexpectedExternalError } from 'vs/base/common/errors'; <del> import { getDefaultHoverDelegate } from 'vs/base/browser/ui/hover/hoverDelegateFactory'; </del> import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; <del> import { ClickAction, KeyDownAction } from 'vs/base/browser/ui/hover/hoverWidget'; </del> <ins> import { ClickAction, HoverPosition, KeyDownAction } from 'vs/base/browser/ui/hover/hoverWidget'; </ins> import { KeyCode } from 'vs/base/common/keyCodes'; <del> import { IHoverService } from 'vs/platform/hover/browser/hover'; </del> <ins> import { IHoverService, WorkbenchHoverDelegate } from 'vs/platform/hover/browser/hover'; </ins> import { AsyncIterableObject } from 'vs/base/common/async'; import { LanguageFeatureRegistry } from 'vs/editor/common/languageFeatureRegistry'; import { getHoverProviderResultsAsAsyncIterable } from 'vs/editor/contrib/hover/browser/getHover';
Code change:
Testing Sometimes when I hovered over the button it would show the hover of that button over the button. When moving down to the button it would close the editor hover sometimes because the mouse would move over the hover. This could be solved by setting an anchor for the and hovers

Related discussion:
text: this._openerService, this._keybindingService, this._hoverService, <ins> this._configurationService, </ins> context.onContentsChanged ); return this._renderedHoverParts;
Code change:
Testing Sometimes when I hovered over the button it would show the hover of that button over the button. When moving down to the button it would close the editor hover sometimes because the mouse would move over the hover. This could be solved by setting an anchor for the and hovers

Related discussion:
text: private readonly _openerService: IOpenerService, private readonly _keybindingService: IKeybindingService, private readonly _hoverService: IHoverService, <ins> private readonly _configurationService: IConfigurationService, </ins> private readonly _onFinishedRendering: () => void, ) { super();
Code change:
Testing Sometimes when I hovered over the button it would show the hover of that button over the button. When moving down to the button it would close the editor hover sometimes because the mouse would move over the hover. This could be solved by setting an anchor for the and hovers

Related discussion:
text: const isActionIncrease = action === HoverVerbosityAction.Increase; const actionElement = dom.append(container, $(ThemeIcon.asCSSSelector(isActionIncrease ? increaseHoverVerbosityIcon : decreaseHoverVerbosityIcon))); actionElement.tabIndex = 0; <ins> const hoverDelegate = new WorkbenchHoverDelegate('mouse', false, { target: container, position: { hoverPosition: HoverPosition.LEFT } }, this._configurationService, this._hoverService); </ins> if (isActionIncrease) { const kb = this._keybindingService.lookupKeybinding(INCREASE_HOVER_VERBOSITY_ACTION_ID); <del> store.add(this._hoverService.setupUpdatableHover(getDefaultHoverDelegate('mouse'), actionElement, kb ? </del> <ins> store.add(this._hoverService.setupUpdatableHover(hoverDelegate, actionElement, kb ? </ins> nls.localize('increaseVerbosityWithKb', "Increase Verbosity ({0})", kb.getLabel()) : nls.localize('increaseVerbosity', "Increase Verbosity"))); } else { const kb = this._keybindingService.lookupKeybinding(DECREASE_HOVER_VERBOSITY_ACTION_ID); <del> store.add(this._hoverService.setupUpdatableHover(getDefaultHoverDelegate('mouse'), actionElement, kb ? </del> <ins> store.add(this._hoverService.setupUpdatableHover(hoverDelegate, actionElement, kb ? </ins> nls.localize('decreaseVerbosityWithKb', "Decrease Verbosity ({0})", kb.getLabel()) : nls.localize('decreaseVerbosity', "Decrease Verbosity"))); }
Code change:
Testing The keybinding does not work on windows due to quick open. Also the keybinding collides with the command. I wonder if this could be solved without registering keybindings. One idea could be that when the hover is focused the user could just use and on the keyboard to increase and decrease the hover (possibly also arrow keys could work). Make sure to mention in the hover of the increase and decrease actions what the keybinding or keyboard key is.
That's a very good point. I think we would still want ideally the + and - to be linked to keybindings so they can be configured by the user. I'll remove the keybindings, so they can simply be set by the users if they so wish. The current code already renders the keybindings if they are set: Perhaps they are not fetched correctly in your case because of the keybinding collisions. !

Related discussion:
text: comment: ['Label for action that will increase the hover verbosity level.'] }, "Increase Hover Verbosity Level"), alias: 'Increase Hover Verbosity Level', <del> precondition: EditorContextKeys.hoverFocused, kbOpts: { kbExpr: EditorContextKeys.hoverFocused, primary: KeyChord(KeyMod.CtrlCmd | KeyCode.KeyK, KeyMod.CtrlCmd | KeyCode.KeyP), weight: KeybindingWeight.EditorContrib } </del> <ins> precondition: EditorContextKeys.hoverFocused </ins> }); }
Code change:
Testing The keybinding does not work on windows due to quick open. Also the keybinding collides with the command. I wonder if this could be solved without registering keybindings. One idea could be that when the hover is focused the user could just use and on the keyboard to increase and decrease the hover (possibly also arrow keys could work). Make sure to mention in the hover of the increase and decrease actions what the keybinding or keyboard key is.
That's a very good point. I think we would still want ideally the + and - to be linked to keybindings so they can be configured by the user. I'll remove the keybindings, so they can simply be set by the users if they so wish. The current code already renders the keybindings if they are set: Perhaps they are not fetched correctly in your case because of the keybinding collisions. !

Related discussion:
text: comment: ['Label for action that will decrease the hover verbosity level.'] }, "Decrease Hover Verbosity Level"), alias: 'Decrease Hover Verbosity Level', <del> precondition: EditorContextKeys.hoverFocused, kbOpts: { kbExpr: EditorContextKeys.hoverFocused, primary: KeyChord(KeyMod.CtrlCmd | KeyCode.KeyK, KeyMod.CtrlCmd | KeyCode.KeyM), weight: KeybindingWeight.EditorContrib } </del> <ins> precondition: EditorContextKeys.hoverFocused </ins> }); }
Code change:
Testing on Linux I have 2 monitors: primary and secondary. I opened VS Code and maximized it on my secondary monitor. Then I dragged an aux window out and maximized it on my primary monitor. After closing and reopening VS Code, the maximized state of both my main window and my aux window were restored, but both were on my secondary monitor. The aux window was on top. I'm using Remote Desktop + Hyper V, so maybe something is going on there: Remote Desktop from Windows to another Windows machine. Hyper V to an Ubuntu VM.
Looks like which monitor is primary and which is secondary doesn't seem to matter as the same thing happens when swap the windows that aux and main are on.
I also experienced a variant of this: Main VS Code window maximized in primary monitor, 1 aux window maximized in primary monitor, 1 aux window maximized in secondary monitor Close VS Code Reopen VS Code All 3 windows (main and aux) are restored to max, but they're all restored to my primary monitor I'm testing on Windows 11 Insiders.

Related discussion:
text: const fullscreen = isFullscreen(this.window); return { ...state, <del> bounds: this.maximized ? undefined : state.bounds, // ignore if maximized (fullscreen is not yet supported!) </del> <ins> bounds: state.bounds, </ins> mode: this.maximized ? AuxiliaryWindowMode.Maximized : fullscreen ? AuxiliaryWindowMode.Fullscreen : AuxiliaryWindowMode.Normal }; }
Code change:
Testing Steps: Use Windows PowerShell (not PowerShell Core) Turn on the terminal intellisense Type stuff is to the terminal

Related discussion:
text: $completionPrefix = $commandLine # Get completions <del> $result = "`e]633;Completions" </del> <ins> $result = "$([char]0x1b)]633;Completions" </ins> if ($completionPrefix.Length -gt 0) { # Get and send completions $completions = TabExpansion2 -inputScript $completionPrefix -cursorColumn $cursorIndex