jiebi/CodeConvo huggingface dataset:
Change:
})); this._register(addDisposableListener(this._domNode, EventType.CLICK, (e) => { <del> this._widget.revertRangeMappings(this._diffs); </del> <ins> if (this._diffs instanceof LineRangeMapping) { this._widget.revert(this._diffs); } else { this._widget.revertRangeMappings(this._diffs); } </ins> e.stopPropagation(); e.preventDefault(); }));

Discussion:
a change it using the gutter arrow :bug: indentation is lost
Can you share a screenshot/screenrecording and provide context on the document you have? Thanks!
Cannot reproduce: ! Please always try to include as much context as you can.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Hi Henning I think I can also reproduce this in 1.84.0-insider (MacOS). I believe the preconditions to reproduce is to set (which is also the default) and revert a deleted code chunk. See attached gif. !
Hey this issue might need further attention. you can help us out by closing this issue if the problem no longer exists, or adding more information.
Change:
} const padding = parseInt(getComputedStyle(document.querySelector('.terminal-outer-container')).paddingLeft.split('px')[0], 10); <ins> const paddingBottom = parseInt(getComputedStyle(document.querySelector('.terminal-wrapper.active')).paddingBottom.split('px')[0], 10); </ins> // Use left padding as right padding, right padding is not defined in CSS just in case // xterm.js causes an unexpected overflow. const innerWidth = width - padding * 2; <del> TerminalInstance._lastKnownDimensions = new Dimension(innerWidth, height); </del> <ins> const innerHeight = height - paddingBottom; TerminalInstance._lastKnownDimensions = new Dimension(innerWidth, innerHeight); </ins> return TerminalInstance._lastKnownDimensions; }

Discussion:
<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issues to prefill these. --- VSCode Version: latest OS Version: Win10 A little bit more space between last line from terminal and the blue line below would be nice !
I 1px border on the bottom would be fine, opening to PRs. Who ever wants to pick this up, you need to make sure the size of the terminal is calculated correctly given the new margin. Relevant files: , .
I'll pick this up. pretty much all of the other terminal issues are already taken, or out of my realm. just let me know somebody's not already working on this ;-)
sounds good
PR posted
Change:
private static readonly UnInstallingClass = `${ExtensionAction.LABEL_ACTION_CLASS} uninstall uninstalling`; constructor( <del> @IExtensionsWorkbenchService private extensionsWorkbenchService: IExtensionsWorkbenchService </del> <ins> @IExtensionsWorkbenchService private readonly extensionsWorkbenchService: IExtensionsWorkbenchService, @IDialogService private readonly dialogService: IDialogService </ins> ) { super('extensions.uninstall', UninstallAction.UninstallLabel, UninstallAction.UninstallClass, false); this.update();

Discussion:
I clicked to "Uninstall" an extension with dependencies and got an error toast as a result: ! I think since I clicked a button explicitly, I would expect a modal dialog as a result.
Sounds low hanging? Should we close or this milestone to fix?
We closed this issue because we in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider. If you wonder what we are up to, please see our and . Thanks for your understanding, and happy coding!
Change:
} .monaco-editor .comment-range-glyph.comment-thread:before { <del> content: "◆"; font-size: 10px; </del> <ins> content: "ea6b"; font-family: "codicon"; font-size: 14px; width: 19px !important; </ins> line-height: 100%; <ins> border-radius: 3px; </ins> z-index: 20; <ins> margin-left: -5px; </ins> } <del> .monaco-editor.inline-comment .margin-view-overlays .folding { margin-left: 7px; </del> <ins> .monaco-editor.inline-comment .margin-view-overlays .codicon-folding-expanded, .monaco-editor.inline-comment .margin-view-overlays .codicon-folding-collapsed { margin-left: 13px; </ins> } .monaco-editor.inline-comment .margin-view-overlays .dirty-diff-glyph { <del> margin-left: 14px; </del> <ins> margin-left: 23px; </ins> }

Discussion:
I was exploring ways to improve the PR experience in VS Code and one of the ideas involved updating the glyph area for comments. Currently we show a gray bar and a unicode and that don't look very pretty. ! A couple of things I explored: Moving glyph area to the left of line numbers. This helps create separation between between the scm indicators and a clear area for adding comments. Adding button for adding and view comments. This follows a similar pattern on GitHub for reviewing changes. Hiding diff chunk areas. This reduces the visual noise and I think most people will be commenting on changed lines in the PR as opposed to lines that are not related Adding color to the and changes to look visually pleasing ! Unsure who should I assign to so assigning to and for now
Some additional feedback from the team: We might still need the indicator for comment areas, particularly when viewing files with changes in review mode where the diffs are not present ! We could also surface the "add comment" button on line hover to increase discoverability
I agree that we will likely still need to show the range, but let's improve the leave-a-comment and there's-a-comment decorations.
Here's what I'm thinking: ! It uses the comment codicon for lines with a comment thread. Keeps the existing + for add Makes them both look a little more clickable but making them more square and giving them rounded corners. and what do you think? I didn't add any color for now and I kept everything to the right of the line numbers still.
this is looking great, love that we can have codicon support in the comments! I know you mentioned you hadn't any color, is that something that you'd be open for us to add? I did a quick mockup that shows an alternate styling: <img width="314" alt="CleanShot 2022-08-08 at 08 57 41 src="https://user-"
I didn't add color because I thought the blue was a bit too strong, but I really like the color in this mock up. I'll add it and merge the change! I also see that you're using the codicon +. I'll switch to that too.
Also updated the multiline add: !
Change:
} const range = firstVisibleRangeForCharacter.ranges[0]; <del> const width = range.width < 1 ? this._typicalHalfwidthCharacterWidth : range.width; </del> <ins> const width = ( nextGrapheme === 't' ? this._typicalHalfwidthCharacterWidth : (range.width < 1 ? this._typicalHalfwidthCharacterWidth : range.width) ); </ins> let textContentClassName = ''; if (this._cursorStyle === TextEditorCursorStyle.Block) {

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 <!-- 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.68.0 OS Version: Ubuntu 20.04.4 LTS Steps to Reproduce: indenting to tabs cursor style to block the cursor at the start of a tab; its width increases to the tab stop Besides looking quite silly and different from other editors (e.g. Emacs or Jetbrains IDEs), the constant growing and shrinking is extremely nauseating when rapidly moving the cursor vertically.
Do you have a suggestion about what to do in these cases? Ensure a max width? Sometimes, the block cursor can sit on a glyph which is a lot wider than a typical character like e.g. .
In both Emacs and the Jetbrains IDEs the block cursor remains the width of a space when placed on a tab indent. I pasted your wide character in a test file and it grows to cover it in both environments as well. As far as I'm concerned that's a very pleasant behaviour. :-)
Just to make sure, my primary concern is not esthetics, which are always subjective, but the amount of screen flicker that is currently involved, since tabs at the beginning of lines in code have a very high density.
great, thanks Already enjoying it in insiders :-)
Change:
return result; } <ins> export function getCaseInsensitive(target: obj, key: string): any { const lowercaseKey = key.toLowerCase(); const equivalentKey = Object.keys(target).find(k => k.toLowerCase() === lowercaseKey); return equivalentKey ? target[equivalentKey] : target[key]; } </ins>

