jiebi/CodeConvo huggingface dataset:
Code change:
URL:      https://code.visualstudio.com/ Icon:     @@NAME@@.xpm Requires: glibc >= 2.15 <ins> Requires: GConf2 </ins> %ifarch x86_64 Requires: libXss.so.1()(64bit) %else

Related discussion:
text: VSCode Version: code-insiders-1.8.0-.el7.x86_64 OS Version: CentOS Linux release 7.2.1511 (Core) Steps to Reproduce: code rpm from insiders build on CentOS minimal to launch it from cli Installing GConf2 fixes it ( yum install GConf2 ). maybe should be a dep in the rpm spec file.
hello would love more information on the minimal install aspect for your use case. To clarify, are you starting with a "minimal installation" and then installing x11 after the fact ? !
Yes, and after that I just install the basic fonts and xorg xauth because I ssh into the devel box and use the editor via X11 forwarding. I've done this with other editors and is pretty handy, so I can avoid copying/checking out code from the workstation to the devel box (I write stuff meant to run over CentOS 7)
The exact same problem occurs on Elementary OS (based on Ubuntu). Running fixes the issue. It's most likely the same missing dependency problem in the .Deb file.
this should be fixed in 1.9
Hello, I had the same problem on openSUSE 42.1, when I ran the problem was solved. Btw I downloaded the .rpm file.
On ArchLinux pacman -S gconf
Code change:
return; } <del> const options = { findNext: true, forward: !previous }; </del> <ins> const options = { findNext: false, forward: !previous }; </ins> if (!this._findStarted) { this.startFind(value, options); return;

Related discussion:
text: Issue Type: <bBug</bOpen a Webview (for example: Help -Release Note) and start the search (Ctrl+F) and write the search term (for example: "Update") Only "u" (first letter) is selected on the view and not the current tipped search term. ! Notice: If i pressed "enter" then the full term is selected on the view. This behavier was other in the previous version (1.52.1) VS Code version: Code 1.54.3 (, 2021-03-15T10:55:45.459Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (31)</summaryExtensionVersion ------ mock-debug0.45.4 cortex-vsc2.1.0 npm-intellisense1.3.1 vscode-markdownlint0.40.1 jshint0.11.0 vscode-eslint2.1.19 vscode-npm-script0.3.18 vscode-firefox-debug2.9.2 auto-close-tag0.5.10 code-runner0.11.3 vscode-test-explorer2.19.6 code-coverage1.2.3 vscode-docker1.11.0 csharp1.23.9 python2021.3. vscode-pylance2021.3.3 jupyter2021.3. cpptools1.2.2 powershell2021.2.2 debugger-for-chrome4.12.12 vetur0.33.1 java0.76.0 vscode-xml0.15.0 vscode-yaml0.17.0 markdown-preview-enhanced0.5.17 vscodeintellicode1.2.12 vscode-java-debug0.32.1 vscode-java-dependency0.18.2 vscode-java-pack0.13.0 vscode-java-test0.28.1 vscode-maven0.28.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.526 --<!-- potentialduplicatescomment --
The search behaviour changed between Electron 9.3.5 and Electron 11.4.1. The parameter should now be whenever we're doing a search for the first time.
Code change:
markdownIt.linkify.set({ fuzzyLink: false }); addNamedHeaderRendering(markdownIt); <ins> addLinkRenderer(markdownIt); </ins> const style = document.createElement('style'); style.textContent = `

Related discussion:
text: [X] Notebooks (.ipynb files) [ ] Interactive Window and/or Cell Scripts (.py files with #%% markers) Hello. As the title says, I can't make a internal link in a jupyter notebook in vscode if the cell's title starts with a capital letter, contains an underscore or contains a space, as you can see on the images. Also, on the sole option that it works, non-capital letter header, when clicked it brings me to the bottom of the notebook, and the focus is not brought on the right header itself. Initial tests: ! The test headers: ! 64.5 v2022.2. Python v3.8.5 Python Extension: v2022.2. No response Local
This is actually handled by VS code core (and not the extension). I've included a demo notebook that repros the problem .
In the demo notebook, the href jumps all work ! But none of the header jumps do unless you rewrite them to be only lowercase. All of the links work fine when running in 'jupyter'.
Vscode this notebook is still with all the bugs. Even on the links that work, they jump me to the very bottom of the notebook, not to cell 2, cell 3 or cell 4. Also Section jump and Section with space jump still doesn't work at all. I'm using portable Vscode btw, but I think this doesn't make any difference since when I was using the regular one this bug still existed. Even now, about 2 years later (that I recall) it still goes on on notebooks in Vscode. I can record a GIF if you need. I assure no weird magic was done on my vscode, just regular installation and all... and I can confirm that this issue still occurred years ago on my other PC too.
Does this reproduce in the ?
It did for me.
Will this issue be addressed on any new version of Vscode? I've headed to version 1.67 and to "April+2022+Recovery+2"+is%3Aclosed and found no mentions of this issue. Perhaps on the next, if it would be implemented/fixed at all? Thanks anyway! :)
This issue was fixed in 1.68 (the May 2022 milestone)
got a look at and pull request ( ) doesn't appear there.
Code change:
markdownIt.linkify.set({ fuzzyLink: false }); addNamedHeaderRendering(markdownIt); <ins> addLinkRenderer(markdownIt); </ins> const style = document.createElement('style'); style.textContent = `

Related discussion:
text: Will it be ? Thanks :)
Did you test it?
Yes! everything was fixed. Capital letters, underscore and space headers now work like a charm. I was just asking if this specific commit ( ) will be listed on the update website. I don't know how it works, if minor fixes won't get listed or something like that. I just wanted to show to some friends that somehow I've contributed to Vscode with my bug report Anyway, everything buggy was fixed. This issue may be closed anytime.
Code change:
private _shadowElement?: HTMLElement; private _shadowElementViewInfo: { height: number; width: number; top: number; left: number } | null = null; <del> private _listStyleOverride = { listBackground: notebookEditorBackground, listActiveSelectionBackground: notebookEditorBackground, listActiveSelectionForeground: foreground, listFocusAndSelectionBackground: notebookEditorBackground, listFocusAndSelectionForeground: foreground, listFocusBackground: notebookEditorBackground, listFocusForeground: foreground, listHoverForeground: foreground, listHoverBackground: notebookEditorBackground, listHoverOutline: focusBorder, listFocusOutline: focusBorder, listInactiveSelectionBackground: notebookEditorBackground, listInactiveSelectionForeground: foreground, listInactiveFocusBackground: notebookEditorBackground, listInactiveFocusOutline: notebookEditorBackground, }; </del> private readonly _editorFocus: IContextKey<boolean>; private readonly _outputFocus: IContextKey<boolean>; private readonly _editorEditable: IContextKey<boolean>;

Related discussion:
text: I opened the Settings editor, hovered over a setting, and noticed a new grey line appear to the left of the settings. This issue occurs with the default light and dark themes. !
I found that when calling , if we don't pass in the style override anymore, it will be reset to default I put this fix for notebook but I wonder if it's unexpected
Thanks for figuring that out. We shouldn't update options that are not set, that a regression. I fixed that with and updated your code to back what it was. Is different, it's about the indent guides which were disabled previously by not providing any colors. With my change we complete your colors with the default colors, which IMO is the right thing to do. is a simple fix. But I think we should not use the colors for that but the already existing option. I'm working on a follow up PR, but that needs to be reviewed by who is out today.
Code change:
@ITextFileService private readonly textFileService: ITextFileService, @IStatusbarService private readonly statusbarService: IStatusbarService, @IInstantiationService private readonly instantiationService: IInstantiationService, <del> @IContextKeyService private readonly contextKeyService: IContextKeyService </del> <ins> @IContextKeyService private readonly contextKeyService: IContextKeyService, @IConfigurationService private readonly configurationService: IConfigurationService </ins> ) { super();

Related discussion:
text: Testing an editor and write something in it. tab until you reach the terminal. Type something in the terminal. . Realize that tab is correctly not moving focus in the terminal. command "Toggle Tab Key Moves Focus" out of the terminal and keep tabbing until you get back to your editor. something in the editor. again until you reach the terminal. something in the terminal. to tab out of the terminal. It looks like tab moves focus as toggled itself off. Tab moves focus seems to be off for both terminal and editor at this point until reload.
I can also cause similar behavior if I flip the settings.
what is supposed to happen now? What I think I expect to happen (and isn't happening): If I run "Toggle tab key moves focus" while in a place where it doesn't move focus via setting, then it now globally moves focus. If I run "Toggle tab key moves focus" while in a place where it does move focus, then it now globally does not move focus. However, I'm not a "tab moves focus" user, so maybe my expectations are bogus.
Thank you for testing. Those expectations are correct, except that the toggling does not apply globally - it is per area. So, if I have in settings: terminal tab focus mode: on editor tab focus mode: off where: = status bar indicator = no status bar indicator focus the terminal focus the editor focus the terminal and toggle it off focus the editor and toggle it on focus the terminal focus the editor reload the window and focus the terminal focus the editor I see that this is not working atm because I'm not reacting to configuration changes
fyi for easier testing since the command palette can cause the terminal to no longer be focused, I'd suggest using the keybinding to toggle tab focus mode
Code change:
if (command && this._currentStickyCommand !== command) { this._throttledRefresh(); } else { <del> this._debouncedRefresh(); </del> <ins> // If it's the same command, do not throttle as the sticky scroll overlay height may // need to be adjusted. This would cause a flicker if throttled. this._refreshNow(); </ins> } } <del> @debounce(20) private _debouncedRefresh(): void { this._throttledRefresh(); } </del> @throttle(0) private _throttledRefresh(): void { <ins> this._refreshNow(); } private _refreshNow(): void { </ins> const command = this._commandDetection.getCommandForLine(this._xterm.raw.buffer.active.viewportY); // The command from viewportY + 1 is used because this one will not be obscured by sticky

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:
import { ExplorerViewPaneContainer } from 'vs/workbench/contrib/files/browser/explorerViewlet'; import { onUnexpectedError } from 'vs/base/common/errors'; import { category, getElementsToOperateOn, getSearchView, openSearchView } from 'vs/workbench/contrib/search/browser/searchActionsBase'; <ins> import { withNullAsUndefined } from 'vs/base/common/types'; import { IConfigurationResolverService } from 'vs/workbench/services/configurationResolver/common/configurationResolver'; import { IHistoryService } from 'vs/workbench/services/history/common/history'; import { Schemas } from 'vs/base/common/network'; </ins> //#region Interfaces

Related discussion:
text: I try to add a keybinding with ${selectedText}. but it will resloved as a normal string. Steps to Reproduce: ! Version: 1.75.0 (user setup) Commit: OS: Windows_NT x64 10.0. Sandboxed: No
would you happen to know why the variable isn't resolving to a value here? Is there something that the command must contain to resolve variables?
The decision for whether variables should be resolved in a command needs to be made on a per command bases. If you want, you can run your commands arguments through the variable resolve when your command is called. For example, the terminal uses the variable resolver here:
From It would be great if more variable resolution was achieved in keybindings - I think it has been requested many times.
verif steps: a keybinding for : that the keybinding correctly sets to the current path.
Code change:
export interface MainThreadDocumentContentProvidersShape extends IDisposable { $registerTextContentProvider(handle: number, scheme: string): void; $unregisterTextContentProvider(handle: number): void; <del> $onVirtualDocumentChange(uri: UriComponents, value: string): void; </del> <ins> $onVirtualDocumentChange(uri: UriComponents, value: string): Promise<void>; </ins> } export interface MainThreadDocumentsShape extends IDisposable {

Related discussion:
text: Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.2 OS Version: Windows 10 It seems that when refreshing () the in a short period, the second refresh is not actually performed. I have provided an example repo and a video demonstrating the issue. Basically we have a that shadows the active editor so whenever a user changes the active editor we update the read only document. However, if the user changes the editors quickly enough then the second change is dropped... Steps to Reproduce: the extension the command "Open Read Only Document" tabs quickly and see how it falls behind even though the content is up to date https://user- The content is actually set but it seems the second is dropped. Because if you refresh the document manually it shows the correct content (see the video above). The issue seems to happen more frequently if the content of the file(s) is large.
I found out why it happens and attempted a fix (with explanation) in
Pinging so it does not get lost
Code change:
document: vscode.TextDocument, webview: vscode.WebviewPanel ): Promise<void> { <del> const lineNumber = this._topmostLineMonitor.getPreviousEditorLineByUri(document.uri); </del> <ins> const lineNumber = this._topmostLineMonitor.getPreviousTextEditorLineByUri(document.uri); </ins> const preview = StaticMarkdownPreview.revive( document.uri, webview,

Related discussion:
text: Issue Type: <bBug</bI have been using for a long time. Currently I end up with a LOT of inadvertant selections when working in two side-by-side editor groups and switching back and forth between them using the mouse. The reason is that the editor scrolls 5 lines every time I click into it. VS Code version: Code - Insiders 1.58.0-insider (, 2021-06-11T05:22:19.992Z) OS version: Darwin arm64 20.5.0 Restricted Mode: No Remote OS version: Linux x64 5.4.0-1046-azure <!-- generated by issue reporter --
I cannot reproduce. Does this reproduce for you when disabling all extensions? (The editor exposes a API to extensions). I have recently also got which seems incredibly similar, but I am having a hard time reproducing any of the jumping that is described. Here I am trying two side-by-side editor groups: https://user-
This reproduces only when the language mode of the files are set to markdown. I think this has to do with how the markdown extension is using the vscode API. But I think it should not use that API at all if no markdown preview is rendered. But it would also be interesting to test what the experience is when the preview is rendered. Given this doesn't reproduce with txt files, I'm optimistically giving this to you. Steps to reproduce: define open two md files side-by-side (preferably without word wrapping to see the top line number change) click on the editor tab of each one on every click, the editor scrolls up by 5 lines https://user-
Could you please take a look at this since you were looking into markdown syncing last iteration?
It seems like it's a bug coming from the scroll syncing between the static and text editor changes that I made a while ago. I'll try to make a PR to fix this soon.
Code change:
this.onTabFocusModeChange(); } })); <ins> this._register(this.configurationService.onDidChangeConfiguration(e => { if (e.affectsConfiguration('editor.tabFocusMode')) { TabFocus.setTabFocusMode(this.configurationService.getValue('editor.tabFocusMode'), TabFocusContext.Editor); this.onTabFocusModeChange(); } else if (e.affectsConfiguration(TerminalSettingId.TabFocusMode)) { TabFocus.setTabFocusMode(this.configurationService.getValue(TerminalSettingId.TabFocusMode), TabFocusContext.Terminal); this.onTabFocusModeChange(); } })); </ins> } private registerCommands(): void {

Related discussion:
text: Testing an editor and write something in it. tab until you reach the terminal. Type something in the terminal. . Realize that tab is correctly not moving focus in the terminal. command "Toggle Tab Key Moves Focus" out of the terminal and keep tabbing until you get back to your editor. something in the editor. again until you reach the terminal. something in the terminal. to tab out of the terminal. It looks like tab moves focus as toggled itself off. Tab moves focus seems to be off for both terminal and editor at this point until reload.
I can also cause similar behavior if I flip the settings.
what is supposed to happen now? What I think I expect to happen (and isn't happening): If I run "Toggle tab key moves focus" while in a place where it doesn't move focus via setting, then it now globally moves focus. If I run "Toggle tab key moves focus" while in a place where it does move focus, then it now globally does not move focus. However, I'm not a "tab moves focus" user, so maybe my expectations are bogus.
Thank you for testing. Those expectations are correct, except that the toggling does not apply globally - it is per area. So, if I have in settings: terminal tab focus mode: on editor tab focus mode: off where: = status bar indicator = no status bar indicator focus the terminal focus the editor focus the terminal and toggle it off focus the editor and toggle it on focus the terminal focus the editor reload the window and focus the terminal focus the editor I see that this is not working atm because I'm not reacting to configuration changes
fyi for easier testing since the command palette can cause the terminal to no longer be focused, I'd suggest using the keybinding to toggle tab focus mode
Code change:
<del> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-disabled-grey{fill:#848484;}</style></defs><title>breakpoint-log-unverified</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M13.414,8,8,13.414,2.586,8,8,2.586Z"/></g><g id="iconBg"><path class="icon-disabled-grey" d="M8,4,4,8l4,4,4-4ZM5.414,8,8,5.414,10.586,8,8,10.586Z"/></g></svg> </del>  No newline at end of file <ins> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 16"><defs><style>.icon-canvas-transparent,.icon-vs-out{fill:#f6f6f6;}.icon-canvas-transparent{opacity:0;}.icon-disabled-grey{fill:#848484;}</style></defs><title>breakpoint-log-unverified</title><g id="canvas"><path class="icon-canvas-transparent" d="M16,0V16H0V0Z"/></g><g id="outline" style="display: none;"><path class="icon-vs-out" d="M13.664,8,8,13.664,2.336,8,8,2.336Z"/></g><g id="iconBg"><path class="icon-disabled-grey" d="M8,3.75,3.75,8,8,12.25,12.25,8ZM5.518,8,8,5.518,10.482,8,8,10.482Z"/></g></svg> </ins>  No newline at end of file

Related discussion:
text: When creating a breakpoint in an active debug session and this breakpoint cannot be verified, the resulting icon is almost invisible: ! The problem is that the icon's stroke is too thin. In previous versions the icon had a thicker stroke: ! I suggest that we restore the previous icon.
Agree that it is a bit too light. I do not just want to take the previous icon since the color and style are different. Thus it would be great if could tackle this Also fyi
Not quite as strong as in the 'before' above, but stronger. Marking verified. !
Code change:
isDefault: true }; if (detectedProfile && detectedProfile.profileName === createdProfile.profileName && detectedProfile.path === createdProfile.path && this._argsMatch(detectedProfile.args, createdProfile.args)) { <del> return undefined; </del> <ins> return detectedProfile.profileName; </ins> } return createdProfile; }

Related discussion:
text: Testing With the following settings: I saw the terminal migration notification and then clicked "Migrate", and my settings changed to: Which is defintely not what I expected to happen.
Perhaps if the shell/shellArgs match one of the detected profiles, the name of that profile can be used? So in the sample above,
I'm also kinda confused by this... here's what I had: and it turned it into:
The behavior should be: If there is an exact match (eg. just ), it should assign the existing profile as the default (). If there is not an exact match (eg. ), it should add the profile to the list and set it as the default. As for the name maybe something like would be best.
To verify, see and try other combinations
or could you pls verify this?
with the following: I don't get a notification. Is that expected?
If you've already said don't show again to the notification in that workspace, yes.
ah... I hit the which didn't show the notification until I reloaded the window.
that was another fix that went in to make sure we're not annoying
Migration doesn't seem to be working for me. Here's a gif: ! These are the same settings as here
Ah looks like if I already define then this migration doesn't work. If I delete that setting (and use instead as the default profile, the migration works.
Meaning if you set the to the name of a profile that already exists within your it doesn't work? I think that's by design.
Gotcha. The only thing I'll mention is this, with a defined does not prompt me: but this without it defined does prompt me:
I guess I would expect the migration to still happen (and a new profile be to my existing ) but maybe that's out of scope.
That seems wrong. It should happen as long as you haven't said don't show again. I'll try it.
ah... just opened dev tools:
it's working for me on Windows.
Hmm what does that mean?
Here's a repro on non-Windows without PowerShell:
any errors in dev tools with that repro? can you turn on trace logging? and search for 'migrat'
Beyond this: I don't see anything... which Output should I dig into specifically?
Run set log level -trace -open developer tools.