jiebi/CodeConvo huggingface dataset:
Code change:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

Related discussion:
text: this._hover.contentsDomNode.style.paddingBottom = ''; this._updateFont(); <del> this._editor.layoutContentWidget(this); </del> this.onContentsChanged(); // Simply force a synchronous render on the editor
Code change:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

Related discussion:
text: // See https://github.com/microsoft/vscode/issues/140339 // TODO: Doing a second layout of the hover after force rendering the editor <del> this._editor.layoutContentWidget(this); </del> this.onContentsChanged(); if (visibleData.stoleFocus) {
Code change:
! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at

Related discussion:
text: } public onContentsChanged(): void { <ins> this._editor.layoutContentWidget(this); </ins> this._hover.onContentsChanged(); const scrollDimensions = this._hover.scrollbar.getScrollDimensions();
Code change:
While verifying I noticed that if I click on the warning I'm not taken to the size limit setting which I would've expected to be taken to. ! Version: 1.68.0-insider (Universal) Commit: Date: 2022-06-02T05:16:30.515Z Electron: 17.4.6 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0 Jupyter Extension version (available under the Extensions sidebar): v2022.5. Python Extension version (available under the Extensions sidebar): v2022.7.
This link is specified in core code.
The issue doesn't seem to be fixed in the latest insiders. Reopening
The issue is now fixed for me in the latest Insiders, at least on Windows 11.

Related discussion:
text: first.textContent = 'Output exceeds the '; const second = document.createElement('a'); second.textContent = 'size limit'; <del> second.href = `command:workbench.action.openSettings?["notebook.output.textLineLimit"]`; </del> <ins> second.href = `command:workbench.action.openSettings?%5B%22notebook.output.textLineLimit%22%5D`; </ins> const third = document.createElement('span'); third.textContent = '. Open the full output data'; const forth = document.createElement('a');
Code change:
Open the color theme picker and select the first option () Observe that it takes around 5 seconds for the results to show. This used to be much snappier

Related discussion:
text: try { const installedExtensions = await this._installedExtensions; <del> const options = { text: `${this.marketplaceQuery} ${value}`, pageSize: 40 }; </del> <ins> const options = { text: `${this.marketplaceQuery} ${value}`, pageSize: 20 }; </ins> const pager = await this.extensionGalleryService.query(options, token); <del> for (let i = 0; i < pager.total && i < 1; i++) { </del> <ins> for (let i = 0; i < pager.total && i < 1; i++) { // loading multiple pages is turned of for now to avoid flickering </ins> if (token.isCancellationRequested) { break; } const nThemes = this._marketplaceThemes.length; <ins> const gallery = i === 0 ? pager.firstPage : await pager.getPage(i, token); </ins> <del> const gallery = await pager.getPage(i, token); </del> <ins> const promises: Promise<IWorkbenchTheme[]>[] = []; const promisesGalleries = []; </ins> for (let i = 0; i < gallery.length; i++) { if (token.isCancellationRequested) { break;
Code change:
Open the color theme picker and select the first option () Observe that it takes around 5 seconds for the results to show. This used to be much snappier

Related discussion:
text: const ext = gallery[i]; if (!installedExtensions.has(ext.identifier.id) && !this._marketplaceExtensions.has(ext.identifier.id)) { this._marketplaceExtensions.add(ext.identifier.id); <del> const themes = await this.getMarketplaceColorThemes(ext.publisher, ext.name, ext.version); for (const theme of themes) { this._marketplaceThemes.push({ id: theme.id, theme: theme, label: theme.label, description: `${ext.displayName} · ${ext.publisherDisplayName}`, galleryExtension: ext, buttons: [configureButton] }); } </del> <ins> promises.push(this.getMarketplaceColorThemes(ext.publisher, ext.name, ext.version)); promisesGalleries.push(ext); } } const allThemes = await Promise.all(promises); for (let i = 0; i < allThemes.length; i++) { const ext = promisesGalleries[i]; for (const theme of allThemes[i]) { this._marketplaceThemes.push({ id: theme.id, theme: theme, label: theme.label, description: `${ext.displayName} · ${ext.publisherDisplayName}`, galleryExtension: ext, buttons: [configureButton] }); </ins> } } if (nThemes !== this._marketplaceThemes.length) { this._marketplaceThemes.sort((t1, t2) => t1.label.localeCompare(t2.label)); this._onDidChange.fire();
Code change:
!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal

Related discussion:
text: this.clearDecorations(); } <ins> private _clearPlaceholder(): void { this._placeholderDecoration?.dispose(); this._placeholderDecoration = undefined; } </ins> public clearDecorations(): void { <del> if (this._placeholderDecoration) { this._placeholderDecoration.marker.dispose(); this._placeholderDecoration.dispose(); this._placeholderDecoration = undefined; } </del> <ins> this._placeholderDecoration?.marker.dispose(); this._clearPlaceholder(); </ins> for (const value of this._decorations.values()) { value.decoration.dispose(); dispose(value.disposables);
Code change:
!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal

Related discussion:
text: } })); // Current command invalidated <del> this._commandDetectionListeners.push(capability.onCurrentCommandInvalidated(() => { this._placeholderDecoration?.dispose(); this._placeholderDecoration = undefined; })); </del> <ins> this._commandDetectionListeners.push(capability.onCurrentCommandInvalidated(() => this._clearPlaceholder())); </ins> } activate(terminal: Terminal): void {
Code change:
!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal

Related discussion:
text: throw new Error(`cannot add a decoration for a command ${JSON.stringify(command)} with no marker`); } <del> this._placeholderDecoration?.dispose(); </del> <ins> this._clearPlaceholder(); </ins> let color = command.exitCode === undefined ? defaultColor : command.exitCode ? errorColor : successColor; if (color && typeof color !== 'string') { color = color.toString();
Code change:
!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal

Related discussion:
text: } if (beforeCommandExecution && !this._placeholderDecoration) { this._placeholderDecoration = decoration; <del> this._placeholderDecoration.onDispose(() => this._placeholderDecoration = undefined); </del> } else if (!this._decorations.get(decoration.marker.id)) { decoration.onDispose(() => this._decorations.delete(decoration.marker.id)); this._decorations.set(decoration.marker.id,
Code change:
!
This happens because command executed happens but not command finished
And that's because of this:
nice, the fix works https://user-

Related discussion:
text: builtin printf "033]633;D;%s007" "$__vsc_status" __vsc_last_history_id=$__vsc_history_id fi <ins> else builtin printf "033]633;D007" </ins> fi __vsc_update_cwd }
Code change:
If a password is not decrypted properly, then it should be removed from the secret storage because it's essentially dead. Originally posted by in
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Verification steps: grab and install in VS Code Insiders Run command Follow the notifications ping me if you have any questions or issues.

Related discussion:
text: if (value.extensionId === extensionId) { return value.content; } <del> } catch (e) { this.logService.error(e); throw new Error('Cannot get password'); </del> <ins> } catch (parseError) { this.logService.error(parseError); // If we can't parse the decrypted value, then it's not a valid secret so we should try to delete it try { await this.credentialsService.deletePassword(fullKey, key); } catch (e) { this.logService.error(e); } throw new Error('Unable to parse decrypted password'); </ins> } }
Code change:
Issue Type: <bPerformance Issue</bTerminals doesn't seem to free all GPU memory when closing them, making alt-tabbing from another application to vscode slower over time, there are other tickets around vscode freezing when alt-tabbing back to it and this seems to be one of the reasons as Windows needs to load/unload 1GB+ of GPU memory when alt-tabbing occurs. One way of reproducing this: 20 integrated terminals the terminals again (now only welcome screen open) Windows task manager -Performance tab something covers vscode completely (i.e. task manager is maximized) the GPU memory usage is 500MB+ lower than if vscode is visible (i.e. task manager is not maximized so it doesn't cover vscode completely, forcing Windows to keep vscode GPU memory active). scales linearly if you open more terminals, i.e. 40 terminals keeps 1GB+ of GPU memory even when they are closed I can reproduce it on the insiders build as well, so Electron 18 doesn't seem to solve this issue. vscode visible (2 GB GPU memory usage at the bottom of the screenshot): ! vscode still open but behind other windows (1 GB GPU memory usage at the bottom of the screenshot): ! VS Code version: Code 1.68.1 (, 2022-06-14T12:48:58.283Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
I tried to repro with stable, but I wasn't able to. What are the steps for verification?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Hello, I'm waiting for these to cleanup the terminals properly: But as I am the author of those PRs I don't think additional verification is needed from me once they get merged.
fyi I think I noticed a few bugs about alt-tabbing being slow

Related discussion:
text: "vscode-proxy-agent": "^0.12.0", "vscode-regexpp": "^3.1.0", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0", "xterm-addon-search": "0.9.0", "xterm-addon-serialize": "0.7.0", </del> <ins> "xterm": "4.20.0-beta.5", "xterm-addon-search": "0.10.0-beta.1", "xterm-addon-serialize": "0.8.0-beta.1", </ins> "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0", "xterm-headless": "4.19.0", </del> <ins> "xterm-addon-webgl": "0.13.0-beta.2", "xterm-headless": "4.20.0-beta.5", </ins> "yauzl": "^2.9.2", "yazl": "^2.4.3" },
Code change:
Issue Type: <bPerformance Issue</bTerminals doesn't seem to free all GPU memory when closing them, making alt-tabbing from another application to vscode slower over time, there are other tickets around vscode freezing when alt-tabbing back to it and this seems to be one of the reasons as Windows needs to load/unload 1GB+ of GPU memory when alt-tabbing occurs. One way of reproducing this: 20 integrated terminals the terminals again (now only welcome screen open) Windows task manager -Performance tab something covers vscode completely (i.e. task manager is maximized) the GPU memory usage is 500MB+ lower than if vscode is visible (i.e. task manager is not maximized so it doesn't cover vscode completely, forcing Windows to keep vscode GPU memory active). scales linearly if you open more terminals, i.e. 40 terminals keeps 1GB+ of GPU memory even when they are closed I can reproduce it on the insiders build as well, so Electron 18 doesn't seem to solve this issue. vscode visible (2 GB GPU memory usage at the bottom of the screenshot): ! vscode still open but behind other windows (1 GB GPU memory usage at the bottom of the screenshot): ! VS Code version: Code 1.68.1 (, 2022-06-14T12:48:58.283Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
I tried to repro with stable, but I wasn't able to. What are the steps for verification?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Hello, I'm waiting for these to cleanup the terminals properly: But as I am the author of those PRs I don't think additional verification is needed from me once they get merged.
fyi I think I noticed a few bugs about alt-tabbing being slow

Related discussion:
text: "tas-client-umd": "0.1.6", "vscode-oniguruma": "1.6.1", "vscode-textmate": "7.0.1", <del> "xterm": "4.19.0", "xterm-addon-search": "0.9.0", </del> <ins> "xterm": "4.20.0-beta.5", "xterm-addon-search": "0.10.0-beta.1", </ins> "xterm-addon-unicode11": "0.4.0-beta.3", <del> "xterm-addon-webgl": "0.12.0" </del> <ins> "xterm-addon-webgl": "0.13.0-beta.2" </ins> } }
Code change:
Previously the terminal could be resized fairly quickly, to see what's going on and then hide it again (with 2 lines still visible). With the new update however, it can only be resized by one line per keystroke. So in order to use the terminal adequately, there are 10 - 20 keystrokes required, which is unacceptable (in my opinion). It would be great, if you could specify "args" for the command which control how many lines the terminal is resized by. Similar like the cursorMove command: Thanks for consideration, Floyd Haremsa <!-- 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. -→
I'm not sure what you mean. changing the height of the panel? https://user-
Yes, changing the height of the panel, but with keyboard shortcuts. Previously it worked pretty well (changing the height by lets say 10 lines, I don't quite remember). But now you can only resize by one line at a time (per hitting the keyboard shortcut), like this: https://user- and that is just way too slow and inefficient. This way I'm forced to resize it with the mouse (which is also too slow) or having it open all the time, which is bad on small screen sizes. Sorry for not having it clarified enough earlier.
we think this is related to the increase view size change - thoughts ?
This is indeed caused by The new behavior is actually the intended behavior, but the terminal is in full control if it wants to have a number-of-lines-based resize setting.
I am also affected by this and it is crazy to work mouseless, resizing terminal is not viable with keyboard like this. Any work around?
how many rows would you expect it to change?
3-4 would be nice
I'd say about 7 - 10 lines at a time. But if I can control it my self, that's even better.
Also being affected by this. The terminal now resizes by 1 line at a time. Previously it was 9 lines (3072×1920 on 16" with terminal.integrated.fontSize = 13) Something in the range of 4-8 lines might be a decent compromise considering the original request that led to the change ()
I think the best approach would be to just have a default of let's say 4 lines, but also a setting that controls this, and/or as I mentioned, arguments to the command for being able to map multiple resize settings to different shortcuts:
I'd rather not add a setting for this as it's pretty obscure and would see hardly any usage. An additional complication here is I'd like to eventually remove the terminal resize commands since we now have the increase/decrease view size commands which weren't around when the terminal resize pane commands got . Seems like 4 rows should work for most people.
Can confirm this is fixed in Insiders. Thanks for the quick response

Related discussion:
text: } class SplitPane implements IView { <del> minimumSize: number = SPLIT_PANE_MIN_SIZE; </del> <ins> minimumSize: number = Constants.SplitPaneMinSize; </ins> maximumSize: number = Number.MAX_VALUE; orientation: Orientation | undefined;
Code change:
<!-- 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. --Executing "Surround with snippet" from the command palette while there's no surround-able snippet, results in an empty pick list: ! Shouldn't it be like showing an information message saying there's no snippet to pick, or just not prompting the user to pick anything?
Prompt might be too annoying but quick pick itself might have a way to show a lightweight in-place message
Do you mean something like this (using )? !
Just submitted the PR. Could you please check it?

Related discussion:
text: picker.items = makeSnippetPicks(); }); picker.items = makeSnippetPicks(); <ins> if (!picker.items.length) { picker.validationMessage = nls.localize('pick.noSnippetAvailable', "No snippet available"); } </ins> picker.show(); // wait for an item to be picked or the picker to become hidden
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 * as vscode from 'vscode'; /** <del> * This interface describes the shape for the references viewlet API. It consists * of a single `setInput` function which must be called with a full implementation </del> <ins> * This interface describes the shape for the references viewlet API. It consists * of a single `setInput` function which must be called with a full implementation </ins> * of the `SymbolTreeInput`-interface. To acquire this API use the default mechanics, e.g: <del> * </del> <ins> * </ins> * ```ts * // get references viewlet API <del> * const api = await vscode.extensions.getExtension<SymbolTree>('ms-vscode.references-view').activate(); * </del> <ins> * const api = await vscode.extensions.getExtension<SymbolTree>('vscode.references-view').activate(); * </ins> * // instantiate and set input which updates the view * const myInput: SymbolTreeInput<MyItems> = ... * api.setInput(myInput)
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: export interface SymbolTree { /** <del> * Set the contents of the references viewlet. * </del> <ins> * Set the contents of the references viewlet. * </ins> * @param input A symbol tree input object */ setInput(input: SymbolTreeInput<unknown>): void;