Question: this._register(this.viewModel.searchResult.onChange((event) => this.onSearchResultsChanged(event))); this._register(this.onDidChangeBodyVisibility(visible => this.onVisibilityChanged(visible))); <ins> this.updateIndentStyles(this.themeService.getFileIconTheme()); this._register(this.themeService.onDidFileIconThemeChange(this.updateIndentStyles, this)); } private updateIndentStyles(theme: IFileIconTheme): void { this.resultsElement.classList.toggle('hide-arrows', this.isTreeLayoutViewVisible && theme.hidesExplorerArrows); </ins> } private onVisibilityChanged(visible: boolean): void {

<!-- 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.72.2 OS Version: Windows 11 / MacOS Monterey Steps to Reproduce: . the icons using the command. that the arrows are still not hidden. The vscode-icons extension has a setting called , which, as the name suggests, hides the explorer arrows next to the project folders. This look something like this: ! With the introduction of the tree mode in the search panel, I would not have expected to see any explorer arrows there. Alas, the panel has the search arrows, regardless of the extension setting. ! I already opened an issue on the vscode-icons repository, which you can find .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.72.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Still happens on 1.72.2!


Question: if (activationEventsNode?.type === 'array' && activationEventsNode.children) { for (const activationEventNode of activationEventsNode.children) { const activationEvent = getNodeValue(activationEventNode); <ins> // Redundant Implicit Activation </ins> if (info.implicitActivationEvents?.has(activationEvent) && redundantImplicitActivationEventPrefixes.some((prefix) => activationEvent.startsWith(prefix))) { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); diagnostics.push(new Diagnostic(new Range(start, end), redundantImplicitActivationEvent, DiagnosticSeverity.Warning)); <del> } else { for (const implicitActivationEventPrefix of reservedImplicitActivationEventPrefixes) { if (activationEvent.startsWith(implicitActivationEventPrefix)) { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); diagnostics.push(new Diagnostic(new Range(start, end), implicitActivationEvent, DiagnosticSeverity.Error)); } </del> <ins> } // Reserved Implicit Activation for (const implicitActivationEventPrefix of reservedImplicitActivationEventPrefixes) { if (activationEvent.startsWith(implicitActivationEventPrefix)) { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); diagnostics.push(new Diagnostic(new Range(start, end), implicitActivationEvent, DiagnosticSeverity.Error)); </ins> } } <ins> // Star activation if (activationEvent === '*') { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); const diagnostic = new Diagnostic(new Range(start, end), starActivation, DiagnosticSeverity.Information); diagnostic.code = { value: 'star-activation', target: Uri.parse('https://code.visualstudio.com/api/references/activation-events#Start-up'), }; diagnostics.push(diagnostic); } </ins> } } }

We want to discourage extension authors from using activation. We should consider adding a diagnostic warning similar to the one we have for implicit events.
Is it not enough that provides the same prompt in terminal when packaging/publishing an extension?
at that stage in the development lifecycle, authors are more likely to just ignore the warning from vsce. Additionally, they might be publishing in CI and might not see it there either.
verification: in an extension, put in activation events see this: !


Question: public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.46.1 OS Version: Ubuntu 20.04 LTS x86_64 shell: bash When alt-clicking in terminal (e. g. to open a file or URL), it gets filled up with lots of or : ! Steps to Reproduce: integrated terminal (or, for a more practical example, in a temp dir) -click anywhere <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Having the same issue in WSL with Ubuntu 18.04 when alt+clicking any link.
Looks like this is an issue where the alt+click feature (move cursor when clicking) is conflicting with links, only when is used.
This issue also occurs on MacOS, only with Opt+Click instead of Alt+Click. I thought at first that this was related to the Opt+Click on a detected link in the terminal (since that is an Alt+Click on Windows/Linux). But this truly does occur when Opt+Clicking anywhere in the terminal while a command is waiting for input. I can confirm that this occurs on my MacOS regardless of the value of setting.
set in , now the way you click url is cmd + click, and it wont happen again
nope, that only slightly changes the junk that is dumped into the Terminal, but it doesn't get rid of it... With (default): With :
emmm, you say is right, i just change a way to open url in vscode terminal to avoid echo ^[[D but not fix it , this also occurs in , if you use option + click. by the way,my final setting as follows (if , vscode still let you click url with option + click ) !
Oh! That's a great observation, Alt+Click fills the terminal with junk even in the standard MacOS Terminal app and also in iTerm2. Now, I am aware that is originally reporting this for Ubuntu. I checked my Linux laptop (Fedora 31), and Alt+Click in the standard system terminal emulator does nothing. It only occurs in VSCode's terminal.


Question: public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

But this still makes me wonder if all of this is system-level issues, or perhaps terminal "emulator" issues, not really a VSCode issue. Hard to know. But the Microsoft devs would know.
As for your workaround, thank you so much for that!!! I still don't see any change in VSCode's behavior when using , but changing definitely avoids the core issue. I hope you don't mind me describing in more detail... According to , "The Go To Definition and Open Link gestures will also respect this setting and adapt such that they do not conflict. For example, when the setting is ctrlCmd, multiple cursors can be with Ctrl/Cmd+Click, and opening links or going to definition can be invoked with Alt+Click." You probably did what I did when originally installing VSCode... I'm using to using Ctrl+Click in Linux and Cmd+Click in MacOS to multi-select files in Finder, items in a list, etc. So I set to be . However, this means that attempting to click on a link in the terminal (for example, an error message referencing the offending line in your source code) requires the use of the other shortcut (Alt + Click). Since it seems that Linux and MacOS have various strange behaviors when Alt + Clicking in a terminal, you are suggesting we switch back to the default . Now we'll use Ctrl+Click / Cmd+Click to follow links in the Terminal, avoiding all that ^[[D^[[D^[[D^[[D nonsense that sometimes causes the terminal to hang. For multi-selecting in the editor window, we'll have to get used to using Alt + Click for that, but in my opinion, that is better than having terminal hanging issues unexpectedly.
So to clarify what I originally posted to Alt+Click will still cause junk to fill the screen, regardless of the value of "editor.multiCursorModifier" setting. However, the above workaround means we don't need the Alt+Click anymore.
it's a feature that's sending keys to move the terminal cursor to the position of the mouse cursor. It needs support in whatever program is running in the terminal though which is why you might see the printed, we cannot detect this support though. The advice right now is to avoid alt clicking if it doesn't work in the program.


Question: public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

could you clarify... Is this a feature in Linux that's doing it, and vscode is not able to see that it's happening? Or do you mean this is a feature in vscode to move the cursor, and vscode is not able to tell if the terminal shell supports it?
it's a feature in , you can see the PR here
what an interesting feature, and I never even knew that was there. Thank you for the perspective. I looked through that PR and searched the settings in VSCode; unfortunately, there doesn't seem to be any way to disable that cursor-moving feature.
Yeah, that feature might be useful but the ability to disable it or, even better, change a modifier to another one (so that it doesn't conflict with the “open file in editor” one) :)
I'm seeing this happen regardless of the setting, on Ubuntu 18.04
Just to inform that is waiting for a community PR for this.
Um, how is project related to VSCode?
Hey great question. The package is a direct dependency as you can see here: means that the behavior will first have to be patched in the underlying package and then it will likely be made available through a setting in VSCode in a future release.
I opened a PR with which would make it possible to disable this feature:
The PR was merged. What is required in order to pass the new option to in VSCode?
I meant no offense; perhaps my "Um" conveyed an unintended tone. I was simply asking, as a non-developer user who has never looked through the VSCode codebase, but is experiencing the OP's issue... how an xterm project would be blocked by an issue in VSCode.
Ah sorry, I assumed you were familiar with the package because of your previous posts (and although it’s no excuse) I’ve learned my lesson and will henceforth refrain from posting prior to my morning coffee - the tone was indeed unnecessary. The original message has been duly modified.
So, does anyone know how to disable it in vscode?
The problem with has been fixed. Could you kindly suggest what are our next steps here?
Sorry, I've been out for a while. We updated in vscode yesterday, so the next steps are to expose it as a setting in vscode. Searching for a similar setting should show how/where to do something like this.


Question: public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

if no one picks this up from the community it would be a good change for you in debt week.
Thank you so much! :tada:
Once it's released in insider's, to verify, set
Hi! Thanks for fixing this Just to understand, may I ask: Why will the future setting default to true? One year ago the problem didn't happen on a fresh install, so why not fix the regression Why is this issue closed but the bug still exists in the latest Insiders? Thank you
As far as I understand this is a new feature in . The special characters only get displayed in certain situations (probably when the running command prevents the shell from moving the cursor). Also the default setting for multicursor is <kbdCtrl</kbdso you would not use <kbdAlt</kbdnormally unless you want exactly this new feature.
I just want to open a file from within the terminal out of the box ! I typically do when running in watch mode On Linux the shortcut is Ctrl+Alt+Click even if the screenshot says otherwise Can users do this without having to find this issue and the corresponding setting? Also, when the filling happens, often the terminal gets stuck, I cannot kill the process with anymore, should I open another issue about this?
Thank you for voicing your concerns - I have to agree that OFF should be the default behavior as Alt-Click is mapped to the file open command in VS Code, and ON is therefore most likely to be the undesired behavior.
<kbdAlt</kbd+<kbdClick</kbdis not the default. The default for opening links and definitions is the one key not used by the multicursor modifier which is by default <kbdAlt</kbd. You can confirm this by looking in the docs or viewing the default value in the settings UI.
Just tried in Portable mode on Linux with no settings nor extension installed. The problem still reproduces. fixes the problem but I'm not sure how new users would know about this
You may be misunderstanding what this option attempts to solve. It's unfortunate that the name was chosen for the setting, since the setting is not about vs. , but rather about enabling or disabling the pseudo-mouse-cursor-moving feature in xTerm entirely. I concur with go back a year and VSCode didn't have this annoying broken "feature" of the terminal.


Question: public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

Now that we've recognized it's broken and updated the xTerm dependency to a version that allows us to get rid of the broken "feature", the default behavior from a VSCode perspective should be to have the feature disabled, since we really never wanted it in the first place. Also, as pointed out, when the typical user hits this strange behavior, are we just expecting them to "VSCode terminal fills with ^[[D^[[D^[[D^[[D^[[D^[[D and locks up" into Google and hope for the best? This "feature" does not work 100%. It should be considered beta/experimental and disabled by default.
I can attempt a PR that Changes the setting name to perhaps (something that doesn't mention vs. ) Default value of But I'm not sure how the open-source community handles requests like this. Any advice on how to proceed? Or is this a closed/merged PR and conversation over?
After re-reading this I realized this is capturing the bug (alt+click conflict) as well as the feature request (new setting), I thought they were separate issues. to fix let's: Override the value of to be false when . Document this override in 's description, that also makes the name correct as this feature only ever works on alt+click. I think that name is good as it aligns with . we're a little tight on time as we're closing in on the end of the iteration, can handle it
Thanks, and I'm really looking forward to being able to click links in the terminal again.
/verified


Question: alwaysFocused: true, verticalScrollMode: ScrollbarVisibility.Visible, ariaLabel: nls.localize('treeAriaLabel', "Quick Picker"), <del> keyboardSupport: this.options.keyboardSupport </del> <ins> keyboardSupport: this.options.keyboardSupport, preventRootFocus: true </ins> }); this.treeElement = this.tree.getHTMLElement();

While testing . VSCode Version: Code - Insiders 1.15.0-insider (, 2017-08-01T05:07:59.267Z) OS Version: Darwin x64 16.7.0 Steps to Reproduce: 3 terminals from the command palette <kbdArrowDown</kbdto the last terminal in the switcher <kbdTab</kbdto rename the terminal -keyboard focus disappears from the input box (and seems to be nowhere). I need a second <kbdTab</kbdto move the keyboard focus to the rename action in the selected row. A single <kbdTab</kbdshould suffice.
This is also an issue with task configuration


Question: name: string; value: string; type?: string; <ins> language?: string; expression?: string; </ins> hasNamedChildren: boolean; indexedChildrenCount: number; extensionId: string;

similar to the 'open in data viewer' command from the jupyter variables view, we should allow extensions to contribute a view for a variables for specific language/types on the built in tree view.
That would essentially be number 6 in this screenshot from the Julia extension , right?
Same idea, either with an icon like that or through the context menu on that item. In the jupyter extension's case, we are planning to allow contributions for data viewers from extensions that didn't necessarily provide the variables.
Cool. I think icon and context menu would be great ;) It might also make sense to think a bit ahead there: there are probably some kind of viewers that are relevant for a lot of languages (tabular data, plots) and others that are very language specific. From our end, we would love it if VS Code at some point gained a generic tabular viewer, and a plot viewer that we could utilize and get rid of our custom implementations as well :) So maybe some kind of API design where in the future one could hook into a as of yet not existing generic tabular/plot viewer.
Example implementation here The menu contribution point name will likely change names when we expand the usage beyond notebooks, but any needed migration will be pretty straight forward.
I created a sample extension and cannot see any variables showing up. Do I need to enable something in VS Code for this feature to work. I couldn't find any settings/experiments that had to be enabled for this.
Found that I needed to enable a VS Code experiment (I was looking for Jupyter experiments). Not sure the API is useful in its current form. Currently when i create a viewer for DataFrames, lists, objects, anything I do not get the name of the variable. Hence I have no idea what I'm looking at, all I get is a value, and thats basically a stringified version of the value. Thus its not really possible to create any viewer, unless of course I'm missing something here.
Moving to March for now. Feel free to move back to February if the issue has been verified or once steps are provided and the issue is verifiable in the latest Insiders. Edit: I confirmed using the sample extension that the viewer does not report the variable name.


Question: name: string; value: string; type?: string; <ins> language?: string; expression?: string; </ins> hasNamedChildren: boolean; indexedChildrenCount: number; extensionId: string;

verification: sure you have jupyter and python extensions enabled the notebook variable view the or create your own some notebook cells that create variables and open the debug sidebar to see the notebook variable view that the command contributed to the menu is provided information about the variable ( should be the expression that would access that variable)


Question: import { BackLayerWebView } from 'vs/workbench/contrib/notebook/browser/view/renderers/backLayerWebView'; import { CodeCellRenderer, MarkupCellRenderer, NotebookCellListDelegate } from 'vs/workbench/contrib/notebook/browser/view/renderers/cellRenderer'; import { IAckOutputHeight, IMarkupCellInitialization } from 'vs/workbench/contrib/notebook/browser/view/renderers/webviewMessages'; <del> import { CodeCellViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/codeCellViewModel'; </del> <ins> import { CodeCellViewModel, outputDisplayLimit } from 'vs/workbench/contrib/notebook/browser/viewModel/codeCellViewModel'; </ins> import { NotebookEventDispatcher } from 'vs/workbench/contrib/notebook/browser/viewModel/eventDispatcher'; import { MarkupCellViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/markupCellViewModel'; import { CellViewModel, NotebookViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/notebookViewModelImpl';

<!-- 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. --Version: 1.78.0 (user setup) Commit: Date: 2023-05-03T20:09:00.748Z Electron: 22.4.8 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No I've reported a bug related jupyter notebook before . After new release of vs code this below bug happens. Steps to Reproduce: https://user- a Jupyter notebook file that contains some images. to view images and see what happens.
I'm not seeing this repro - can you try disabling all extensions and opening that same notebook to see if it still repros? Also check which renderer is being used for the image by selecting 'change presentation' in the output menu !
I've provided info about you asked in the video. extensions are disabled was using 1. as seen in the image and video. tried other renderer as well to show difference. another issue is; VS Code is scrolling down own its own when notebook is opened first time and loading of output started. It can be observed below in end of video as well. I cannot hold the page and have to scroll back by myself. !
How many images are you displaying there? (I still don't see it with 500, though perf takes a big hit) Does it repro with a smaller number of images? Like just displaying the same image 10 times.


Question: import { BackLayerWebView } from 'vs/workbench/contrib/notebook/browser/view/renderers/backLayerWebView'; import { CodeCellRenderer, MarkupCellRenderer, NotebookCellListDelegate } from 'vs/workbench/contrib/notebook/browser/view/renderers/cellRenderer'; import { IAckOutputHeight, IMarkupCellInitialization } from 'vs/workbench/contrib/notebook/browser/view/renderers/webviewMessages'; <del> import { CodeCellViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/codeCellViewModel'; </del> <ins> import { CodeCellViewModel, outputDisplayLimit } from 'vs/workbench/contrib/notebook/browser/viewModel/codeCellViewModel'; </ins> import { NotebookEventDispatcher } from 'vs/workbench/contrib/notebook/browser/viewModel/eventDispatcher'; import { MarkupCellViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/markupCellViewModel'; import { CellViewModel, NotebookViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/notebookViewModelImpl';

Do you know if all the images are being displayed? I see some suspicious collapsed borders in between a few. Can you try and reloading to check if there's a setting causing this? ( to default to switch back)
Alright, I have tried the way you told me and created new profile and didnt install anything at all. But it seems that doesnt change. I dont have a notebook that have few images. The notebook have 618 images as it could be seen in the video before images output says that 1/618, 2/618 .... 618/618. Those are the images is saved in storage after that they are being displayed. As far as i noticed those movements only occurs when notebook is being loaded. Because if load finishes that movement seem to stop as well. Another thing is there is something wrong about loading process as it could be seen in the video. I especially didnt use mouse's wheel not to confuse you, i only used scroll bar on the right. VS Code stops loading/showing images after some point untill i scroll down bottom and if i come back it suddenly appears. And i wanted to show how google colab loads in the browser.
<!-- 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!
are there verification steps for this?
verification steps a notebook and put a small image in your local workspace a cell with the code: the cell and wait for completion, (finished for me in a few seconds) , close, and re-open the notebook the images might take a bit to all render, but they shouldn't bump up and down once they are visible
Same bug (bumping up and down) still persists for me. Another thing is loading of images are stuck some point and it's fixed if i scroll down to bottom and come back. I showed and explained the bug which was in vscode.mp4 video and duration between 00:42-1:20.


Question: import { BackLayerWebView } from 'vs/workbench/contrib/notebook/browser/view/renderers/backLayerWebView'; import { CodeCellRenderer, MarkupCellRenderer, NotebookCellListDelegate } from 'vs/workbench/contrib/notebook/browser/view/renderers/cellRenderer'; import { IAckOutputHeight, IMarkupCellInitialization } from 'vs/workbench/contrib/notebook/browser/view/renderers/webviewMessages'; <del> import { CodeCellViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/codeCellViewModel'; </del> <ins> import { CodeCellViewModel, outputDisplayLimit } from 'vs/workbench/contrib/notebook/browser/viewModel/codeCellViewModel'; </ins> import { NotebookEventDispatcher } from 'vs/workbench/contrib/notebook/browser/viewModel/eventDispatcher'; import { MarkupCellViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/markupCellViewModel'; import { CellViewModel, NotebookViewModel } from 'vs/workbench/contrib/notebook/browser/viewModel/notebookViewModelImpl';

Version: 1.79.2 (user setup) Commit: Date: 2023-06-14T08:57:04.379Z Electron: 22.5.7 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
This fix is only on VS Code Insiders right now. It looks like you're still using the stable version.


Question: } } <ins> class GetStartedWithAccessibilityFeatures extends Action2 { static readonly ID = 'workbench.action.getStartedWithAccessibilityFeatures'; constructor() { super({ id: GetStartedWithAccessibilityFeatures.ID, title: localize2('getStartedWithAccessibilityFeatures', 'Get Started with Accessibility Features'), category: Categories.Help, f1: true, menu: { id: MenuId.MenubarHelpMenu, group: '1_welcome', order: 6 } }); } run(accessor: ServicesAccessor): void { const commandService = accessor.get(ICommandService); const accessibilityService = accessor.get(IAccessibilityService); commandService.executeCommand('workbench.action.openWalkthrough', accessibilityService.isScreenReaderOptimized() ? 'SetupScreenReader' : 'SetupAccessibility'); } } </ins> // --- Actions Registration if (KeybindingsReferenceAction.AVAILABLE) {

Screen reader and low vision (or other accessibility) users often use our menu items to discover things. We should include a menu item to open the getting started walkthrough under .
and WDYT?
Seems reasonable to me. The title suggests that it could also be a walkthrough, or part of an existing walkthrough. The tradeoff there would be discoverability.
I see an error in the console when opening accessible view from that welcome experience:
Cc
Related:


Question: } .monaco-button-dropdown > .monaco-button.monaco-dropdown-button { <ins> border: 1px solid var(--vscode-button-border, transparent); </ins> border-left-width: 0 !important; border-radius: 0 2px 2px 0; }


Question: "@vscode/windows-mutex": "^0.4.4", "@vscode/windows-process-tree": "^0.5.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-canvas": "0.6.0-beta.19", "@xterm/addon-image": "0.7.0-beta.17", "@xterm/addon-search": "0.14.0-beta.19", "@xterm/addon-serialize": "0.12.0-beta.19", "@xterm/addon-unicode11": "0.7.0-beta.19", "@xterm/addon-webgl": "0.17.0-beta.19", "@xterm/headless": "5.4.0-beta.19", "@xterm/xterm": "5.4.0-beta.19", </del> <ins> "@xterm/addon-canvas": "0.6.0-beta.20", "@xterm/addon-image": "0.7.0-beta.18", "@xterm/addon-search": "0.14.0-beta.20", "@xterm/addon-serialize": "0.12.0-beta.20", "@xterm/addon-unicode11": "0.7.0-beta.20", "@xterm/addon-webgl": "0.17.0-beta.20", "@xterm/headless": "5.4.0-beta.20", "@xterm/xterm": "5.4.0-beta.20", </ins> "graceful-fs": "4.2.11", "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2",

/gifPlease
Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, files are preferred as they are displayed inline on GitHub. You may find helpful as a browser-based gif recording tool. If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording ( in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue. Happy coding!
The terminal's usage of may have regressed?
The issue I'm seeing is no longer seems to flip the terminal link modifiers and column select modifier. Additionally the cursor isn't showing anymore when using column selection.
Actually I don't think it ever flipped the column select modifier
When is set, alt+click still opens fine. After the crosshair will be working as intended, the link pointer cursor will override it correctly.
! I can still repro if . Is there something else I should set? It works fine if I set .
Since verification steps are needed and is OOF, this issue will be moved to the February 2024 milestone.
in case you know the verifications steps.
I verified that regardless of the value of , I can open links in the terminal with ctrlCmd and holding alt allows me to do column selection, which I believe is by design.
It turns out that the bug has nothing to do with the cross cursor. The real cause was extension host keep crashing after a few minutes after opening a big TypeScript monorepo.


Question: } /** <ins> * Register an inlay hints provider. */ export function registerInlayHintsProvider(languageId: string, provider: modes.InlayHintsProvider): IDisposable { return modes.InlayHintsProviderRegistry.register(languageId, provider); } /** </ins> * Contains additional diagnostic information about the context in which * a [code action](#CodeActionProvider.provideCodeActions) is run. */

And we could use in browser.
Sorry, just confirm, Would this will be released in July (the next) version?


Question: } .monaco-tree .monaco-tree-row > .content.actions > .primary-action-bar .action-label { <del> margin-right: 0.2em; </del> <ins> margin-right: 0.4em; </ins> margin-top: 4px; background-repeat: no-repeat; width: 16px;

This is to track all the issues surrounding the terminal switcher for the August iteration. [x] move keyboard focus [x] add create new terminal option [x] add kill terminal actionbar item to entries and [x] fix tab focus for action items [x] fix focus on arrow keys [x] fix spacing between actionbar icons


Question: border-color: var(--vscode-textBlockQuote-border); } <ins> kbd { color: var(--vscode-editor-foreground); border-radius: 3px; vertical-align: middle; padding: 1px 3px; background-color: hsla(0,0%,50%,.17); border: 1px solid rgba(71,71,71,.4); border-bottom-color: rgba(88,88,88,.4); box-shadow: inset 0 -1px 0 rgba(88,88,88,.4); } .vscode-light kbd { background-color: hsla(0,0%,87%,.5); border: 1px solid hsla(0,0%,80%,.7); border-bottom-color: hsla(0,0%,73%,.7); box-shadow: inset 0 -1px 0 hsla(0,0%,73%,.7); } </ins> ::-webkit-scrollbar { width: 10px; height: 10px;

Similar to GitHub style or Keyboard Shortcuts GUI: <kbdCtrl</kbd


Question: return false; }); <del> let nextWidget: ReviewZoneWidget; if (idx === this._commentWidgets.length) { nextWidget = this._commentWidgets[0]; } else { nextWidget = sortedWidgets[idx]; </del> <ins> const nextWidget: ReviewZoneWidget | undefined = sortedWidgets[idx]; if (nextWidget !== undefined) { this.editor.setSelection(nextWidget.commentThread.range ?? new Range(1, 1, 1, 1)); nextWidget.reveal(undefined, CommentWidgetFocus.Widget); </ins> } <del> this.editor.setSelection(nextWidget.commentThread.range ?? new Range(1, 1, 1, 1)); nextWidget.reveal(undefined, CommentWidgetFocus.Widget); </del> } public previousCommentThread(): void {

Type: <bBug</bCC (alt+F9) does not stop at the last comment. It cycles back to the first comment once it reaches the end. This is especially confusing for screen reader users because pressing alt+F9 multiple times does not always guarantee the last comment position. Please make stop at the last comment position. Of course, (alt+shift+F9) has the same issue. ! VS Code version: Code - Insiders 1.93.0-insider (, 2024-08-20T08:04:15.567Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (128)</summaryExtensionVersion ------ vscode-openapi4.28.1 zotenote1.0.1 android-dev-ext1.4.0 aiprm-lang0.0.2 Bookmarks13.5.0 openscad1.2.2 spellright3.0.136 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.6.0 external-pdf1.2.0 doxdocgen1.4.0 vscode-markdownlint0.53.0 vscode-eslint3.0.10 vscode-quick-select0.2.9 vscode-deno3.38.2 gitlens14.6.1 EditorConfig0.16.4 prettier-vscode10.1.0 figma-vscode-extension0.3.5 vscode-firefox-debug2.9.10 shell-format7.2.5 vscode-google-translate1.4.13 codespaces1.17.2 copilot1.223.1058 copilot-chat0.20. remotehub0.62.0 vscode-github-actions0.26.2 vscode-pull-request-github0.95.


Question: return false; }); <del> let nextWidget: ReviewZoneWidget; if (idx === this._commentWidgets.length) { nextWidget = this._commentWidgets[0]; } else { nextWidget = sortedWidgets[idx]; </del> <ins> const nextWidget: ReviewZoneWidget | undefined = sortedWidgets[idx]; if (nextWidget !== undefined) { this.editor.setSelection(nextWidget.commentThread.range ?? new Range(1, 1, 1, 1)); nextWidget.reveal(undefined, CommentWidgetFocus.Widget); </ins> } <del> this.editor.setSelection(nextWidget.commentThread.range ?? new Range(1, 1, 1, 1)); nextWidget.reveal(undefined, CommentWidgetFocus.Widget); </del> } public previousCommentThread(): void {

cloudcode2.16.4 overleaf-workshop0.13.2 cslpreview0.2.2 path-autocomplete1.25.0 latex-workshop10.1.0 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 commitlint2.6.0 language-julia1.109.1 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 language-matlab1.2.5 zotero0.1.11 git-graph1.30.0 azure-dev0.8.3 vscode-azureappservice0.25.2 vscode-azurecontainerapps0.6.1 vscode-azurefunctions1.15.2 vscode-azureresourcegroups0.8.3 vscode-azurestaticwebapps0.12.2 vscode-azurestorage0.16.0 vscode-azurevirtualmachines0.6.5 vscode-cosmosdb0.22.0 vscode-docker1.29.2 vscode-edge-devtools2.1.5 black-formatter2024.3. debugpy2024.11. flake82023.13. isort2023.13. python2024.13. vscode-pylance2024.8.101 jupyter2024.8. jupyter-keymap1.1.2 jupyter-renderers1.0.19 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.381.0 remote-ssh0.114. remote-ssh-edit0.86.0 remote-wsl0.81.8 vscode-remote-extensionpack0.25.0 azure-account0.12.0 azure-repos0.38.0 cmake-tools1.18.44 cpptools1.21.6 cpptools-extension-pack1.3.0 js-debug-nightly2024.8.1517 powershell2024.3.2 remote-explorer0.5. remote-repositories0.40.0 remote-server1.6.


Question: return false; }); <del> let nextWidget: ReviewZoneWidget; if (idx === this._commentWidgets.length) { nextWidget = this._commentWidgets[0]; } else { nextWidget = sortedWidgets[idx]; </del> <ins> const nextWidget: ReviewZoneWidget | undefined = sortedWidgets[idx]; if (nextWidget !== undefined) { this.editor.setSelection(nextWidget.commentThread.range ?? new Range(1, 1, 1, 1)); nextWidget.reveal(undefined, CommentWidgetFocus.Widget); </ins> } <del> this.editor.setSelection(nextWidget.commentThread.range ?? new Range(1, 1, 1, 1)); nextWidget.reveal(undefined, CommentWidgetFocus.Widget); </del> } public previousCommentThread(): void {

vscode-github-issue-notebooks0.0.130 vscode-node-azure-pack1.2.0 vscode-selfhost-test-provider0.3.25 vscode-serial-monitor0.12.0 vscode-speech0.10.0 vscode-speech-language-pack-en-ca0.4.0 vscode-speech-language-pack-en-gb0.4.0 vscode-speech-language-pack-ko-kr0.4.0 vsliveshare1.0.5936 windows-ai-studio0.4.0 autodocstring0.6.1 pandocciter0.10.4 publisher1.1.5 shiny1.0.0 shinyuieditor0.5.0 quarto1.114.0 r-debugger0.5.4 java1.33.0 vscode-xml0.27.1 vscode-yaml1.14.0 r2.8.4 multi-command1.6.0 AudioQ0.0.2 vscode-deepl1.1.1 abc-music0.4.0 lua3.10.5 latex-utilities0.4.14 cmake0.0.17 vscode-terminal-here0.2.4 windows-terminal0.7.0 errorlens3.16.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-conventional-commits1.25.0 vscode-arduino0.7.0 vscode-gradle3.16.4 vscode-java-debug0.58.0 vscode-java-dependency0.24.0 vscode-java-pack0.29.0 vscode-java-test0.42.0 vscode-maven0.44.0 zotero-cite0.8.6 markdown-all-in-one3.6.2 grammarly0.25.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
i'm wondering if we were to announce "comment 1 of 3, 2 of 3, 3 of 3" etc., that would be a sufficient workaround?
-- Adding the index number would be really helpful! However, that is a separate feature enhancement and I would prefer not to wrap once it reaches the end. At least, a simple bell sound needs to be played when it wraps.


Question: previewManager.activePreview?.zoomOut(); })); <ins> disposables.push(vscode.commands.registerCommand('imagePreview.copyImage', () => { previewManager.activePreview?.copyImage(); })); </ins> return vscode.Disposable.from(...disposables); }

<!-- 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: Version: 1.74.3 (on ) OS Version: Linux, Gnome, Chrome Steps to Reproduce: an image in the media-preview extension click on the image and select copy to paste the image somewhere Nothing happens. Also note that Cut and Paste make no sense here as menu items. I assume that these are just the default context menu options from - perhaps these should be removed entirely from the preview extension and we could manually implement copy?
Hey I would like to work on this issue.
assign this to me
Are these the correct steps to reproduce the issue? I'm unable to verify it on my mac. Can you provide more information? I previewed the image and then copied and pasted it. <img width="950" alt="image" src="https://user-"
I would like to wokr on this issue.
I would like to try solving this issue.
You right-click an image and select "copy", then you click a folder in VSCode's explorer and select "paste". The image should be pasted into that folder but it doesn't.
I would like to work on this issuse. here, I tried to copy and paste (Ctrl+v) it. But it doesn't work. https://user-
After a day of researching, I think I can explain why this issue happens.


Question: previewManager.activePreview?.zoomOut(); })); <ins> disposables.push(vscode.commands.registerCommand('imagePreview.copyImage', () => { previewManager.activePreview?.copyImage(); })); </ins> return vscode.Disposable.from(...disposables); }

Basically in the core webview module (see ), three default context menu actions (cut, copy and paste) are to the menu, which are accessible throughout all webviews, and happens to be one of them, so after you right-click anywhere in a image previewer, you will be able to see these three actions. After you clicks one of these actions, the editor will post an message to the image previewer, telling it to cut, copy or paste. If there is a correspondent listener for this perpose, the image will be actually cut, copied, pasted, but unfortunately there is no such listeners defined. This problem has existed for quite a bit of time. The original modification that cause this problem is from here . It is origianlly meant to allow users to copy selected text within an extension's README page. There is also a closed issue that describe such issue in . Personally I think providing action cut, copy and paste for all webviews is a little bit hasty, since there are not universally required for each webview, and even some of them need, the subject to be copied may vary from different webviews, or even different places in a same webview. I can solve it by disabling the default actions first (there is a option to achieve this), then let image previewer to implement its own copy and cut functionality, but I think this is rather a quick and sloppy solution. There should be another better way to solve this issue.
What about adding a handler :
Here's what I tried VSC insiders without any extensions Open a folder with a .png file Open the png file in vscode Right click and select Paste into folder in vscode = does not work Paste into markdown cell in vscode = does not work What am i doing wrong?
Pasting image data into folders isn't supported by VS Code. Pasting into a notebook cells works fine for me though. To verify though you can also paste into an external image editor


Question: disturl "https://electronjs.org/headers" <del> target "25.8.0" ms_build_id "23503258" </del> <ins> target "25.8.1" ms_build_id "23779380" </ins> runtime "electron" build_from_source "true"

Version 1.74.0, when I open the developer tools, it becomes a floating window, which is very unfriendly for extension developers, please add at least one option to use the old layout. !
Was caused by an upstream electron bug with WCO Believe there are plans to restore the docking feature in the near future now that the electron issue is resolved.
I found that if you toggle OFF the setting, Developer Tools docking functionality is restored AND you also still get the WCO experience (perhaps that's a separate bug?). Suggest docking at the bottom instead of to the right if there's any visual conflict due to the aforementioned electron bug.
It work, thanks!.
The setting will be removed at one point, keeping the issue open to provide and dock options when WCO is enabled.
I manged to get it to dock again with 's workaround but I noticed in the dev tool now it shows the HTML for the VS code app instead of the file I have open in the preview !
Related Stack Overflow question:
This makes working on Windows really awful for me, I think the upstream bug is fixed.
To give some context, with WCO chromium has a bug in orienting devtools window when docked to the position where the Window controls are, basically they overlap making it harder to use the close, minimize or maximize button. Chromium always pop out the devtools window in PWA for this scenario and Electron inherited this by default. The fix in does not address the aligning behavior but rather provides a workaround that calling would be respected even in the WCO scenario rather than forcing to always detach. Now, on our end to incorporate this fix we need to change all our callsite with a mode otherwise we will default to detach as seen in this logic Say we chose as default and user later reposition it to right or left then this new state will be persisted to json file under the user data directory, in non WCO cases this saved preference will be applied next time when calling or without a mode value from the application side, that is how user's preferred position is applied. But in the WCO case, this does not take effect so we need a logic on VSCode side to read the preference value and adjust the start mode with it. I didn't want to make this change yet in core hence this issue remains open, I will tackle it in debt week.


Question: disturl "https://electronjs.org/headers" <del> target "25.8.0" ms_build_id "23503258" </del> <ins> target "25.8.1" ms_build_id "23779380" </ins> runtime "electron" build_from_source "true"

I see this as an issue when you dock the devtools to the right, but why is the ability to dock it at the bottom taken away? This seems to work just fine with WCO. But on Windows, a user is not able to reposition the devtools at all? This functionality seems to be truly gone, so a setting for Windows only would be a decent workaround and good improvement over what we have today. If we decide on a setting that forces the location, I can see to do such a change.
I am good with a setting to force the bottom position only on Windows. I will see if the runtime behavior can be improved to avoid docking the devtools to the position where the controls are present as part of this issue.
The dock options are back, though setting it to dock on the right looks funny with the WCO in the way. !
Yes that is the original bug in chromium which is not addressed.
In the new version, if the developer tools are on the right side, the close button will be blocked, which is not as good as the old version of . !
use a dock position that is not overlapping with the window controls, by default the devtools will not dock to the position were the window controls are to avoid the bug.
I know, but I always put the developer tools on the right, which is where I'm most productive.
Is it possible to revert "window.experimental.windowControlsOverlay.enabled" to a VS Code new version? In order for the developer tools to be correctly positioned on the right side, I now have to go back to VS Code version 1.81 and disable updates. !
is there an issue where we are tracking how the WCO is overlapping the devtools?
no we are not tracking it in the runtime, unless you have manually docked it to the overlapping position devtools by default would be undocked. The overlapping position in the runtime will not resolved anytime soon.


Question: if (event.affectsConfiguration(TitlebarPart.configCommandCenter)) { this.updateTitle(); this._onDidChangeCommandCenterVisibility.fire(); <ins> this._onDidChange.fire(undefined); </ins> } }

Toggling the command center works, but the title bar height is stuck until the window is resized. I also noticed some issues where I had to click twice to open the command center once enabled. The command center input then disappears while the command center quick pick opens.
Maybe an electron update regression


Question: } const outputs = viewCell.outputsViewModels; <del> for (const output of outputs) { </del> <ins> for (const output of outputs.slice(0, outputDisplayLimit)) { </ins> const [mimeTypes, pick] = output.resolveMimeTypes(this.textModel!, undefined); if (!mimeTypes.find(mimeType => mimeType.isTrusted) || mimeTypes.length === 0) { continue;


Question: } const outputs = viewCell.outputsViewModels; <del> for (const output of outputs) { </del> <ins> for (const output of outputs.slice(0, outputDisplayLimit)) { </ins> const [mimeTypes, pick] = output.resolveMimeTypes(this.textModel!, undefined); if (!mimeTypes.find(mimeType => mimeType.isTrusted) || mimeTypes.length === 0) { continue;


Question: } const outputs = viewCell.outputsViewModels; <del> for (const output of outputs) { </del> <ins> for (const output of outputs.slice(0, outputDisplayLimit)) { </ins> const [mimeTypes, pick] = output.resolveMimeTypes(this.textModel!, undefined); if (!mimeTypes.find(mimeType => mimeType.isTrusted) || mimeTypes.length === 0) { continue;


Question:
<textarea name="description" id="description" placeholder="${escape(localize('details', "Please enter details."))}" required></textarea>

${escape(localize('descriptionEmptyValidation', "A description is required."))}

${escape(localize('descriptionTooShortValidation', "Please provide a longer description."))}

To prevent issues like this: and like this and many more
this is a good idea, I've been getting tagged in a lot of these recently. it's difficult to say what exactly the limit/requirements should be though. atm we require title and description (the rest of the info is fluff that is auto included). Maybe force description to be longer than 10 characters?
We can start with 10characters enforced on both title & body and see how issues keep coming. We could also maybe crowd-source ideas from the team


Question: import { IExtHostRpcService } from 'vs/workbench/api/common/extHostRpcService'; import { ISelection } from 'vs/editor/common/core/selection'; import { TestItemImpl } from 'vs/workbench/api/common/extHostTestingPrivateApi'; <ins> import { VSBuffer } from 'vs/base/common/buffer'; import { SerializableObjectWithBuffers } from 'vs/workbench/services/extensions/common/proxyIdentifier'; </ins> interface CommandHandler { callback: Function;

Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this


Question: weight = KeybindingWeight.ExternalExtension + idx; } <ins> let commandAction = MenuRegistry.getCommand(command); let precondition = commandAction && commandAction.precondition; let fullWhen: ContextKeyExpr | undefined; if (when && precondition) { fullWhen = ContextKeyExpr.and(precondition, ContextKeyExpr.deserialize(when)); } else if (when) { fullWhen = ContextKeyExpr.deserialize(when); } else if (precondition) { fullWhen = precondition; } </ins> let desc: IKeybindingRule2 = { id: command, args, <del> when: ContextKeyExpr.deserialize(when), </del> <ins> when: fullWhen, </ins> weight: weight, primary: KeybindingParser.parseKeybinding(key, OS), mac: mac ? { primary: KeybindingParser.parseKeybinding(mac, OS) } : null,

contribute command that uses enablement assign a keybinding, via :bug: enablement isn't honoured
When users configure keybindings we allow them to change preconditions as well, e.g rename requires an editable document so I don't plan to have a different strategy for contributed commands
I don't see the nice "Command 'Hello World' is not enabled in the current context." info toast when I try the keybinding though. I only see that message when I try to run it from the command palette. The command correctly doesn't run when not enabled though.
Yeah, that's the design. Keybindings don't show messages


Question: // Note: When this action is executed from the process explorer, a config is passed. For all // other cases it is run with no arguments. <del> public run(config?: IConfig): Promise<any> { if (config && 'type' in config && 'request' in config) { return this.debugService.startDebugging(undefined, config, this.isNoDebug()); } </del> <ins> public run(): Promise<any> { </ins> const configurationManager = this.debugService.getConfigurationManager(); let launch = configurationManager.selectedConfiguration.launch; if (!launch || launch.getConfigurationNames().length === 0) {

Somehow I missed the change in the and only now found it out. What I do not udnerstand is why we need all this code? I think this handler should be removed and the action should be called like it was done previously. Code pointer: It would be great if we could tackle this in December. Thanks
The reason for this code change was that creates a handler for command that passes no arguments to the action: So instead I used with a handler that would forward the argument. It looks like there are other debug commands registered in this way in , so I think moving the code for startDebug there makes sense. The handlers there are shorter and less generic, I'll see if rewriting the startDebug one that way causes any issues
what you need is calling the start debug with a configuration, and I believe we already have a way for doing this. can you please provide a pointer to where you are already calling start debug with a configuration. are you calling start debug from the main side or where from exactly? I can also look into this. You can just let me know how to verify that I did not break your scenario.
The extension API's implementation passes a debug configuration to the debug service's startDebugging here:
I'm trying to start debugging from the process explorer. Since it's a separate browser window, it doesn't have access to the debug workbench service, and it's also not an extension, so it can't leverage the extension API for starting debugging. Currently, the process explorer window sends an IPC message back to the issue service in the main process. This then sends an IPC message to the main renderer process to run the debug start command: The path is also used by the native menu to trigger commands from the main process.
ok got it. So the best way it seems is to what you have done going via the action. Can you try to clean up the handler. And if that does not work I can look into an alternative solution.
Sure, I'll work on cleaning up the handler today


Question: * ------------------------------------------------------------------------------------------ */ 'use strict'; <del> import { env, languages, commands, workspace, window, ExtensionContext, Memento, IndentAction, Diagnostic, DiagnosticCollection, Range, DocumentFilter, Disposable } from 'vscode'; </del> <ins> import { env, languages, commands, workspace, window, ExtensionContext, Memento, IndentAction, Diagnostic, DiagnosticCollection, Range, DocumentFilter, Disposable, Uri } from 'vscode'; </ins> // This must be the first statement otherwise modules might got loaded with // the wrong locale.

VS Code does not report errors in , and then silently drops the ball without telling the user. This is particularly annoying since some things might continue working, while others mysteriously stop. Errors in come in two flavours – actual syntactical errors, but also unrecognized new properties. In particular the latter is annoying, for example when TypeScript adds new features such as (see ). My suggestion would be to at least visibly and loudly report this, but preferably be more lenient about what's accepted (e.g. unrecognized properties).
FYI
+1 I had a similar issue (non existing compiler option) and I didn't get why my configured target=es6 got not accepted. Interestingly, it worked when compiling over command line but it failed when compiling over tsserver. See also the TS compiler code. Maybe one could get that error from tsserver back to VS code?
+1 I've just had a similar issue that I've spent 3 hours working through. Adding a new typescript 2 option such as "noUnusedParameters" caused vscode to reference not , making some of my code have errors in the editor, but not when built! I've worked around by having a different that I used for building with.
See


Question: resolved "https://registry.yarnpkg.com/vscode-textmate/-/vscode-textmate-7.0.1.tgz#8118a32b02735dccd14f893b495fa5389ad7de79" integrity sha512-zQ5U/nuXAAMsh691FtV0wPz89nSkHbs+IQV8FDk+wew9BlSDhf4UmWGlWJfTR2Ti6xZv87Tj5fENzKf6Qk7aLw== <del> xterm-addon-search@0.9.0-beta.39: version "0.9.0-beta.39" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.39.tgz#e8376e1485ee7d763c07d1a8f1354114f65b3e3e" integrity sha512-h45wkecgfqXXoAUqgNytAfSd6g0xNT6rZy/enVaEU0aes7QoL9pxHUKkCry8PP6hs03Slk0VxQ4AGsbSZGvK/w== </del> <ins> xterm-addon-search@0.9.0-beta.41: version "0.9.0-beta.41" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.41.tgz#0992da36fe01ff6d71449265a9dabeef7f9d0a3f" integrity sha512-b1vuWR5JZ8QIiObbKkwSzpzf4x0B9hdzGCHJG+PXWT/xbxk65DOe/X9rgrRyOnCWe5ylQGG4DIHTiREigTp0lg== </ins> xterm-addon-unicode11@0.4.0-beta.3: version "0.4.0-beta.3" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.4.0-beta.3.tgz#f350184155fafd5ad0d6fbf31d13e6ca7dea1efa" integrity sha512-FryZAVwbUjKTmwXnm1trch/2XO60F5JsDvOkZhzobV1hm10sFLVuZpFyHXiUx7TFeeFsvNP+S77LAtWoeT5z+Q== <del> xterm-addon-webgl@0.12.0-beta.41: version "0.12.0-beta.41" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.41.tgz#17dbca975b6e9b34526ebc57f4de59ee295da1b6" integrity sha512-wvQxC5diMYEJEMaILfz+4CWB2GgtzjzNQRNDnK7R7Y9wDI+P4idDlQKgyH0nA93sl9R4zgqlBVha//wuq4vfZg== </del> <ins> xterm-addon-webgl@0.12.0-beta.43: version "0.12.0-beta.43" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.43.tgz#916ed4e390371403aab0d277097cd8a61be436e8" integrity sha512-hGXfwT6TOmp0tBDiS/iF8s0SLHLd3shJ5zQyS4HNtq99B5cEhHhwaUAZAfjLt5rnUt0kvqR9YWtGsDux5dWVLA== </ins> <del> xterm@4.19.0-beta.60: version "4.19.0-beta.60" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.60.tgz#de89d93153ae3ec17b53f3e5d03b8ea859126081" integrity sha512-YQjvp4xtSAyNm9+gF4OA5+QzkSWdKMCy4WABETpe7CsrEGx+mJVoXCZ9wgopmvwRXz7DeJvKM5dWz1HPjVLDtA== </del> <ins> xterm@4.19.0-beta.67: version "4.19.0-beta.67" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.67.tgz#9a7d79be64469c91bb693b9f5a50b5a22e921cd3" integrity sha512-4bYTnT6g91N5QId1qPaiSvkpsxMQYpuPdPJItvBZFOcQLTuFSX85x5NeFuDvhNqi33eMFPimyGhzH/JvAV1v/Q== </ins>

https://user-
Related ,
happening bc the first line's marker isn't disposed of (and thus the decoration isn't either) !
so maybe we should have some API on xterm like so that can be handled specially?
oh here's the issue that solved but looks like that actually wasn't solved anyway
Just to confirm, to verify this issue, are you typing commands followed by the clear command in between? Or are you clearing the terminal another way?
Typing and clearing
Pretty sure this is the command, not run in the terminal


Question: resolved "https://registry.yarnpkg.com/vscode-textmate/-/vscode-textmate-7.0.1.tgz#8118a32b02735dccd14f893b495fa5389ad7de79" integrity sha512-zQ5U/nuXAAMsh691FtV0wPz89nSkHbs+IQV8FDk+wew9BlSDhf4UmWGlWJfTR2Ti6xZv87Tj5fENzKf6Qk7aLw== <del> xterm-addon-search@0.9.0-beta.39: version "0.9.0-beta.39" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.39.tgz#e8376e1485ee7d763c07d1a8f1354114f65b3e3e" integrity sha512-h45wkecgfqXXoAUqgNytAfSd6g0xNT6rZy/enVaEU0aes7QoL9pxHUKkCry8PP6hs03Slk0VxQ4AGsbSZGvK/w== </del> <ins> xterm-addon-search@0.9.0-beta.41: version "0.9.0-beta.41" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.41.tgz#0992da36fe01ff6d71449265a9dabeef7f9d0a3f" integrity sha512-b1vuWR5JZ8QIiObbKkwSzpzf4x0B9hdzGCHJG+PXWT/xbxk65DOe/X9rgrRyOnCWe5ylQGG4DIHTiREigTp0lg== </ins> xterm-addon-unicode11@0.4.0-beta.3: version "0.4.0-beta.3" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.4.0-beta.3.tgz#f350184155fafd5ad0d6fbf31d13e6ca7dea1efa" integrity sha512-FryZAVwbUjKTmwXnm1trch/2XO60F5JsDvOkZhzobV1hm10sFLVuZpFyHXiUx7TFeeFsvNP+S77LAtWoeT5z+Q== <del> xterm-addon-webgl@0.12.0-beta.41: version "0.12.0-beta.41" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.41.tgz#17dbca975b6e9b34526ebc57f4de59ee295da1b6" integrity sha512-wvQxC5diMYEJEMaILfz+4CWB2GgtzjzNQRNDnK7R7Y9wDI+P4idDlQKgyH0nA93sl9R4zgqlBVha//wuq4vfZg== </del> <ins> xterm-addon-webgl@0.12.0-beta.43: version "0.12.0-beta.43" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.43.tgz#916ed4e390371403aab0d277097cd8a61be436e8" integrity sha512-hGXfwT6TOmp0tBDiS/iF8s0SLHLd3shJ5zQyS4HNtq99B5cEhHhwaUAZAfjLt5rnUt0kvqR9YWtGsDux5dWVLA== </ins> <del> xterm@4.19.0-beta.60: version "4.19.0-beta.60" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.60.tgz#de89d93153ae3ec17b53f3e5d03b8ea859126081" integrity sha512-YQjvp4xtSAyNm9+gF4OA5+QzkSWdKMCy4WABETpe7CsrEGx+mJVoXCZ9wgopmvwRXz7DeJvKM5dWz1HPjVLDtA== </del> <ins> xterm@4.19.0-beta.67: version "4.19.0-beta.67" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.67.tgz#9a7d79be64469c91bb693b9f5a50b5a22e921cd3" integrity sha512-4bYTnT6g91N5QId1qPaiSvkpsxMQYpuPdPJItvBZFOcQLTuFSX85x5NeFuDvhNqi33eMFPimyGhzH/JvAV1v/Q== </ins>

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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: 1.50.1 OS Version: 10.15.7 Steps to Reproduce: system input source to shuangpin, before which add shuangpin as an input source. ! caps lock, with caps lock unlock, you will input Chinese character, which is an expected behavior. something in the integrated terminal, I can only input upper case letters. But when I input something in editor or some other application, I can input lower case letters. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes. Actually I think it might be the problem of might decide the letters by cap lock. This is not as expected with shuangpin mode.
This looks like an upstream issue in
Thanks for replying. Opened an issue for


Question: private readonly _onDispose = this._register(new Emitter<void>()); readonly onDispose = this._onDispose.event; <del> readonly capabilities = 0; </del> <ins> readonly capabilities = WorkingCopyCapabilities.None; </ins> readonly name = basename(this.resource);

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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: head OS Version: n/a This is a bug/inconsistency in the VSC codebase, which is currently obscured because of the specific way the code is written. This wouldn't really matter, but when using a build step that generates files for dependencies, the gets evaluated down to and compilation fails. And overall, it'd be nice for the types to align in a sensible way. Steps to Reproduce: , replace with Expected: compiles fine Actual: there are a number of errors like Property 'getFirstLineText' does not exist on type 'never'. The intersection 'this & IResolvedTextFileEditorModel' was reduced to 'never' because property 'capabilities' has conflicting types in some (2339)TextFileEditorModelIWorkingCopyIResolvedTextFileEditorModelthis.isResolved() is known to be true) says capabilities should be a readonly 2. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Since this seems to concern only you with your specific setup, wanna do a PR to fix this?
I would be more than happy to, but I'm not sure what approach you'd find (in)appropriate. could type in as a number instead of an enum (since checks against it are anyways done via bitwise-and) could change in to actually be 2 instead of 0 (though it seems like you also use 0 for this field in other places like , and somehow TSC doesn't care...) could add a enum value of 0 to , since it seems like that's how you use it. I'm leaning towards approach 3. What are your thoughts?
Yeah I think we can give 3. a try in a PR.


Question: "when": "false" } ], <del> "webview/context": [ { "command": "notebook.cellOutput.copy", "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ] </del> <ins> "webview/context": [ { "command": "notebook.cellOutput.copy", "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ] </ins> } }, "scripts": {

Type: <bBug</bI have noticed two problems with my vscode-insiders installation which I assume may form one issue. a notebook in nbformat 4.5 is opened, new cells do not receive cell ids, even though this is required by the format spec and is a documented feature of vscode: a new notebook is created, the format is always 4.2. I am not sure whether this is expected. Steps to reproduce: a notebook with jupyterlab or any other way (jupytext etc.), and verify that it has nbformat = 4.5 the notebook in vscode, and generate a new cell, then save. the JSON of the saved notebook - the new cell does not have a cell id. Some additional points which may be of interest The issue persists when all extensions except jupyter/python are disabled. I have recent versions of nbformat etc. installed, but I would assume this is bundled with vscode anyway. The issue also exists on the current pre-release version of the jupyter extension. I haven't found any configuration option which would enable or disable support of notebook formats 4.2 Maybe I have missed a configuration option which I should have set? VS Code version: Code - Insiders 1.84.0-insider (, 2023-10-23T05:33:33.712Z) OS version: Linux x64 6.2.0-35-generic Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (18)</summaryExtensionVersion ------ vscode-neovim0.9.1 vscode-eslint2.4.2 githistory0.6.20 fuzzy-search0.0.3 black-formatter2023.5. python2023.19. vscode-pylance2023.7.40 jupyter2023.10. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 remote-ssh0.107. remote-ssh-edit0.86.0 remote-explorer0.5. remote-server1.5.


Question: "when": "false" } ], <del> "webview/context": [ { "command": "notebook.cellOutput.copy", "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ] </del> <ins> "webview/context": [ { "command": "notebook.cellOutput.copy", "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ] </ins> } }, "scripts": {

even-better-toml0.19.2 my-vscode-utils0.0.2 pyexec0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thank you for filing this issue and sorry you are running into this. I can replicate this at my end as well. Will look into this.


Question: export interface IActiveEditorActions { readonly actions: IToolbarActions; <del> readonly onDidChange: Event<IMenuChangeEvent>; </del> <ins> readonly onDidChange: Event<IMenuChangeEvent | void>; </ins> } export interface IEditorGroup {

Steps: begin with multi tabs showing open an editor hide tab bar actions move to the top close editor open same editor actions are not visible anymore, there is just a "..." <img width="1348" alt="image" src=""
When creating the editor actions we rely on the event to tell us when actions change. However, this event is not set when there is no active pane. In that case we should have a different event trigger the onDidChange event such as onDidChangeActiveEditor for example


Question: './foo', '../foo', '/foo/bar', <del> 'foo/bar' </del> <ins> '/foo/bar+more', 'foo/bar', 'foo/bar+more', </ins> ]; const windowsLinks = [

Issue Type: <bBug</bnew VSCode window new Terminal terminal: terminal: in Cmd and mouse over the two listing name. Only the /tmp/Foo.h will be clickable. won't be because of the . VS Code version: Code 1.43.0 (, 2020-03-09T19:34:44.548Z) OS version: Darwin x64 19.3.0 <!-- generated by issue reporter --
/duplicate


Question: */ getBoundaryScore?(length: number): number; } <del> export class SequenceFromIntArray implements ISequence { constructor(private readonly arr: number[]) { } getElement(offset: number): number { return this.arr[offset]; } get length(): number { return this.arr.length; } } </del>

Diffing the files: original: modified: <img width="1127" alt="image" src="https://user-"It would be better to line up things differently and give preference to having lines with smaller indent be boundary lines. fyi
Very nice idea!! Very valuable example. I can implement this in the experimental diffing algorithm, and soon we can discuss to deprecate the smart diffing algorithm ().
Implemented in the experimental diff algorithm (not smart). Let's try to deprecate the smart diff algorithm in favor of the experimental in the next milestones.
Closing, as this is implemented in the experimental diff algorithm, which is now the default. To verify, try it out in the playground:


Question: import { extHostNamedCustomer } from 'vs/workbench/api/common/extHostCustomers'; import { revive } from 'vs/base/common/marshalling'; import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; <ins> import { SerializableObjectWithBuffers } from 'vs/workbench/services/extensions/common/proxyIdentifier'; </ins> @extHostNamedCustomer(MainContext.MainThreadCommands) export class MainThreadCommands implements MainThreadCommandsShape {


Question: import { LiveTestResult } from 'vs/workbench/contrib/testing/common/testResult'; import { ITestResultService } from 'vs/workbench/contrib/testing/common/testResultService'; import { IMainThreadTestController, ITestRootProvider, ITestService } from 'vs/workbench/contrib/testing/common/testService'; <del> import { CoverageDetails, ExtensionRunTestsRequest, IFileCoverage, ITestItem, ITestMessage, ITestRunProfile, ITestRunTask, ResolvedTestRunRequest, TestResultState, TestsDiffOp } from 'vs/workbench/contrib/testing/common/testTypes'; </del> <ins> import { CoverageDetails, ExtensionRunTestsRequest, IFileCoverage, ITestItem, ITestMessage, ITestRunProfile, ITestRunTask, ResolvedTestRunRequest, TestResultState, TestRunProfileBitset, TestsDiffOp } from 'vs/workbench/contrib/testing/common/testTypes'; </ins> import { IExtHostContext, extHostNamedCustomer } from 'vs/workbench/services/extensions/common/extHostCustomers'; import { ExtHostContext, ExtHostTestingShape, ILocationDto, ITestControllerPatch, MainContext, MainThreadTestingShape } from '../common/extHost.protocol';

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.86 OS Version: macOS 14.3 Steps to Reproduce: run profile programmatically with isDefault = false seems to restore the previously selected state "isDefault", or if there is none, makes the first profile "Default". behavior works for me. But unfortunately after the profile is created and before its state is changed manually in the UI, it reports isDefault = false. Expected: isDefault matches the UI state at all times. //
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This works for me, but note that the synchronization of the new profile is asynchronous after its creation. This is intentional because it's common for extensions to create a profile and then set its properties, like we don't want to cause that to override what the user previously set (especially since making isDefault a 'live' property was a later addition to the API). For me, adding a listener like triggers shortly after its creation
Fascinating! I can't reproduce this bug today.
It seems like there is some inconsistency here
A simple snippet like this surfaces the issue for me: The console is saying And the GUI has run 1 as (Default)
Looks like this is working now:


Question: private didLayout = false; private emptyViews: ISplitViewView<{ top: number; left: number }>[] | undefined; private readonly splitViewDisposables = new DisposableStore(); <del> private centeredLayoutFixedWidth = true; </del> constructor( private container: HTMLElement, private view: IView, <del> public state: CenteredViewState = { ...defaultState } </del> <ins> public state: CenteredViewState = { ...defaultState }, private centeredLayoutFixedWidth: boolean = false </ins> ) { this.container.appendChild(this.view.element); // Make sure to hide the split view overflow like sashes #52892

<!-- 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.78.0 OS Version: Windows 10 (x64) Steps to Reproduce: "Centered Layout". the editor by independently moving its sashes (holding down Alt). and restart VS Code. The position used to be remembered in previous versions, but starting with version 1.76, the position gets reset on every start. Only the width is being remembered. It's still broken in the current insider build of VS Code 1.78.0.
Do we already know, which commit causes this regression?
I looked through the commits for 1.76.0 and I suspect it was .
Yeah, it is solved for me.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.8.0: version "25.8.0" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.0.tgz#60c84f1f256924ac5a0aff13276b901b0c43767a" integrity sha512-T3kC1a/3ntSaYMCVVfUUc9v7myPzi6J2GP0Ad/CyfWKDPp054dGyKxb2EEjKnxQQ7wfjsT1JTEdBG04x6ekVBw== </del> <ins> electron@25.8.1: version "25.8.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.1.tgz#092fab5a833db4d9240d4d6f36218cf7ca954f86" integrity sha512-GtcP1nMrROZfFg0+mhyj1hamrHvukfF6of2B/pcWxmWkd5FVY1NJib0tlhiorFZRzQN5Z+APLPr7aMolt7i2AQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

Version 1.74.0, when I open the developer tools, it becomes a floating window, which is very unfriendly for extension developers, please add at least one option to use the old layout. !
Was caused by an upstream electron bug with WCO Believe there are plans to restore the docking feature in the near future now that the electron issue is resolved.
I found that if you toggle OFF the setting, Developer Tools docking functionality is restored AND you also still get the WCO experience (perhaps that's a separate bug?). Suggest docking at the bottom instead of to the right if there's any visual conflict due to the aforementioned electron bug.
It work, thanks!.
The setting will be removed at one point, keeping the issue open to provide and dock options when WCO is enabled.
I manged to get it to dock again with 's workaround but I noticed in the dev tool now it shows the HTML for the VS code app instead of the file I have open in the preview !
Related Stack Overflow question:
This makes working on Windows really awful for me, I think the upstream bug is fixed.
To give some context, with WCO chromium has a bug in orienting devtools window when docked to the position where the Window controls are, basically they overlap making it harder to use the close, minimize or maximize button. Chromium always pop out the devtools window in PWA for this scenario and Electron inherited this by default. The fix in does not address the aligning behavior but rather provides a workaround that calling would be respected even in the WCO scenario rather than forcing to always detach. Now, on our end to incorporate this fix we need to change all our callsite with a mode otherwise we will default to detach as seen in this logic Say we chose as default and user later reposition it to right or left then this new state will be persisted to json file under the user data directory, in non WCO cases this saved preference will be applied next time when calling or without a mode value from the application side, that is how user's preferred position is applied. But in the WCO case, this does not take effect so we need a logic on VSCode side to read the preference value and adjust the start mode with it. I didn't want to make this change yet in core hence this issue remains open, I will tackle it in debt week.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.8.0: version "25.8.0" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.0.tgz#60c84f1f256924ac5a0aff13276b901b0c43767a" integrity sha512-T3kC1a/3ntSaYMCVVfUUc9v7myPzi6J2GP0Ad/CyfWKDPp054dGyKxb2EEjKnxQQ7wfjsT1JTEdBG04x6ekVBw== </del> <ins> electron@25.8.1: version "25.8.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.1.tgz#092fab5a833db4d9240d4d6f36218cf7ca954f86" integrity sha512-GtcP1nMrROZfFg0+mhyj1hamrHvukfF6of2B/pcWxmWkd5FVY1NJib0tlhiorFZRzQN5Z+APLPr7aMolt7i2AQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

I see this as an issue when you dock the devtools to the right, but why is the ability to dock it at the bottom taken away? This seems to work just fine with WCO. But on Windows, a user is not able to reposition the devtools at all? This functionality seems to be truly gone, so a setting for Windows only would be a decent workaround and good improvement over what we have today. If we decide on a setting that forces the location, I can see to do such a change.
I am good with a setting to force the bottom position only on Windows. I will see if the runtime behavior can be improved to avoid docking the devtools to the position where the controls are present as part of this issue.
The dock options are back, though setting it to dock on the right looks funny with the WCO in the way. !
Yes that is the original bug in chromium which is not addressed.
In the new version, if the developer tools are on the right side, the close button will be blocked, which is not as good as the old version of . !
use a dock position that is not overlapping with the window controls, by default the devtools will not dock to the position were the window controls are to avoid the bug.
I know, but I always put the developer tools on the right, which is where I'm most productive.
Is it possible to revert "window.experimental.windowControlsOverlay.enabled" to a VS Code new version? In order for the developer tools to be correctly positioned on the right side, I now have to go back to VS Code version 1.81 and disable updates. !
is there an issue where we are tracking how the WCO is overlapping the devtools?
no we are not tracking it in the runtime, unless you have manually docked it to the overlapping position devtools by default would be undocked. The overlapping position in the runtime will not resolved anytime soon.


Question: applyZoom(webFrame.getZoomLevel() - 1); } }; <del> } </del>  No newline at end of file <ins> } </ins>


Question: 'navigation', shouldInlineGroup ); <ins> } else { // If there is no active pane in the group (it's the last group and it's empty) // Trigger the change event when the active editor changes const _onDidChange = new Emitter<void>(); onDidChange = _onDidChange.event; disposables.add(this.onDidActiveEditorChange(() => _onDidChange.fire())); </ins> } return { actions: { primary, secondary }, onDidChange };


Question: import { IChatCommandButton, IChatContentReference, IChatFollowup, IChatProgressMessage, IChatResponseErrorDetails, IChatResponseProgressFileTreeData, IChatUsedContext, InteractiveSessionVoteDirection } from 'vs/workbench/contrib/chat/common/chatService'; import { countWords } from 'vs/workbench/contrib/chat/common/chatWordCounter'; import { CodeBlockModelCollection } from './codeBlockModelCollection'; <ins> import { IMarkdownString } from 'vs/base/common/htmlContent'; </ins> export function isRequestVM(item: unknown): item is IChatRequestViewModel { return !!item && typeof item === 'object' && 'message' in item;

Steps: extension that registers a document and a document range formatting provider open a test workspace that activates the extension and trigger a range format. You get:


Question: import { IChatCommandButton, IChatContentReference, IChatFollowup, IChatProgressMessage, IChatResponseErrorDetails, IChatResponseProgressFileTreeData, IChatUsedContext, InteractiveSessionVoteDirection } from 'vs/workbench/contrib/chat/common/chatService'; import { countWords } from 'vs/workbench/contrib/chat/common/chatWordCounter'; import { CodeBlockModelCollection } from './codeBlockModelCollection'; <ins> import { IMarkdownString } from 'vs/base/common/htmlContent'; </ins> export function isRequestVM(item: unknown): item is IChatRequestViewModel { return !!item && typeof item === 'object' && 'message' in item;


Question: return; } <ins> const next = keybindingService.lookupKeybinding(AccessibleDiffViewerNext.id)?.getAriaLabel(); const previous = keybindingService.lookupKeybinding(AccessibleDiffViewerPrev.id)?.getAriaLabel(); let switchSides; const switchSidesKb = keybindingService.lookupKeybinding('diffEditor.switchSide')?.getAriaLabel(); if (switchSidesKb) { switchSides = localize('msg3', "Run the command Diff Editor: Switch Side ({0}) to toggle between the original and modified editors.", switchSidesKb); } else { switchSides = localize('switchSidesNoKb', "Run the command Diff Editor: Switch Side, which is currently not triggerable via keybinding, to toggle between the original and modified editors."); } </ins> const keys = ['accessibility.signals.diffLineDeleted', 'accessibility.signals.diffLineInserted', 'accessibility.signals.diffLineModified']; const content = [ localize('msg1', "You are in a diff editor."), localize('msg2', "View the next ({0}) or previous ({1}) diff in diff review mode, which is optimized for screen readers.", next, previous), <del> localize('msg3', "To control which accessibility signals should be played, the following settings can be configured: {0}.", keys.join(', ')), </del> <ins> switchSides, localize('msg4', "To control which accessibility signals should be played, the following settings can be configured: {0}.", keys.join(', ')), </ins> ]; const commentCommandInfo = getCommentCommandInfo(keybindingService, contextKeyService, codeEditor); if (commentCommandInfo) {

mentioned that the diff editor experience is a little confusing because we don't explicitly state that the current editor is the modified one vs the original editor. AFAICT, there's also no way to jump between the original and modified ones. Is this correct? & I'd appreciate your thoughts here. Edit: action items: [ ] add info in help dialog about switch sides command [ ] get accessibility signals to work in original editor
There is the Diff Editor: Switch Sides command that moves focus to the other side. Maybe the wording could be improved. So not sure what needs to be done here? Feels like similar to the other issue you created about missing clarity in announcements on original vs modified.
Yes, I was unaware of that command. We should include it in the diff editor help dialog and include a default keybinding for when in screen reader mode as that's definitely something users would want to do IMO.
pointed out this should maybe be a tab stop if possible
I have the following keybinding, but there was no noticeable change (at least to from a screen reader user's standpoint) after switching into the other side. :
could you tell there was a focus change at all? Is there also no difference if you run the command vs use the keybinding?
Audio cues do not work when I'm navigating in the original editor. !


Question: }); }); <ins> test('trim final new lines bug#46075', function () { const model: TextFileEditorModel = instantiationService.createInstance(TextFileEditorModel, toResource.call(this, '/path/trim_final_new_line.txt'), 'utf8'); return model.load().then(() => { const configService = new TestConfigurationService(); configService.setUserConfiguration('files', { 'trimFinalNewlines': true }); const participant = new TrimFinalNewLinesParticipant(configService, undefined); const textContent = 'Test'; const eol = `${model.textEditorModel.getEOL()}`; let content = `${textContent}${eol}${eol}`; model.textEditorModel.setValue(content); // save many times for (let i = 0; i < 10; i++) { participant.participate(model, { reason: SaveReason.EXPLICIT }); } // confirm trimming assert.equal(snapshotToString(model.createSnapshot()), `${textContent}${eol}`); // undo should go back to previous content immediately model.textEditorModel.undo(); assert.equal(snapshotToString(model.createSnapshot()), `${textContent}${eol}${eol}`); model.textEditorModel.redo(); assert.equal(snapshotToString(model.createSnapshot()), `${textContent}${eol}`); }); }); </ins> });

This was also discussed in and apparently fixed in , but I'm still experiencing this. Steps to reproduce: to in settings. a file, and add the following contents: Ensure that there's an empty newline at the end. Save it. Then hit Undo. Nothing will happen. Hit Undo again, then it will work as expected. You can even hit Save multiple times, and each time will add one extra step to the Undo list. So hit Save 10 times, then you can hit Undo 10 times and nothing will happen. Could you take a look at this if possible?


Question: .extension-list-item > .details > .footer > .author > .publisher-name { font-size: 90%; <ins> color: var(--vscode-descriptionForeground); </ins> font-weight: 600; } <ins> .monaco-list-row.disabled .extension-list-item > .details > .footer > .author > .publisher-name{ color: var(--vscode-disabledForeground); } .monaco-list-row.disabled.selected .extension-list-item > .details > .footer > .author > .publisher-name{ color: unset; } .monaco-list-row.selected .extension-list-item > .details > .footer > .author > .publisher-name{ color: unset; } </ins> .extension-list-item > .details > .footer > .author > .publisher-name:not(:first-child) { padding-left: 1px; }

While helping Marketplace improve extension search I noticed that for most queries there are no more than 5 good results. And we currently show an infinite list which depending on Monitor size would show 10 - 20 extensions. Also we sometimes struggle with the small size of extension items in the list - not enough space for all the decorations we would like to render. Based on the two above, I suggest we explore with increasing the vertical size of the extension items in the list. Ideally this would allow to present the information in a cleaner way when users search for extensions. I am not sure how this would effect the list of installed and recommended extensions. Ideally we would also increase the size of those to be consistent, but for those cases I am not convinced if it would be a win. what do you think? for ux thoughts Example from my screen !
From a visual standpoint it makes sense to explore giving these some breathing room. As far as solving for quality results, I don't know if making them bigger will necessarily solve that problem alone. It could be that we have a sort of "Top Results" section up top with the remaining results in another section. Just one idea off the top of my head.
I agree its worth exploring it give more space for an extension in the viewlet. But this might impact if the size of the screen is smaller.
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!
I see this is merged and should be latest VS Code Insiders but I do not see any changes in my VS Code Insiders. am I missing something here?
I'm seeing the latest after updating: <img width="320" alt="CleanShot 2023-01-03 at 08 48 48 src="https://user-"<img width="328" alt="CleanShot 2023-01-03 at 08 49 32 src="https://user-"
I just got the update. Looks ok to me - I will need some time to adjust. Let's see what insiders users and the rest of the team says :)


Question: readonly viewType: string; readonly notebook: NotebookTextModel; isDirty(): boolean; <ins> isUntitled(): boolean; </ins> save(): Promise<boolean>; saveAs(target: URI): Promise<boolean>; revert(options?: IRevertOptions | undefined): Promise<void>;

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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. --- Version: 1.46.0-insider Commit: Date: 2020-06-01T10:32:27.369Z Electron: 7.3.0 Chrome: 78.0.3904.130 12.8.1 V8: 7.8.279.23-electron.0 OS: Darwin x64 19.5.0 Steps to Reproduce: a new untitled notebook (using VS Code Python extension) you add a cell or the like, then VSC will invoke the save method on the Problems Adding cells should not invoke save (this happens when user has auto save turned on) Errors thrown in the method are ignored. VSC will assume the notebook was saved and mark it as not dirty (the dirty indicator doesn't exist on the tab anymore) I don't think VSCode should call the method for untitled notebooks. FYI - We create untitled notebooks with a scehme . If this isn't the way to indicate an untitled file (scheme), we might need some API or the like in the notebooks implememtation. /cc
Good catch, untitled file should not trigger save until users explicitly run Save, which will invoke SaveAs.
We should also improve the overall experience for creating untitled notebook documents, they can be created in two approaches: Users press cmd/ctrl+n to create an untitled file, switch to another view type (tracked in ) Users run a specific command to quickly create a notebook untitled file. command should take view type as arguments. cc we may also want to adopt this in Custom Editor world.
We now support opening a untitled file with specified editor view type through the existing new untitled file command (in master, and tomorrow's Insiders) When the command is executed, is invoked with an URI with scheme. is invoked only when users save so no auto save for untitled files as usual.


Question: }; export interface ISuggestController { <ins> isPasting: boolean; </ins> selectPreviousSuggestion(): void; selectPreviousPageSuggestion(): void; selectNextSuggestion(): void;

Steps to Reproduce: text into PowerShell (with Terminal suggest enabled) see batched pasting behavior
maybe related to
Haha, I think this is it triggering completions while the pasted text is being send then kicking in. Pastes should never trigger completions so let's track that here.
When verifying make sure you're on macOS.


Question: case FormEvent.SENDING: this.isSendingFeedback = true; this.sendButton.setClass('send in-progress'); <del> this.sendButton.value(nls.localize('feedbackSending', "Sending...")); </del> <ins> this.sendButton.value(nls.localize('feedbackSending', "Sending")); </ins> break; case FormEvent.SENT: this.isSendingFeedback = false; <del> this.sendButton.setClass('send success').value(nls.localize('feedbackSent', "Thanks :)")); </del> <ins> this.sendButton.setClass('send success').value(nls.localize('feedbackSent', "Thanks")); </ins> this.resetForm(); this.autoHideTimeout = setTimeout(() => { this.hide();

To reproduce. click smiley in the bottom right of editor window. The feedback form should appear enter several characters, press "Enter" (the new line should appear) continue entering characters while you can You should stop at "1 characters left" (declensions?) After that you will not be able to enter anything On the screenshot. There's a newline after "1". I reached the end of input and unable to enter more characters. But counter still says "1 characters left": <img width="468" alt="" src=""Mac OS 10.10.5 Yosemite
This is interesting. I created this to reproduce the behavior. do you have any thoughts on this? Here are a couple ideas we've talked about before. 1 - Remove the text area completely and replace with just the tweet button. This makes sense because we're submitting to twitter anyways. 2 - Hack the text area element to get better behavior. This would involve looking for new line characters based on the batter described by OP. I'm not a fan of this as it seems error prone. If we go with option 1, I'll work with Brad and get some design love on the form. any thoughts? I created PR to fix the "s" on singular count issue.
Thanks for your amazing job and thanks for asking! :blush: If the "Tweet" button will not require having a Twitter account, then it's a solution, I guess. I feel a bit weird reporting those super-tiny issues that still require developers time. Is the related (then we should star it)? Probably even disabling line breaks (like turning into line input) could be a solution.
Yes that is the exact issue. Starred it! I thought about disabling line breaks, but I think it would be a good thing for the user to do, considering Twitter supports line breaks. The Tweet button wouldn't require a Twitter account, but once the Tweet button takes them to twitter they would need to login.
Well, the need to login on Twitter is a requirement to have a Twitter account :blush: I wouldn't think it's a good UX :relaxed:
Right. Unfortunately Twitter doesn't support anonymous tweets.
After some internal discussion we decided to go with a dialog redesign. Will work with our UX designer to get some help.
Closing as it will be fixed with .


Question: break; } } <del> if (!differentGroups) { </del> <ins> if (!differentGroups && group.terminalInstances.length === instances.length) { </ins> return; } }

<!-- 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.69.0-insider OS Version: Windows 10 Steps to Reproduce: Two split terminals + one standalone terminal, select them all then join. !
this works now, must've been fixed
I tried it in the latest insider build, still fails. Instead of selecting the terminal tabs one by one, can you try to select all, then join them? If you can reproduce, please reopen it.


Question: let _commandRegistrations: IDisposable[] = []; <del> ExtensionsRegistry.registerExtensionPoint<schema.IUserFriendlyCommand | schema.IUserFriendlyCommand[]>({ </del> <ins> export const commandsExtensionPoint = ExtensionsRegistry.registerExtensionPoint<schema.IUserFriendlyCommand | schema.IUserFriendlyCommand[]>({ </ins> extensionPoint: 'commands', jsonSchema: schema.commandsContribution <del> }).setHandler(extensions => { </del> <ins> }); commandsExtensionPoint.setHandler(extensions => { </ins> function handleCommand(userFriendlyCommand: schema.IUserFriendlyCommand, extension: IExtensionPointUser<any>, disposables: IDisposable[]) {

contribute command that uses enablement assign a keybinding, via :bug: enablement isn't honoured
When users configure keybindings we allow them to change preconditions as well, e.g rename requires an editable document so I don't plan to have a different strategy for contributed commands
I don't see the nice "Command 'Hello World' is not enabled in the current context." info toast when I try the keybinding though. I only see that message when I try to run it from the command palette. The command correctly doesn't run when not enabled though.
Yeah, that's the design. Keybindings don't show messages