jiebi/CodeConvo huggingface dataset:
Code change:
* with the next editor or if it will be kept. */ preview?: boolean; <ins> /** * An optional selection to apply for the document in the [editor](#TextEditor). */ selection?: Range; </ins> } /**

Related discussion:
text: For
Verify: write an extension that exercises the following APIs by passing in a selection as option and verify the selection is revealed and showing up in the opened editor: command API Provide a property of type to get it. !
Code change:
}); const searchOperation = await startInput.ongoingSearchOperation; <del> this.onSearchComplete(searchOperation, config, startInput); </del> <ins> await this.onSearchComplete(searchOperation, config, startInput); </ins> } private async onSearchComplete(searchOperation: ISearchComplete, startConfig: SearchConfiguration, startInput: SearchEditorInput) {

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.61.0 (I've seen this before and see it on too) OS Version: MacOS 11.6 Steps to Reproduce: Have 2 editor groups in workspace. Open a search editor (Cmd+Shift+F [can't remember if that's a default or my custom keybinding]) it to the other editor group. something to search for. At this point, you have to scroll up to see the results.
I've been looking into this. Any ideas where to start? I see that the following code does get called, but doesn't seem to position it correctly. If I wrap in a for 500ms, it works, but that's not a good long term solution.
Code change:
model.dispose(); mode.dispose(); }); <ins> test('issue #111128: Multicursor `Enter` issue with indentation', () => { const model = createTextModel('    let a, b, c;', { detectIndentation: false, insertSpaces: false, tabSize: 4 }, mode.getLanguageIdentifier()); withTestCodeEditor(null, { model: model }, (editor, viewModel) => { editor.setSelections([ new Selection(1, 11, 1, 11), new Selection(1, 14, 1, 14), ]); viewModel.type('n', 'keyboard'); assert.equal(model.getValue(), '    let a,nt b,nt c;'); }); }); </ins> }); interface ICursorOpts {

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.51.1 / 1.52.0-insider OS Version: Ubuntu 20.04 / Windows 10 Steps to Reproduce: 4x spaces at the beginning of a line multiple cursors on that line enter Expected: Insert newline at each of the positions where cursor is present Actual Behavior: Inserts newline only at the first (NOT the left most) cursor position (Let me know the relevant settings values required) Addiditional info: I use tabs (width of 4 spaces) for indentation for formatting ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
I think this might be caused by one of your installed extensions. Here it is on my machine: ! To validate this, could you please : Run the command Developer: Toggle Keyboard Shortcuts Troubleshooting This will activate logging of dispatched keyboard shortcuts and will open an output panel with the corresponding log file. You can then press <kbdEnter</kbdand check what command is invoked. If you are having trouble understanding the output, please feel free to paste here and I can help decipher it for you.
Here is the renderer keyboard troubleshoot log: Also, the I have disabled all the extensions. And, now, I can reproduce this with the latest stable too and in Ubuntu.
It is also not exclusive to the multi cursors created using keybinding. I can reproduce this by placing mulitple cursors created using the too.
From the keyboard log, I can confirm that nobody is "stealing" Enter via keybindings. But there is another way that extensions can intercept that, via our command. That is the way in which intercepts Enter. Does this reproduce when disabling all extensions? Press and then choose !
Hey , In all of my previuos posts I have made sure that I have disabled all the extensions (by running the command that you have mentioned) and also, at the end of each of my posts I have explicitly stated that I had disabled the extensions. Can it have anything to do with my settings related to tabs?
Code change:
model.dispose(); mode.dispose(); }); <ins> test('issue #111128: Multicursor `Enter` issue with indentation', () => { const model = createTextModel('    let a, b, c;', { detectIndentation: false, insertSpaces: false, tabSize: 4 }, mode.getLanguageIdentifier()); withTestCodeEditor(null, { model: model }, (editor, viewModel) => { editor.setSelections([ new Selection(1, 11, 1, 11), new Selection(1, 14, 1, 14), ]); viewModel.type('n', 'keyboard'); assert.equal(model.getValue(), '    let a,nt b,nt c;'); }); }); </ins> }); interface ICursorOpts {

Related discussion:
text: May be, inspect my settings here: (which has ) and, try to reproduce the issue by applying the exact same settings (copy paste my ).
Also, , Please carefully go through each of the above posts. It seems like you are not reading all the comments. It will save me from repeating the same thing again and again. Thanks.
Thank you for your patience, with your settings, I could finally reproduce. I missed the fact that the editor is configured to use tabs and I believed you might be using vim due to the block cursor in the GIF. You can workaround by using .
Code change:
builtin return fi <ins> __vsc_initialized="0" </ins> __vsc_in_command_execution="1" __vsc_last_history_id=0

Related discussion:
text: !
updated Insider's and the problem remains
I think this is the same as We will need to always send the exit code and have it get evaluated on the renderer against the extracted command name to fix these problems.
sometimes reproduces on mac
you can check if this is the same issue () by running a command a few times and then when is run if it's a single entry or multiple in the output.
interesting to me that it allows repro on linux/WSL and does so inconsistently on mac. here's linux: !
K, let's try understand this a little better then, that shouldn't happen as the initial history id is 0:
Oh I figured out when it reproes on mac - if you run the same command in a different terminal, then the second and beyond ones don't have an exit code
Running the command again in the terminal where you first ran the command works every time and does not repro on mac. So mac steps are: in terminal 1 - again in terminal 1 - in terminal 2 - Linux: a terminal and run any command - placeholder decoration shown for the first one regardless of exit code
It would be nice to fix this since is the default shell used
Think I see the problem, PR incoming.
Code change:
const element = this.options[index]; let optionDisabled: boolean; index === this.disabledOptionIndex ? optionDisabled = true : optionDisabled = false; <del> listEntries.push({ optionText: element, optionDisabled: optionDisabled }); </del> <ins> const optionDescription = this.detailsProvider ? this.detailsProvider(index) : { details: null, isMarkdown: false }; listEntries.push({ optionText: element, optionDisabled: optionDisabled, optionDescriptionText: optionDescription.details }); </ins> } this.selectList.splice(0, this.selectList.length, listEntries);

Related discussion:
text: New enum/select box detailed descriptions should be read by reader. Add describedby attribute handling for details provider within selectbox.
Either describedby or just
Yep, I've thought about live/alert also. By my research this does not really match the expected taxonomy for the accessibility tree, an extended description is pretty much exactly what describedby is for. That said, describedby probably will not be happy changing which will mean I will need the static set of descriptions in the Dom. Not a big deal, just another example of where nothing is straightforward. But, that's why we get paid the big bucks ... well at least you :-o ! What I really want to solve is getting rid of the multiple 'clickable' readings. I think I may have a way to avoid that which will be very important for these descriptions given the number of links.
Good point, I have no idea if pointing all of the selectbox items at the same details box will work, or if there's something we can do to order events to make it work better. Or maybe changing the 'id' of the details element for each item. I'm very curious what's causing that! Very weird.
describedby can have a list of IDs associated with it. like labeled by and most other ARIA aspects it does not like things changing underneath it, that of course is what aria-live is for but, but everything I read says use this judiciously. I think having a separate set of descriptions (modified for reader output/minimal clickable) will not be a big deal. Just as the options are static, so are the descriptions so hiding them in the select for use will not be an issue. I haven't done the definitive experiment yet but, I believe the multiple clickable issue has to do with something like this: I think the reader can find these as all clickable elements when they are descendents of a managed accessibility tree. my research has yet to determine if this is considered a bug or as designed
Code change:
.monaco-workbench .terminal-action.new { background: url('new.svg') center center no-repeat; } /* Dark theme / HC theme */ .vs-dark .monaco-workbench .terminal-action.kill, .hc-black .monaco-workbench .terminal-action.kill { background: url('kill-inverse.svg') center center no-repeat; } <del> .vs-dark .monaco-workbench .terminal-action.new, .hc-black .monaco-workbench .terminal-action.new { background: url('new-inverse.svg') center center no-repeat; } </del>  No newline at end of file <ins> .vs-dark .monaco-workbench .terminal-action.new, .hc-black .monaco-workbench .terminal-action.new { background: url('new-inverse.svg') center center no-repeat; } .vs-dark .monaco-workbench.mac .panel.integrated-terminal .xterm-rows, .hc-black .monaco-workbench.mac .panel.integrated-terminal .xterm-rows { cursor: -webkit-image-set(url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAQAAAC1+jfqAAAAL0lEQVQoz2NgCD3x//9/BhBYBWdhgFVAiVW4JBFKGIa4AqD0//9D3pt4I4tAdAMAHTQ/j5Zom30AAAAASUVORK5CYII=') 1x, url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAQAAADZc7J/AAAAz0lEQVRIx2NgYGBY/R8I/vx5eelX3n82IJ9FxGf6tksvf/8FiTMQAcAGQMDvSwu09abffY8QYSAScNk45G198eX//yev73/4///701eh//kZSARckrNBRvz//+8+6ZohwCzjGNjdgQxkAg7B9WADeBjIBqtJCbhRA0YNoIkBSNmaPEMoNmA0FkYNoFKhapJ6FGyAH3nauaSmPfwI0v/3OukVi0CIZ+F25KrtYcx/CTIy0e+rC7R1Z4KMICVTQQ14feVXIbR695u14+Ir4gwAAD49E54wc1kWAAAAAElFTkSuQmCC') 2x) 5 8, text; } </ins>  No newline at end of file

Related discussion:
text: VSCode Version: Code - Insiders 1.5.0-insider (, 2016-08-09T16:02:06.523Z) OS Version: Darwin x64 14.5.0
Code change:
this.show(); } })); <ins> this._register(this._configurationService.onDidChangeConfiguration(e => { if (e.affectsConfiguration(TerminalSettingId.AccessibleViewFocusOnCommandExecution)) { this._updateCommandExecutedListener(); } })); this._register(this._instance.capabilities.onDidAddCapability(e => { if (e.capability.type === TerminalCapability.CommandDetection) { this._updateCommandExecutedListener(); } })); </ins> } xtermReady(xterm: IXtermTerminal & { raw: Terminal }): void { const addon = this._instantiationService.createInstance(TextAreaSyncAddon, this._instance.capabilities); xterm.raw.loadAddon(addon);

Related discussion:
text: Type: <bFeature Request</bCC Please consider auto-activiating accessible view in terminal when user hit enter key. In most cases, screen reader users want to open accessible view after executing command in terminal. Thus, pressing Enter key can do: the current command to terminal. Accessible View immediately. Rather than having this as the default mode, we could consider adding this as a custom user setting. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-02T09:02:24.464Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
This makes sense. let us know if you have any thoughts.
I imagine this mode can boost user productivity because VSCode now sends user typing in Accessible View directly to the active terminal. If this mode is , users will experience more seamless round trip between terminal input and accessible view without having to press Alt+F2 and ESC.
To verify, enable . Run a command in the terminal. The accessible view should open.
Code change:
const termBox = xterm.element.getBoundingClientRect(); const rowHeight = termBox.height / xterm.rows; const overlayHeight = stickyScrollLineCount * rowHeight; <del> this._element.style.bottom = `${termBox.height - overlayHeight + 1}px`; </del> <ins> // Adjust sticky scroll content if it would below the end of the command, obscuring the // following command. let endMarkerOffset = 0; if (!isPartialCommand && command.endMarker && command.endMarker.line !== -1) { if (buffer.viewportY + stickyScrollLineCount > command.endMarker.line) { const diff = buffer.viewportY + stickyScrollLineCount - command.endMarker.line; endMarkerOffset = diff * rowHeight; } } this._element.style.bottom = `${termBox.height - overlayHeight + 1 + endMarkerOffset}px`; </ins> } } else { this._setVisible(false);

Related discussion:
text: Testing So I was testing the terminal sticky scroll and I noticed that the sticky code block disappears in an abrupt manner when the beginning (not the end) of the multiline terminal command, reaches the end of the scope. To give more context about what I mean, I the GIF below. I was sort of expecting the code block to start disappearing when the line reached the end of the output for that command. I noticed that the code block disappeared however when the line reached the end of the output for that run. I don't think this is a problem per say, it's a different manner of animating sticky scroll. I was just wondering if this is intended? I think the potential issue with this approach is that the sticky scroll block is hiding the next terminal command and its output while you are scrolling until it disappears. In the editor, sticky scroll starts disappearing progressively when the bottom of the last block/line touches the end of the scope. Perhaps we could explore something similar?
This is actually a bug, it's meant to scroll up as in the editor and was doing that at some point. Note that it's not as smooth as the editor since there's no "partial line scrolling" in the terminal
Repro that demonstrates more clearly what's happening: Run: Run: Run: when scrolling, sticky scroll from a command should never obscure the command below it like this: !
I see the prompt line sort of being obscured here
Code change:
} if (currentCount < desiredCount) { <del> const rulerWidth = dom.computeScreenAwareSize(1); </del> <ins> const rulerWidth = this._context.model.getTabSize(); </ins> let addCount = desiredCount - currentCount; while (addCount > 0) { let node = createFastDomNode(document.createElement('div'));

Related discussion:
text: The rulers and indent guides do not display well on high pixel density displays VSCode Version: Version 1.21.0 (1.21.0) OS Version: macOS Sierra 10.12.6 (16G1212) Steps to Reproduce: out editor Does this issue occur when all extensions are disabled?: Yes Example !
Code change:
const runToolbar = this.setupRunToolbar(runButtonContainer, container, contextKeyService, disposables); const executionOrderLabel = DOM.append(cellContainer, $('div.execution-count-label')); <ins> executionOrderLabel.setAttribute('title', 'Execution Order'); </ins> const editorPart = DOM.append(cellContainer, $('.cell-editor-part')); const editorContainer = DOM.append(editorPart, $('.cell-editor-container'));

Related discussion:
text: Testing Unfiltered notebook noob feedback: ! I was expecting a tooltip to tell me what it meant.
Agreed that we should add tooltip for it.
how would you interpret it if there was a tooltip that said "Execution Order"?
when you run all cells it goes in that order? I was expecting that to be sequential from the top?
It's the order that it was executed it, not the order it will execute in. Hopefully a user would figure that out if they run the cell and see it change.
oh, more explicit would be better then imo I also question why this is useful but I'm guessing this is a common notebooks feature elsewhere?
Yeah it's what people expect from Jupyter and can help you understand the state of the kernel
Thanks that needs to be localized though. btw if you are going to merge your change in, you can just commit directly, no PR needed
Code change:
} private _showToggleVisibilityQuickPick() { <del> const quickPick = this._quickInputService.createQuickPick(); </del> <ins> const quickPick = this._register(this._quickInputService.createQuickPick()); </ins> quickPick.hideInput = true; quickPick.hideCheckAll = true; quickPick.canSelectMany = true;

Related discussion:
text: Quick pick and events are disposables: is a listeners are : , , , , , A few instances of pickers or events not being disposed or registered as disposable: [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] //cc
Thanks for catching these just taught me that there's a better way to use the quick pick API - with and that will avoid this
Interesting, curious to see how that change looks like, I have a lot more places:
Code change:
export const textSeparatorForeground = registerColor('textSeparator.foreground', { light: '#0000002e', dark: '#ffffff2e', hcDark: Color.black, hcLight: '#292929' }, nls.localize('textSeparatorForeground', "Color for text separators.")); export const textLinkForeground = registerColor('textLink.foreground', { light: '#006AB1', dark: '#3794FF', hcDark: '#3794FF', hcLight: '#0F4A85' }, nls.localize('textLinkForeground', "Foreground color for links in text.")); export const textLinkActiveForeground = registerColor('textLink.activeForeground', { light: '#006AB1', dark: '#3794FF', hcDark: '#3794FF', hcLight: '#0F4A85' }, nls.localize('textLinkActiveForeground', "Foreground color for links in text when clicked on and on mouse hover.")); <del> export const textPreformatForeground = registerColor('textPreformat.foreground', { light: '#A31515', dark: '#D7BA7D', hcDark: '#000000', hcLight: '#FFFFFF' }, nls.localize('textPreformatForeground', "Foreground color for preformatted text segments.")); </del> <ins> export const textPreformatForeground = registerColor('textPreformat.foreground', { light: '#A31515', dark: '#D7BA7D', hcDark: '#D7BA7D', hcLight: '#292929' }, nls.localize('textPreformatForeground', "Foreground color for preformatted text segments.")); </ins> export const textPreformatBackground = registerColor('textPreformat.background', { light: '#0000001A', dark: '#FFFFFF1A', hcDark: '#FFFFFF', hcLight: '#09345f' }, nls.localize('textPreformatBackground', "Background color for preformatted text segments.")); export const textBlockQuoteBackground = registerColor('textBlockQuote.background', { light: '#f2f2f2', dark: '#222222', hcDark: null, hcLight: '#F2F2F2' }, nls.localize('textBlockQuoteBackground', "Background color for block quotes in text.")); export const textBlockQuoteBorder = registerColor('textBlockQuote.border', { light: '#007acc80', dark: '#007acc80', hcDark: Color.white, hcLight: '#292929' }, nls.localize('textBlockQuoteBorder', "Border color for block quotes in text."));

Related discussion:
text: Expected ! Actual !
Regressed in
The markdown preview in the chat is also broken for Dark Modern but is fixed by your change: !
And the markdown preview in the settings editor: !
I looked into this some more and have the following findings block rendering is broken for Dark Modern, Light Modern, Dark HC and Light HC What changed: we a new theme token, , adopted it in and , and updated the values for to look good with a different background color But we didn't adopt token for blocks in Markdown previews, which is why is broken for Markdown preview Some options Adopt for blocks in Markdown preview -- this amounts to a rather drastic styling change for Markdown previews ! Revert Revert the change to and drop the usage of so that Markdown preview, chat, and settings UI are in a reasonable state for all themes, which I attempted in
Also affects the Extensions Details page since it is a Markdown preview !
Verification: for Light/Dark Modern and Light/Dark HC, make sure that blocks are properly rendered in Markdown preview, settings UI and chat
Code change:
options = { position: TypeConverters.fromViewColumn(columnOrOptions.viewColumn), preserveFocus: columnOrOptions.preserveFocus, <ins> selection: typeof columnOrOptions.selection === 'object' ? TypeConverters.fromRange(columnOrOptions.selection) : undefined, </ins> pinned: typeof columnOrOptions.preview === 'boolean' ? !columnOrOptions.preview : undefined }; } else {

Related discussion:
text: For
Verify: write an extension that exercises the following APIs by passing in a selection as option and verify the selection is revealed and showing up in the opened editor: command API Provide a property of type to get it. !
Code change:
import { debugToolBarBackground, debugToolBarBorder } from 'vs/workbench/contrib/debug/browser/debugColors'; import { CONTINUE_ID, CONTINUE_LABEL, DISCONNECT_AND_SUSPEND_ID, DISCONNECT_AND_SUSPEND_LABEL, DISCONNECT_ID, DISCONNECT_LABEL, FOCUS_SESSION_ID, FOCUS_SESSION_LABEL, PAUSE_ID, PAUSE_LABEL, RESTART_LABEL, RESTART_SESSION_ID, REVERSE_CONTINUE_ID, STEP_BACK_ID, STEP_INTO_ID, STEP_INTO_LABEL, STEP_OUT_ID, STEP_OUT_LABEL, STEP_OVER_ID, STEP_OVER_LABEL, STOP_ID, STOP_LABEL } from 'vs/workbench/contrib/debug/browser/debugCommands'; import * as icons from 'vs/workbench/contrib/debug/browser/debugIcons'; <del> import { CONTEXT_DEBUG_STATE, CONTEXT_FOCUSED_SESSION_IS_ATTACH, CONTEXT_MULTI_SESSION_DEBUG, CONTEXT_STEP_BACK_SUPPORTED, CONTEXT_SUSPEND_DEBUGGEE_SUPPORTED, CONTEXT_TERMINATE_DEBUGGEE_SUPPORTED, IDebugConfiguration, IDebugService, State, VIEWLET_ID } from 'vs/workbench/contrib/debug/common/debug'; </del> <ins> import { CONTEXT_DEBUG_STATE, CONTEXT_FOCUSED_SESSION_IS_ATTACH, CONTEXT_IN_DEBUG_MODE, CONTEXT_MULTI_SESSION_DEBUG, CONTEXT_STEP_BACK_SUPPORTED, CONTEXT_SUSPEND_DEBUGGEE_SUPPORTED, CONTEXT_TERMINATE_DEBUGGEE_SUPPORTED, IDebugConfiguration, IDebugService, State, VIEWLET_ID } from 'vs/workbench/contrib/debug/common/debug'; </ins> import { IWorkbenchLayoutService } from 'vs/workbench/services/layout/browser/layoutService'; import { Codicon } from 'vs/base/common/codicons';

Related discussion:
text: vscode window (given you have setting to put debug controls in the command center notice how the command center includes debug controls and then right away disappear See: