jiebi/CodeConvo huggingface dataset:
Change:
public readonly onDidChange = this.onDidChangeEmitter.event; <del> // This delay fixes a suggest widget issue when typing "." immediately restarts the suggestion session. private readonly setInactiveDelayed = this._register(new RunOnceScheduler(() => { if (!this.isSuggestWidgetVisible) { if (this._isActive) { this._isActive = false; this.onDidChangeEmitter.fire(); } } }, 100)); </del> /** * Returns undefined if the suggest widget is not active. */

Discussion:
<!-- 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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.73.1 OS Version: Windows Steps to Reproduce: Have these internal settings enabled: "editor.inlineSuggest.allowQuickSuggestions": true, "editor.inlineSuggest.allowSuggestOnTriggerCharacters": true The Intellisense interaction with grey text is awesome! But I noticed some flickering. Here is the GIF. ! I grabbed screenshots to make the flickering clear: WLC prediction is in Italics ! When Intellisense is up, Intellisense text is in Italics and wlc prediction is not. ! When .is typed, there is a small latency where wlc prediction disappears. This is because . is a trigger character for Intellisense so first it will process Intellisense and then request the wlc inlineCompletionProvider. ! After that small latency, the wlc prediction shows up again in Italics ! So, the 2 main problems here are 1) When Intellisense pops up while walking the prediction, the prediction goes from Italics to non-Italics. It goes back to Italics when Intellisense is dismissed (either by manual dismissal or item committed). In VS, we keep the font for grey text the same regardless of whether Intellisense is up or not, that would be helpful in VS Code. 2) The small delay that happens when a trigger character is hit and the wlc prediction disappears and comes back again. cc
This is normal, I use Copilot and experience the same thing.

I believe this is not a bug but a slight delay in rendering.
I cannot reproduce: ! Please log all calls from VS Code into your implementation of the inline completions provider and send me that log.
Here are the logs, lmk if you need anything else.
I was able to repro the bug in code-oss. ghostText is indeed when the flickering happens. I captured a GIF of the logs so you can see at what point ghostText becomes undefined. ! Here are the logs
I was also able to repro this bug in the sample extension. I used the extension from here - !
Verified that inline completions do not flicker anymore.
Change:
this.notebookEditor.focusNotebookCell(info.cell, 'editor'); } } <ins> } else if (data.type === 'clicked-data-url') { this._onDidClickDataLink(data); </ins> } return; }

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Python Notebook implementation has special code to handle click events of links containing an ObjectUrl (href=blob:....). I'm hoping VS Code would handle this natively as these links allow users to save blobs as files. This is generic enough that it need not be something special to the Python implementation. Would benefit anyone using the new VSC API to display HTML that allows saving images. Current Python Notebook implementation: We handle all click events in document If target element === and starts with . Then we get the blob contents and send it to extension On extension side we prompt user to save the file using . /cc
what is the use case for this?
Sure, a user could render a plotly plot and such plots can contain links to save images, and those hrefs have a ref to object urls. This isn't specific to Python extension, any HTML could have markup that allows users to save images . Also, opening such a plot in other notebook viewer, user is able to click such links and save the images. If this isn't address, then VSCode displays an empty page in notebook with an error message (see below). I think this is due to the fact that href results in nativigating the current page to url=blob://. & again, we can address this with a custom renderer, however I believe this is generic enough for VSC to handle. ! !
TIL about the API. Should this also work for URLs?
Good pick. I would say yes. At the end of the day someone could render a link with a download attribute
To do this for blob ULIs, I have to download the contents of the URL in the context of the webview, and pipe it back to vscode to write to a file. Data URLs are easier, I can just open it in a browser. Maybe an experience in vscode would be nicer though. Where are these urls coming from in your case, some 3rd party renderer code or your extension code?
3rd party That's exactly what we have in our python extension when using the webview.