Discussion:
Connect a mac-windows SSH remote Open terminal See this popup ! So fails here because it checks ".PATH" on the environment when this is actually "Path" on windows. has special behavior where it resolves property accesses in a case-insensitive way on Windows. We changed many accesses from using to a constructed environment object, and need the same behavior there.
is this a mac-specific issue or are there steps to repro/verify on Windows?
Can't be verified on windows. Thanks
Change:
import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; <del> import { ShellIntegrationStatus, WindowsShellType } from 'vs/platform/terminal/common/terminal'; </del> <ins> import { ShellIntegrationStatus, TerminalSettingId, WindowsShellType } from 'vs/platform/terminal/common/terminal'; </ins> import { AccessibilityVerbositySettingId } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; import { AccessibleViewType, IAccessibleContentProvider, IAccessibleViewOptions } from 'vs/workbench/contrib/accessibility/browser/accessibleView'; import { ITerminalInstance, IXtermTerminal } from 'vs/workbench/contrib/terminal/browser/terminal';

Discussion:
Changing this behavior could be jarring, so instead, we will set it to by default and include a hint about this in the terminal accessibility help dialog.
To verify, enable screen reader mode, run the command . The terminal shouldn't be focused and the accessible buffer shouldn't be opened. Change the setting and repeat and verify that it works per the setting descriptions.
So that is u - who spoiled the terminal focus in user-input scenarios. Would be awesome if auto-focus worked only on pending user input to the terminal, so everybody would be happy. But I have no clue if such a functionality is even possible.
not sure what you mean, but you can set it to to have the terminal focused automatically !
Yes, thank you, I know. I mean next cases at the same time: only prints to the console - no focus to the waits for user input - terminal receives auto-focus
Change:
case ConfigurationTarget.USER: { const { local, remote } = await this.reloadUserConfiguration(); <del> await this.loadConfiguration(this._configuration.applicationConfiguration, local, remote); </del> <ins> await this.loadConfiguration(this._configuration.applicationConfiguration, local, remote, true); </ins> return; } case ConfigurationTarget.USER_LOCAL:

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?: not applicable <!-- 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.79.0-insider OS Version: Windows 11 x64 Steps to Reproduce: an extension that implements a FileSystemProvider and serves a file containing a setting. a workspace that uses this FSP. that the setting has no effect until the workspace is reloaded. I will prepare a branch of fsprovider-sample to demonstrate the issue.
Repro steps: project () and VSIX (). an empty profile and install the VSIX into it. no folder or workspace open, run . Explorer find and open that though this specifies a font size of 24 it is displayed in the default font size. and observe that the font size is now correct. !
/assign I will submit a PR to fix this.
<!-- 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
Change:
"@vscode/windows-mutex": "^0.5.0", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.34", "@xterm/addon-image": "0.9.0-beta.51", "@xterm/addon-search": "0.16.0-beta.51", "@xterm/addon-serialize": "0.14.0-beta.51", "@xterm/addon-unicode11": "0.9.0-beta.51", "@xterm/addon-webgl": "0.19.0-beta.51", "@xterm/headless": "5.6.0-beta.51", "@xterm/xterm": "5.6.0-beta.51", </del> <ins> "@xterm/addon-clipboard": "0.2.0-beta.35", "@xterm/addon-image": "0.9.0-beta.52", "@xterm/addon-search": "0.16.0-beta.52", "@xterm/addon-serialize": "0.14.0-beta.52", "@xterm/addon-unicode11": "0.9.0-beta.52", "@xterm/addon-webgl": "0.19.0-beta.52", "@xterm/headless": "5.6.0-beta.52", "@xterm/xterm": "5.6.0-beta.52", </ins> "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2", "jschardet": "3.1.3",

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 <!-- 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.92.0, commit OS Version: Windows 10 Enterprise, 22H2 build .4651 Error message: Steps to Reproduce: a new VS code window ! a new file and drag out to make another window ! "Create New Terminal in Editor Area" on that new window ! error will show up ! "Try Again" will reload the terminal, but it doesn't accept inputs, cannot type anything there ! Creating terminal in main window and drag it to side windows does work, but I have to do that with every window reload. Yesterday I could still use terminals in side windows like normal, this only occured after updating to 1.92 July update Thanks for reading :)
! Facing same issue
coming from xterm here I think !
I have the same problem on Fedora 40 Sway. After I click , it will create a non-interoperable terminal.
I'm also having this issue, I thought it might be a problem with WSL but it started for me after updating to VSCode 1.92.0 !
QUICK FIX!!! Just create a new In-window terminal and drag it to the new terminal window.
Will this be hotfixed or should we downgrade?
sorry this won't get a patch release as there's a few workarounds. To downgrade in the meantime you can grab 1.91.1 here , you'll also want to set
Hi. Didn't do the trick for me. Other hack: Ctrl+J (new term in main window) Ctrl + Shift + P Terminal: Move Into New Window Drag & Drop into wanted window. Cumbersom many many times a day.
Change:
dispose(disposables); <del> const iframes = getElementsByTagName('iframe'); </del> for (const iframe of iframes) { iframe.style.pointerEvents = 'auto'; }

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: Version: 1.37.0-insider Commit: Date: 2019-07-08T05:33:31.335Z Electron: 4.2.5 Chrome: 69.0.3497.128 10.11.0 V8: 6.9.427.31-electron.0 OS: Darwin x64 17.7.0 OS Version: macOS High Sierra 10.13.6 (17G7024) Steps to Reproduce: the following sample code of extension. the WebView Panel. is not smooth. ! Does this issue occur when all extensions are disabled?: Yes
Change:
private label?: IResourceLabelProps; private options?: IResourceLabelOptions; private computedIconClasses?: string[]; <del> private lastKnownConfiguredLangId?: string; </del> <ins> private lastKnownDetectedModeId?: string; </ins> private computedPathLabel?: string; private needsRedraw?: Redraw;

Discussion:
Issue Type: <bBug</bto something like . a new tab. The tab should have the Markdown icon, but it has the Plain Text icon. If you move to another tab then back, the icon will be updated. This only started happening when I updated to 1.3, and it's still happening in Insiders. I've got no extensions or settings (other than ) set. VS Code version: Code - Insiders 1.31.0-insider (, 2018-12-21T06:14:53.023Z) OS version: Darwin x64 18.2.0 <!-- generated by issue reporter --
This is a consequence of adopting : When the tab opens we immediately render the icon, but the resource only gets the mode associated after a on the end of the tick.
via
Change:
await this._webview?.removeMarkdownPreview(cell.id); } <ins> async updateMarkdownPreviewSelectionState(cell: ICellViewModel, isSelected: boolean): Promise<void> { if (!this._webview) { return; } await this._resolveWebview(); await this._webview?.updateMarkdownPreviewSelectionState(cell.id, isSelected); } </ins> async createInset(cell: CodeCellViewModel, output: IInsetRenderOutput, offset: number): Promise<void> { this._insetModifyQueueByOutputId.queue(output.source.model.outputId, async () => { if (!this._webview) {

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. --- VS Code Version: 1.54-Insiders OS Version: macOS open a GitHub issue notebook cmd+shift+o navigate down only code cells are highlighted https://user- <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --

Verifying in the vscode repo across some of the markdown headers ! If I put them into edit mode, then I see the background change on multiselect
I guess you don't see this issue when commenting out from the workspace setting?
Yeah, that's correct! I see everything get highlighted as expected when that setting is off
The root cause is that the for webview backed markdown cells has a height of zero. This element gets the correct background color during selection, but is not visible due to the height. We have zero height so that you can click through to the webview instead of to the cell I will prototype telling the cell in the webview if it is selected or not. Then we can add styling inside the webview to show selection state
Change:
_serviceBrand: undefined; readonly hasFocus: boolean = true; <ins> async hadLastFocus(): Promise<boolean> { return true; } </ins> readonly onDidChangeFocus: Event<boolean> = Event.None; async restart(): Promise<void> { }

Discussion:
I would like to see the release notes when there's an update, because there are always useful additions that I want to know about, but currently VS Code: re-opens release notes that I have already read, release notes in EVERY SINGLE WINDOW. ! These have been happening for years. Please fix them before I jump off a bridge! There should never be any reason to automatically open them more than ONE time. Perhaps consider using the OS notification system to send ONE notification. If you can't do that, please open ONE window with the release notes, instead of one tab in every window.
/needsMoreInfo does this reproduce if you run with all extensions disabled?
Since some of the conditions to reproduce it (a new release) are outside of my control, and outside of my knowledge until I see the release notes, that's very hard to answer. Are you trying to tell me that you do not have the release notes appear in every single window when you reopen Visual Studio Code and there's a new release? And that you never have them appear again after you've already read them? Since I've seen this happen SO many times, I guessed it happened quite widely.
This seems to be triggered from update, moving to Joao.
Yes there is a known issue: when opening release notes, every window opens them. It's pretty dramatic in your case since you seem to have ~20 windows open. But release notes should not appear twice, unless there's been a recovery update. There was one yesterday: 1.42.1... so that might explain it?
I could swear this issue had been fixed in the past... and I was right. Original issue is and fix was This got broken by
Muito obrigado João!
De nada! Make sure you let us know when stuff annoys you. Sometimes it seems obvious that an issue would annoy everyone but sometimes it just doesn't. :+1:
is there a good way to verify this? If not, I have already verified by code review.
Code review should be
Change:
import { ServicesAccessor } from '../../../../editor/browser/editorExtensions.js'; import { Schemas } from '../../../../base/common/network.js'; import { ITextEditorOptions } from '../../../../platform/editor/common/editor.js'; <del> import { IUserDataProfileService } from '../../userDataProfile/common/userDataProfile.js'; </del> import { coalesce } from '../../../../base/common/arrays.js'; import { mainWindow, isAuxiliaryWindow } from '../../../../base/browser/window.js'; import { isIOS, isMacintosh } from '../../../../base/common/platform.js';

Discussion:
When using vscode through a , if I switch profiles and then open an existing project (ctrl+r, left click), the url then updates with some url parameters (). The window loaded with that payload doesn't work correctly. For example, code search only works on the already opened files, and not the entire folder. A workaround is to remove the payload from the url. Version: 1.93.1 Commit: User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 Embedder: <!-- generated by web issue reporter --
Change:
import { Handler, ScrollType } from 'vs/editor/common/editorCommon'; import { EditorContextKeys } from 'vs/editor/common/editorContextKeys'; import { VerticalRevealType } from 'vs/editor/common/view/viewEvents'; <ins> import { MenuId } from 'vs/platform/actions/common/actions'; </ins> import { ICommandHandlerDescription } from 'vs/platform/commands/common/commands'; import { ContextKeyExpr } from 'vs/platform/contextkey/common/contextkey'; import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation';

Discussion:
While verifying I realized that expandLineSelection is not in the command window (F1). Would be good to have it as command to use programmatically.
It can be used programmatically. It doesn't show up in F1, just like moveLeft doesn't show up in F1. I agree it should be a proper action, so :+1: