jiebi/CodeConvo huggingface dataset:
Code change:
if (!model) { return false; } <del> if (model.uri.scheme === 'output') { // in output editor return false; } </del> if (editor.getOption(EditorOption.inDiffEditor)) { // this editor belongs to a diff editor for (const diffEditor of codeEditorService.listDiffEditors()) {

Related discussion:
text: Visual Studio's Output window has a "Toggle Word Wrap" button, but VS Code has word wrapping always (?) enabled. For certain scenarious like the pending "C/C++ References" output it is desirable for word wrapping to be disabled for the results to be more easily read. There is a "View: Toggle Word Wrap" command, but it applies to the active document only (and not the Output panel, even if it's active). And/or if the OutputChannel interface could add a toggleWordWrap capability, that would allow extensions to set an appropriate default for their particular Output channel. This seems like a pretty basic feature that other Output channel providers would want, but I couldn't find an existing feature request on this.
This describes the same issue and led to adding a config option but it doesn't seem to work or the feature request was misunderstood?
Thanks a lot -- I can use that [Log] setting as a workaround (by setting it in our configurationDefaults); however, the result is still not ideal because it will apply to all Output windows and our C/C++ extension would prefer to isolate the behavior to a specific one. (And a button in the UI would make it easier for users to figure out how to overwrite our "no wrap" default).
Currently, one workaround is to set:
Yes, that is the same workaround I was describing (which our C/C++ extension uses), but it applies to all the output panes, and we'd prefer to isolate the change to a particular output pane (e.g. "C/C++" or "C/C++ References" and not "Git", etc.).
that's a nice to have feature.
For log files, I had the word wrap button visible & after a few moments it just disappeared
It looks like the 'editor.wordWrap' setting no longer works for [Log]. Was it removed intentionally or it is a bug?
That setting is working for me with non-Insiders VS Code with our C/C++ output window, but I see certain output panes like "Window" ignoring the setting somehow (i.e. it always wraps).
Ah, it's working for me now. It looks like it requires a Reload Window after it is set.
command is now also supported for Output Channels.
Code change:
'libdrm2 (>= 2.4.38)', 'libexpat1 (>= 2.0.1)', 'libgbm1 (>= 8.1~0)', <del> 'libgcc-s1 (>= 3.0)', 'libgcc-s1 (>= 3.5)', </del> 'libglib2.0-0 (>= 2.16.0)', 'libglib2.0-0 (>= 2.39.4)', 'libgtk-3-0 (>= 3.9.10)',

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 <!-- 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: Insiders 1.71 OS Version: Ubuntu 18.04 amd64 Steps to Reproduce: to install latest code-insiders packages from MS repository () The issue is that with the dependency on Debian derivatives changed to which only exists on newer releases (20.04 and later I think). I realise that support for Ubuntu-Ancient is low on the priority list, but I am sadly stuck with it, and would appreciate if there was a workaround. Installing newer libgcc releases as suggested in some places easily leads to a very broken system.
This is a side effect of now using bullseye sysroot, we should apply the following change https://chromium- to our debian calculate package deps.
Code change:
# means the user re-exported the PS1 so we should re-wrap it if [[ "$__vsc_custom_PS1" == "" || "$__vsc_custom_PS1" != "$PS1" ]]; then __vsc_original_PS1=$PS1 <del> __vsc_custom_PS1="[$(__vsc_prompt_start)]$PREFIX$__vsc_original_PS1[$(__vsc_prompt_end)]" </del> <ins> __vsc_custom_PS1="[$(__vsc_prompt_start)]$__vsc_original_PS1[$(__vsc_prompt_end)]" </ins> PS1="$__vsc_custom_PS1" fi if [[ "$__vsc_custom_PS2" == "" || "$__vsc_custom_PS2" != "$PS2" ]]; then

Related discussion:
text: Type: <bBug</bIn the new shell integration options for Bash and Zsh, VS Code wraps the PS1 prompt variable to support new functionality. However, when it does this, it prefixes the PREFIX environment variable to the existing PS1 when creating the new PS1 prompt. See the picture below for an example. ! For Bash, the problem is at: For Zsh, see: Steps to reproduce: either Bash or Zsh, enable the integrated terminal a value to a variable named PREFIX in the integrated terminal that the value you assigned to PREFIX is prepended to the prompt The PREFIX environment variable is commonly used across a variety of projects in the Linux world for configuring and building applications (grepping for 'PREFIX during the build process and it makes the terminal hard to use. This issue is the cause of . I can submit a pull request for this if you'd like. VS Code version: Code 1.71.0 (, 2022-09-01T07:36:10.600Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <!-- generated by issue reporter --
thanks for the investigation and yes would appreciate a PR for this
I can't remember why PREFIX is there, we should blame history before doing the fix
Looks like PREFIX was only used in the initial commit to accomplish what is currently done with _vscpromptstart(), and it was safe to do so as PREFIX was declared as a local variable. Here are the original commits of the relevant files: Zsh: Bash: The second commit to modify these files () modified the updateprompt() function and removed the local PREFIX variable, but did not remove the variable from the PS1 assignment.
For Zsh specifically, in , extra references to PREFIX were to fix a separate issue.
Nice, looks like it's safe to switch to in bash. I'm guessing it's safe in zsh too, do you agree?
<!-- 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!
/verified
Code change:
registry.registerWorkbenchAction(new SyncActionDescriptor(SaveAllAction, SaveAllAction.ID, SaveAllAction.LABEL), category, ['save', 'all', 'files']); registry.registerWorkbenchAction(new SyncActionDescriptor(SaveFilesAction, SaveFilesAction.ID, null /* only for programmatic trigger */)); registry.registerWorkbenchAction(new SyncActionDescriptor(RevertFileAction, RevertFileAction.ID, RevertFileAction.LABEL), category, ['revert', 'file']); <ins> registry.registerWorkbenchAction(new SyncActionDescriptor(GlobalNewFileAction, GlobalNewFileAction.ID, GlobalNewFileAction.LABEL), category, ['new', 'file']); </ins> registry.registerWorkbenchAction(new SyncActionDescriptor(GlobalNewFolderAction, GlobalNewFolderAction.ID, GlobalNewFolderAction.LABEL), category, ['new', 'folder']); registry.registerWorkbenchAction(new SyncActionDescriptor(GlobalCompareResourcesAction, GlobalCompareResourcesAction.ID, GlobalCompareResourcesAction.LABEL), category, ['compare', 'files']); registry.registerWorkbenchAction(new SyncActionDescriptor(CloseFileAction, CloseFileAction.ID, CloseFileAction.LABEL, { primary: KeyMod.chord(KeyMod.CtrlCmd | KeyCode.KEY_K, KeyCode.KEY_W) }), category, ['close', 'file']);

Related discussion:
text: VSCode Version: 1.0.0 OS Version: OSX 10.11.3 I noticed that we can set to a keybinding. Which creates a nice input field in the sidebar to create the directory at the current selected position. ! But there is no possibility to do this for a file. Yes you can bind but it does not do the same thing. It just creates a new and when pressing <kbdcmd</kbd+ <kbds</kbdyou have to choose the destination in a picker. So, is it possible to add something for a new file as well? It would really improve my speed because I don't have to touch my mouse anymore to create a new named file in a specific directory.
sounds like a good example for a PR?
Yes I looked into it but to be honest, I have to clue where to start :). So if you can point me in the right direction, I would be very happy to do one :).
I would start by fulltext search for the action id () and that brings you here: From there you can get a feeling how this global action works and maybe add the new one. You will also see the one on top for creating an untitled file (which is not what you want). When you find the references of that action you will see where it is being registered to the system:
Alright, awesome. Thank you very much Will see what I can do :).
Code change:
} } <del> class TreeMenus extends Disposable implements IDisposable { </del> <ins> class TreeMenus implements IDisposable { </ins> private contextKeyService: IContextKeyService | undefined; private _onDidChange = new Emitter<ITreeItem>(); public readonly onDidChange = this._onDidChange.event;

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/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: V1.81.1 OS Version: Linux kkuser-virtual-machine 5.15.0-83-generic ~20.04.1-Ubuntu SMP Mon Aug 21 14:00:49 UTC 2023 x8664 x8664 x8664 GNU/Linux Steps to Reproduce: are constant changes in attribute states in the treeview calls to () functions result in memory leakage
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.82.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
<!-- 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!
Code change:
} private _layout(): void { <del> const windowWidth = window.innerWidth; const width = windowWidth * DIMENSION_DEFAULT.WIDTH; this._editorWidget.layout({ width, height: this._editorWidget.getContentHeight() }); const left = Math.round((windowWidth - width) / 2); this._editorContainer.style.left = `${left}px`; </del> <ins> this._editorWidget.layout({ width: DIMENSION_DEFAULT.WIDTH, height: this._editorWidget.getContentHeight() }); </ins> } private async _getTextModel(resource: URI): Promise<ITextModel | null> {

Related discussion:
text: When resizing the windows while the accessible help menu is visible, the help menu slides diagonally: !
Code change:
} private _layout(): void { <del> const windowWidth = window.innerWidth; const width = windowWidth * DIMENSION_DEFAULT.WIDTH; this._editorWidget.layout({ width, height: this._editorWidget.getContentHeight() }); const left = Math.round((windowWidth - width) / 2); this._editorContainer.style.left = `${left}px`; </del> <ins> this._editorWidget.layout({ width: DIMENSION_DEFAULT.WIDTH, height: this._editorWidget.getContentHeight() }); </ins> } private async _getTextModel(resource: URI): Promise<ITextModel | null> {

Related discussion:
text: Repro: Alt+F1 ! If should be in the center as that's the most obvious location Version: 1.80.0-insider (user setup) Commit: Date: 2023-06-28T08:01:04.380Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
Putting it here makes the most sense to me because that's where we put other components - like the quick pick. I want to get feedback from low vision users
That's fine, but if you're styling like the command palette we should position it in a similar way ! So below the title bar and not quite and maybe a little less wide
Re , we should also size the height similar to quick pick
But shouldn't the height be determined by the contents?
yes, but have a similar height cap to the quick pick
We should also use the same font as the quick pick
I think you've convinced me - this should be in the center.
Personally I preferred the top position, I'd just render it as the quick pick: Same position and same style. VS Code does not have many vertically centered dialogs. If you want to make it vertically centered, I'd suggest to align it with other vertically centered dialogs, like the trust dialog (notice the background shadow): ! ! Generally, I think, if there is no particular reason to be different, we should try to have a consistent UI throughout the entire product. I'm still in favor of the top position, as the workspace trust dialog is the only vertically centered dialog I know of and it is strongly modal (you have to click one of the buttons to make it disappear). FYI
Fading the background like the trust dialog is good imo, I like centered as it's a very special mode and it's modal as in clicking outside will always dismiss it, unlike the quick pick which may not dismiss when clicking outside. In the end the visual appearance isn't that important really, I just want it to be very obvious when the accessible view is up.
I agree that we should try to align with existing design. My personal preference is to have it positioned like the quick pick.
Code change:
} private _layout(): void { <del> const windowWidth = window.innerWidth; const width = windowWidth * DIMENSION_DEFAULT.WIDTH; this._editorWidget.layout({ width, height: this._editorWidget.getContentHeight() }); const left = Math.round((windowWidth - width) / 2); this._editorContainer.style.left = `${left}px`; </del> <ins> this._editorWidget.layout({ width: DIMENSION_DEFAULT.WIDTH, height: this._editorWidget.getContentHeight() }); </ins> } private async _getTextModel(resource: URI): Promise<ITextModel | null> {

Related discussion:
text: But in the end, it is not super important as pointed out.
One issue with doing it as the quick pick is it would look wrong being so narrow, and making is narrow would make it less accessible, say if a low vision user was using it.
Not sure it needs to be as narrow as quick pick. I just think the positioning of the quick pick is fitting. So the top and center. It could be wider or longer.
Now that we have the focus border, it is more obvious, so fine to be at the top IMO.
This is still not fixed imo, it should follow quick pick and look like this (native title bar): ! Not this (custom title bar): !
Verified off main :+1:
Code change:
super.render(container); addClass(container, 'switch-output'); this._register(attachStylerCallback(this.themeService, { selectBorder }, colors => { <del> container.style.border = colors.selectBorder ? `1px solid ${colors.selectBorder}` : ''; </del> <ins> container.style.borderColor = colors.selectBorder ? `${colors.selectBorder}` : ''; </ins> })); }

Related discussion:
text: The select box in the panel header should have a white background: ! This is similar to the recent breakage with the simple editor widget background color in SCM and extensions views.
To Verify: to an obvious color. that terminal and output select boxes are using these when they are in their default locations in panel.
Code change:
<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import { ContentHoverController } from 'vs/editor/contrib/hover/browser/contentHover'; import { Range } from 'vs/editor/common/core/range'; import { Position } from 'vs/editor/common/core/position'; import { IHoverPart } from 'vs/editor/contrib/hover/browser/hoverTypes'; suite('Content Hover', () => { test('issue #151235: Gitlens hover shows up in the wrong place', () => { const actual = ContentHoverController.computeHoverRanges( new Range(5, 5, 5, 5), [<IHoverPart>{ range: new Range(4, 1, 5, 6) }] ); assert.deepStrictEqual( actual, { showAtPosition: new Position(5, 5), showAtRange: new Range(5, 5, 5, 5), highlightRange: new Range(4, 1, 5, 6) } ); }); }); </ins>

Related discussion:
text: ! 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
Code change:
j:number, lastIncludedCharIndex:number, len:number, <del> characterClasses = getCharacterClasses(), characterClassesLength = characterClasses.length, </del> linkBeginIndex:number, state:number, ch:string,

Related discussion:
text: VSCode Version: 1.0 OS Version: OS X 10.11.4 I just upgraded my VSCode to 1.0 release. Since it supports Traditional Chinese now, my default language was set to so that some of comments in the newly config file is in Chinese. As you can see in the following screenshot, a Chinese character "", which is equivalent to the period "." in English, was matched as part of valid URL, and it caused VSCode direct to a incorrect URL. ! I have a working fix for this issue, the naive solution is to check if in is greater than 128, which means a non-ASCII character. Why to match only ASCII character? Because when you copy a URL from most of web browsers to clipboard, it will be automatically converted into ASCII-only string. Also, I came up with another idea to modify the to let it cache all the result of ASCII characters (0~127). In this way, we only need to modify the default case of the switch clause in the state machine. Which solution is more preferable? Please give me some advice then I can submit the patch ASAP.
Code change:
})); this.nextBtn = this._register(new SimpleButton({ <del> label: NLS_NEXT_MATCH_BTN_LABEL, </del> <ins> label: NLS_NEXT_MATCH_BTN_LABEL + (options.nextMatchActionId ? this._getKeybinding(options.nextMatchActionId) : ''), </ins> icon: findNextMatchIcon, onTrigger: () => { this.find(false);

Related discussion:
text: Terminal: <img width="328" alt="image" src=""Editor: <img width="436" alt="image" src=""
Code change:
content.push(`.monaco-list${suffix}:not(.drop-target):not(.dragging) .monaco-list-row:hover:not(.selected):not(.focused) { color:  ${styles.listHoverForeground}; }`); } <del> if (styles.listSelectionOutline) { content.push(`.monaco-list${suffix} .monaco-list-row.selected { outline: 1px dotted ${styles.listSelectionOutline}; outline-offset: -1px; }`); </del> <ins> /** * Outlines */ const focusAndSelectionOutline = asCssValueWithDefault(styles.listFocusAndSelectionOutline, asCssValueWithDefault(styles.listSelectionOutline, styles.listFocusOutline ?? '')); if (focusAndSelectionOutline) { // default: listFocusOutline content.push(`.monaco-list${suffix}:focus .monaco-list-row.focused.selected { outline: 1px solid ${focusAndSelectionOutline}; outline-offset: -1px;}`); </ins> } <del> if (styles.listFocusOutline) { </del> <ins> if (styles.listFocusOutline) { // default: set </ins> content.push(` .monaco-drag-image, .monaco-list${suffix}:focus .monaco-list-row.focused { outline: 1px solid ${styles.listFocusOutline}; outline-offset: -1px; }

Related discussion:
text: This seems really aggressive and probably not intentional <img width="406" alt="image" src="https://user-"
I think this rule references a css variable that isn't defined <img width="501" alt="image" src="https://user-" it looks like you were in this area recently, it looks like there is a default that we don't fall back to, do you know what's going on?