I thought this would be generic enough for VSCode to handle, as others could end up with similar scenarios, at the end of the day it's from a 3rd party package.
Yeah, I think it makes sense for us to handle this as well.
Do you have an example of a notebook that has this button? Is this from ipywidgets?
Also can you link me to the code that handles this in your extension?
No, its plot generated by plotly. Here's the code required to generate such a plot:
I thought this was working on Wednesday, but now I get a CORS error when I fetch any blob URL from the webview code. Did you do anything to handle this? I don't understand why it's working in your webview and not mine. Maybe we are making webview changes right now that might affect this.
U might have to setup the csp (for data and blobs), this here's what we have:
Change:
editorColumn = EditorPosition.TWO; } else if (column === <number>types.ViewColumn.Three) { editorColumn = EditorPosition.THREE; <ins> } else if (column === <number>types.ViewColumn.Active) { editorColumn = undefined; </ins> } return editorColumn; }

Discussion:
VSCode Version: Code - Insiders 1.13.0-insider (, 2017-05-26T05:14:23.944Z) OS Version: Windows_NT ia32 10.0. These 2 apis should honor the ViewColumn if specified, but if left they should default to the column of the active editor Having this will eliminate code in many extensions such as: Which fails for anything that isn't a text document (since will be missing)
Unsure what that means?
Sorry, I meant that the could be if the actual active "editor" is a non-text document (image, extension, etc). And can be for a diff editor (maybe other cases?). So an extension can't reliably get the real "active" column
+1 for not setting as default if not specified so that we prefer the currently active editor column when documents open.
PR addresses it, but it conflicts with another change see: Any thoughts on coming to a resolution on that -- I would LOVE to see this fixed.
we have an option for editors to reveal if they are open in another group (see ). I am actually surprised that was fixed and marked as important because the normal workbench behaviour is to open an editor in the currently active editor group. On top of that, the solution also does not seem right because what if I start in column 2 and I open a document in column 3 and then open the document from column 2 again. It opens in column 1?
I was surprised as well as that was my argument too :)
I could rebase that PR again (since its quite old) if you'd like, but it will still fail because of a test checking for
Well, we had this behaviour in place, extensions rely on it , and we don't want to break them. That's why this is tricky The solution is to use column 1 if not specified, no column-math happens:
Change:
compare(a: BulkEditElement, b: BulkEditElement): number { if (a instanceof FileElement && b instanceof FileElement) { <del> return compare(a.edit.uri.toString(), b.edit.uri.toString()); </del> <ins> return compareBulkFileOperations(a.edit, b.edit); </ins> } if (a instanceof TextEditElement && b instanceof TextEditElement) {

Discussion:
Testing With all the files in the multi-diff editor collapsed to make it easy to see: ! To repro, try to rename this:
I see, that's a good point thanks!
To verify: Do a rename but do not accept rename Click on The refactor preview should open Open the multi diff editor from there by clicking on any change in the refactor preveiw Check that the order of the files in the refactor preview matches the order of the files in the multi diff editor
Change:
isValid: ((value: string) => patternRegex!.test(value)), message: prop.patternErrorMessage || nls.localize('validations.regex', "Value must match regex `{0}`.", prop.pattern) }, <ins> { enabled: prop.format === 'color-hex', isValid: ((value: string) => Color.Format.CSS.parseHex(value)), message: nls.localize('validations.colorFormat', "Invalid color format. Use #RGB, #RGBA, #RRGGBB or #RRGGBBAA.") } </ins> ].filter(validation => validation.enabled); }

Discussion:
Testing The setting functions properly when I enter an invalid color: it defaults back to a red indicator. But I was thinking perhaps adding a warning message to users that they have entered an invalid color (like the warning for invalid ), and/or auto-filling the entry back to red would emphasize to them why their indicator has turned red again.
The setting is of type string, with which provides a good error message while editing the setting in the JSON file. As far as I can tell there is no way to currently get the same experience in the settings UI. I do agree that it would be nice to have a better experience for editing color settings in the settings UI. have we ever considered adding a type/validation for a setting?
We have to implement these individually and that format isn't implemented yet
It would be a feature request for the settings editor, probably easy, feel free to assign it to me
would you be opened for me to submit a pull request? I would be happy to take a stab at this in my free time to learn more about our codebase.
Sure! Here are our string validations:
Change:
resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.36.tgz#460f80829a78c979a448d5b764699af3f0366ff1" integrity sha512-sgX7OHSGZQZE5b4xtPqd/5NEcll0Z+00tnTVxKZlXf5XEENcG0tnBF4I4f+k9K3cmjE1UIUVG2yYPrqWlYCdpA== <del> xterm@4.19.0-beta.55: version "4.19.0-beta.55" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.55.tgz#b2b4acca6ef5c7a4761098b5e1629b7f93deefc9" integrity sha512-AGT7b6UYZ0o7jtyLZ8KwY8Rchdqv3Pi6Nkcs4YbxR0opbQjIovEc44jkGmudfVYcGaFWsA/bdxM6feJ7VXRAlg== </del> <ins> xterm@4.19.0-beta.56: version "4.19.0-beta.56" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.56.tgz#a3f1021b43ac04aa0c3f7b06f1b44ad34d487879" integrity sha512-kywKIK61oPjbloZI+jXY1zgjQm/ghOsFFMjb79IIMaWocUDDqdpo9MmGwziTVZYu4w/Air2Zfas9UWBu4/KEyA== </ins>

Discussion:
Testing Have the same content in the editor and in the terminal. Search for something. Notice how the occurrence are fat and visible in the editor scrollbar. Notice how they are not fat and sparse in terminal. They seem to be incorrectly placed since my match is almost on every line and that is not the feeling I get from the terminal scroll bar ! !
How many lines do you have in the editor for this example? It looks like there are a bunch of empty lines near the bottom? The way we calculate the position of terminal scroll bar decorations is line / number of lines in the buffer.
I had the same number of lines as the terminal which is 23. If I had more lines in the editor I think that would mean that the decorations are smaller in the editor, not larger and that seems to be happening :)
to me, it looks like the decorations are closer together and not taking up as much vertical space in the scrollbar see how the lower half is just empty? !
Good point. Now I have disabled scrolling beyond last line in the editor. And they render the equal height. But look at the decorations - they are very different. Do you also see this on your machine? !
The ones in the editor are double the height - likely because of device pixel ratio on a mac that's getting taken into account there and probably should be also for the terminal. ! !
Strange because we are doing the right thing here, but is 1 here for me on a mac . !
We can make these heights different based on the number of lines in the buffer similar to what the editor does
Upstream issue:
Change:
})); } <ins> private _registerSelectionChangeListener() { // When the user selects a separator, the separator will move to the top and focus will be // set to the first element after the separator. this._register(this._tree.onDidChangeSelection(e => { const elementsWithoutSeparators = e.elements.filter((e): e is QuickPickItemElement => e instanceof QuickPickItemElement); if (elementsWithoutSeparators.length !== e.elements.length) { if (e.elements.length === 1 && e.elements[0] instanceof QuickPickSeparatorElement) { this._tree.setFocus([e.elements[0].children[0]]); this._tree.reveal(e.elements[0], 0); } this._tree.setSelection(elementsWithoutSeparators); } })); } </ins> //#endregion //#region public methods

Discussion:
! I can click on them
Took a different approach with this... instead they are clickable, but they cause the list to scroll that separator up to the top (and they also clear focus).
Fixed in
Change:
this.editorInput.selectedCategory = categoryID; this.editorInput.selectedStep = stepId; this.currentWalkthrough = ourCategory; <del> this.buildCategorySlide(categoryID); </del> <ins> this.buildCategorySlide(categoryID, stepId); </ins> this.setSlide('details'); }); }

Discussion:
<!-- 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?: No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.85.2 OS Version: MacOS ventura 13.4.1 According to it appears that I should be able to execute the command: or This should open up a specific step of my extension's walkthrough. However whenever I include my I am getting this error when executing the command: <img width="1050" alt="image" src=""As a side note, not including a step id is working just fine, however I would like to be able to open a specific step for this case.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I don't believe we ever supported this args format for opening a walkthrough step. You can try this instead: vscode.commands.executeCommand('', { category: 'extensionId#walkthroughId', step: 'stepId' }, false);
Tried this and it will open the walkthrough, however it will not open the step that is specified.
Could you please share the code snippet you used to execute this command?
here it is! (sorry for the delay) EDIT: this may be related or not but throughout tesing with this snippet I somehow managed to get two welcome pages at once in the editor <img width="264" alt="image" src=""
vscode.commands.executeCommand('', , false);
! !
Change:
}; const disposableStore = new DisposableStore(); disposableStore.add(this._editorWidget.onKeyDown((e) => { <del> if (e.keyCode === KeyCode.Escape || shouldHide(e.browserEvent, this._keybindingService)) { </del> <ins> if (e.keyCode === KeyCode.Escape || shouldHide(e.browserEvent, this._keybindingService, this._configurationService)) { </ins> hide(e); } else if (e.keyCode === KeyCode.KeyH && provider.options.readMoreUrl) { const url: string = provider.options.readMoreUrl!;

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --In previous versions, with the use of and the extension, I could easily select and copy terminal output content in the "Accessible View" via Vi mode. However, in the update, I noticed a change that "The Accessible View now closes when a user starts typing and focuses the prior element for a smoother work flow.". This change prevents me from using Vi mode to select content in the "Accessible View." Could you please consider providing an option that allows users to choose whether or not this feature is enabled? Alternatively, are there any other solutions to this issue?
Related to
can you take a look at this one? Thanks!
To verify, disable and make sure the view does not close on key press.
Fixed now! Thanks for the quick resolution!
Change:
return this._themeService.getColorTheme().semanticHighlighting; } <del> private _compute(grammar: IGrammar | null, semanticTokens: SemanticTokensResult | null, position: Position): string { </del> <ins> private _compute(grammar: IGrammar | null, semanticTokens: SemanticTokensResult | null, position: Position) { </ins> const textMateTokenInfo = grammar && this._getTokensAtPosition(grammar, position); const semanticTokenInfo = semanticTokens && this._getSemanticTokenAtPosition(semanticTokens, position); if (!textMateTokenInfo && !semanticTokenInfo) { <del> return 'No grammar or semantic tokens available.'; </del> <ins> dom.reset(this._domNode, 'No grammar or semantic tokens available.'); return; </ins> } let tmMetadata = textMateTokenInfo?.metadata;

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The next step in resolving . Simirarly to , it aims to replace construction of HTML elements by string concatenation in file. The code contains mainly a table construction by concatenating strings of . The goal is to replace them all with function calls.
I verified by running the monaco editor from source and testing the inspect token hover
To verify, open the hover and verify it looks all proper.
Change:
import { SpectronApplication } from '../../spectron/application'; <del> export class Terminal { static TERMINAL_SELECTOR = '.panel.integrated-terminal'; static TERMINAL_ROWS_SELECTOR = `${Terminal.TERMINAL_SELECTOR} .xterm-rows > div`; static TERMINAL_CURSOR = `${Terminal.TERMINAL_SELECTOR} .terminal-cursor`; </del> <ins> const PANEL_SELECTOR = 'div[id="workbench.panel.terminal"]'; const XTERM_SELECTOR = `${PANEL_SELECTOR} .terminal-wrapper`; export class Terminal { </ins> constructor(private spectron: SpectronApplication) { } public async showTerminal(): Promise<void> { if (!await this.isVisible()) { await this.spectron.workbench.quickopen.runCommand('View: Toggle Integrated Terminal'); <del> await this.spectron.client.waitForElement(Terminal.TERMINAL_CURSOR); </del> <ins> await this.spectron.client.waitForElement(XTERM_SELECTOR); </ins> await this.waitForTerminalText(text => text.length > 0, 'Waiting for Terminal to be ready'); } } public async isVisible(): Promise<boolean> { <del> const element = await this.spectron.client.element(Terminal.TERMINAL_SELECTOR); </del> <ins> const element = await this.spectron.client.element(PANEL_SELECTOR); </ins> return !!element; }

Discussion:
FYI I commented out the test. Please fix it and enable it.
The test is failing because the DOM is no longer filled with nodes so these tests can't work the way they did previously. Is it possible with Spectron to pull a DOM node object, including any custom properties it has? If so I could attach a reference to the object to the terminal element which would allow querying the terminal for this sort of information really easily.
Yes, you can access the DOM in Spectron and we do it in multiple places. For example refer to . This will allow you to execute java script code on the renderer process that has access to DOM and let you return the model you want. But please be aware that, Since it runs in a different process than the test process, console log does not work.
PR with fix is out , will merge in after release is branched off.
Change:
this.focusedMenu = { index: menuIndex }; this.focusState = MenubarState.OPEN; } <ins> e.preventDefault(); e.stopPropagation(); </ins> }); this.customMenus[menuIndex].buttonElement.on(EventType.MOUSE_ENTER, () => {

Discussion:
Issue Type: <bBug</bWhen using the custom title bar and the toggled menu bar setting, the menu bar becomes stuck in the toggled on state. This primarily occurs when the active VS Code window becomes inactive while the menu bar is toggled on. When using multiple VS Code windows this makes it difficult to identify the correct window because the title bar's filename information is hidden. Steps to reproduce: the setting to , and setting to VS Code is the active window, hold down the key to show the menu bar the key while still holding the key to switch to another application. The active VS Code window becomes inactive and the menu bar is visible. Alternatively you can click outside of the active VS Code window while the menu bar is being displayed. VS Code version: Code 1.25.0 (, 2018-07-05T13:11:58.697Z) OS version: Windows_NT x64 10.0. <details<summaryExtensions (4)</summaryExtensionVersion ------ classic-asp0.0.4 vscode-icon-theme1.6.2 csharp1.15.2 PowerShell1.8.0 </details<!-- 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.538 --- <!-- score: 0.491 --- <!-- score: 0.483 --- <!-- score: 0.482 --- <!-- score: 0.48 --<!-- potentialduplicatescomment --
Change:
buttons: [{ label: localize('install anyway', "Install Anyway"), run: () => { <del> const installAction = this.installOptions?.isMachineScoped ? this.instantiationService.createInstance(InstallAction, { donotVerifySignature: true }) : this.instantiationService.createInstance(InstallAndSyncAction, { donotVerifySignature: true }); </del> <ins> const installAction = this.instantiationService.createInstance(InstallAction, { donotVerifySignature: true }); </ins> installAction.extension = this.extension; return installAction.run(); }

Discussion:
Look at telemetry and if not a lot of users are using the Install and Do not Sync extension action remove the action to simplify the Extension Install flow. is the action name. fyi
Ok was run on 59K distinct machines. For comparison extensionGallery:install was executed on 10.4M machines. So Do not Sync is used in 0.5% of cases. I think it is fine if we remove it - we keep it somewhere but not so prominent. what do you think?
Any suggestions?
We already have the "Sync Extension" check in the Extension context menu when it is installed - this is great. ! And we already have the "Sync Extension" check in the same context menu when it is not installed. Just currently if I click this, there is no effect. So ideally the experience would be that I can uncheck this before installing the extension. And thus we need no new actions. !
Lets try this in insiders already and see if we get any hit back.
Awesome - thanks!