Question: import { AccessibilitySignal, IAccessibilitySignalService } from '../../../../platform/accessibilitySignal/browser/accessibilitySignalService.js'; import { ILoggerService, LogLevel, LogLevelToLocalizedString, LogLevelToString } from '../../../../platform/log/common/log.js'; import { IDefaultLogLevelsService } from '../../logs/common/defaultLogLevels.js'; <del> import { EditorOptions } from '../../../../editor/common/config/editorOptions.js'; import { WordCharacterClassifier, getMapForWordSeparators } from '../../../../editor/common/core/wordCharacterClassifier.js'; import { WordNavigationType } from '../../../../editor/common/cursor/cursorWordOperations.js'; </del> <ins> import { KeybindingsRegistry, KeybindingWeight } from '../../../../platform/keybinding/common/keybindingsRegistry.js'; </ins> import { EditorContextKeys } from '../../../../editor/common/editorContextKeys.js'; <del> import { ITextModel } from '../../../../editor/common/model.js'; import { WordLeftCommand, WordRightCommand } from '../../../../editor/contrib/wordOperations/browser/wordOperations.js'; </del> import { CONTEXT_ACCESSIBILITY_MODE_ENABLED } from '../../../../platform/accessibility/common/accessibility.js'; import { IsWindowsContext } from '../../../../platform/contextkey/common/contextkeys.js'; <del> import { KeybindingWeight } from '../../../../platform/keybinding/common/keybindingsRegistry.js'; import { Position } from '../../../../editor/common/core/position.js'; import { registerEditorCommand } from '../../../../editor/browser/editorExtensions.js'; </del> import { FocusedViewContext } from '../../../common/contextkeys.js'; // Register Service

cloudcode2.14.0 overleaf-workshop0.13.0 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.90.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.4 zotero0.1.11 git-graph1.30.0 azure-dev0.8.3 vscode-azureappservice0.25.2 vscode-azurecontainerapps0.6.1 vscode-azurefunctions1.15.1 vscode-azureresourcegroups0.8.3 vscode-azurestaticwebapps0.12.2 vscode-azurestorage0.16.0 vscode-azurevirtualmachines0.6.5 vscode-cosmosdb0.22.0 vscode-docker1.29.1 vscode-edge-devtools2.1.5 black-formatter2024.3. debugpy2024.9. flake82023.13. isort2023.13. python2024.11. vscode-pylance2024.7.1 jupyter2024.6. jupyter-keymap1.1.2 jupyter-renderers1.0.18 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.377.0 remote-ssh0.113. 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.43 cpptools1.21.0 cpptools-extension-pack1.3.0 js-debug-nightly2024.7.517 powershell2024.3.2 remote-explorer0.5. remote-repositories0.40.0 remote-server1.6.


Question: import { AccessibilitySignal, IAccessibilitySignalService } from '../../../../platform/accessibilitySignal/browser/accessibilitySignalService.js'; import { ILoggerService, LogLevel, LogLevelToLocalizedString, LogLevelToString } from '../../../../platform/log/common/log.js'; import { IDefaultLogLevelsService } from '../../logs/common/defaultLogLevels.js'; <del> import { EditorOptions } from '../../../../editor/common/config/editorOptions.js'; import { WordCharacterClassifier, getMapForWordSeparators } from '../../../../editor/common/core/wordCharacterClassifier.js'; import { WordNavigationType } from '../../../../editor/common/cursor/cursorWordOperations.js'; </del> <ins> import { KeybindingsRegistry, KeybindingWeight } from '../../../../platform/keybinding/common/keybindingsRegistry.js'; </ins> import { EditorContextKeys } from '../../../../editor/common/editorContextKeys.js'; <del> import { ITextModel } from '../../../../editor/common/model.js'; import { WordLeftCommand, WordRightCommand } from '../../../../editor/contrib/wordOperations/browser/wordOperations.js'; </del> import { CONTEXT_ACCESSIBILITY_MODE_ENABLED } from '../../../../platform/accessibility/common/accessibility.js'; import { IsWindowsContext } from '../../../../platform/contextkey/common/contextkeys.js'; <del> import { KeybindingWeight } from '../../../../platform/keybinding/common/keybindingsRegistry.js'; import { Position } from '../../../../editor/common/core/position.js'; import { registerEditorCommand } from '../../../../editor/browser/editorExtensions.js'; </del> import { FocusedViewContext } from '../../../common/contextkeys.js'; // Register Service

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-ko-kr0.4.0 vsliveshare1.0.5932 windows-ai-studio0.3.3 autodocstring0.6.1 pandocciter0.10.4 publisher1.1.3 shiny1.0.0 shinyuieditor0.5.0 quarto1.113.0 r-debugger0.5.4 java1.32.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.9.3 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.6. vscode-java-debug0.58.0 vscode-java-dependency0.23.7 vscode-java-pack0.27.0 vscode-java-test0.41.1 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 --
do you know why this isn't currently supported?
It seems to work for me in Mac, are you seeing it otherwise?
It does work for me, although sometimes with the screen reader enabled, it's reading the word then a whole chunk of text. I'll try on windows.
It’s not working in Windows.
Can reproduce on windows. I see that this is happening because there's a part of the when clause for and of for windows
Removing that from the clause fixes it. Looks like that condition was to fix this can you try removing that condition from the clause and seeing if you experience any consequences of doing so?


Question: MenuRegistry.appendMenuItem(MenuId.EditorActionsPositionSubmenu, { command: { id: EditorActionsTitleBarAction.ID, title: localize('titleBar', "Title Bar"), toggled: ContextKeyExpr.or(ContextKeyExpr.equals('config.workbench.editor.editorActionsLocation', 'titleBar'), ContextKeyExpr.and(ContextKeyExpr.equals('config.workbench.editor.showTabs', 'none'), ContextKeyExpr.equals('config.workbench.editor.editorActionsLocation', 'default'))) }, group: '1_config', order: 20 }); MenuRegistry.appendMenuItem(MenuId.EditorActionsPositionSubmenu, { command: { id: HideEditorActionsAction.ID, title: localize('hidden', "Hidden"), toggled: ContextKeyExpr.equals('config.workbench.editor.editorActionsLocation', 'hidden') }, group: '1_config', order: 30 }); <ins> MenuRegistry.appendMenuItem(MenuId.EditorTabsBarContext, { command: { id: ConfigureEditorTabsAction.ID, title: localize('configureTabs', "Configure Tabs ...") }, group: '9_configure', order: 10 }); </ins> // Editor Title Context Menu MenuRegistry.appendMenuItem(MenuId.EditorTitleContext, { command: { id: CLOSE_EDITOR_COMMAND_ID, title: localize('close', "Close") }, group: '1_close', order: 10 }); MenuRegistry.appendMenuItem(MenuId.EditorTitleContext, { command: { id: CLOSE_OTHER_EDITORS_IN_GROUP_COMMAND_ID, title: localize('closeOthers', "Close Others"), precondition: EditorGroupEditorsCountContext.notEqualsTo('1') }, group: '1_close', order: 20 });

! is not very discoverable. If it would be a submenu of the context menu, it would be much easier to tweak this setting.
...
I'm for making these types of settings more discoverable, however, I do not want to add these types of settings to the contextmenu. We mainly use the context menu to change the visibility of elements/features but we don't really use it to configure them/change appearance. Also, the context menu is already pretty full and I don't want to overload it.
I'm open to other ideas to make them more discoverable. Maybe a "configure" entry in the overflow menu of the toolbar?
Yeah I like the idea of an action in the "..." menu to configure all things editor related by narrowing down a settings search in the settings editor.
verification steps: Right click on the tab bar (not on a tab) At the bottom of the context menu there is an action "Configure Tabs...", press it Settings editor should open with tabs related settings


Question: this.domNode = undefined; })); <ins> this.toDispose.add(dom.addDisposableListener(this.domNode, dom.EventType.CONTEXT_MENU, (e) => { this.contextMenuService.showContextMenu({ getAnchor: () => { return new StandardMouseEvent(dom.getActiveWindow(), e); }, getActions: () => { return [{ id: 'workench.action.disableTerminalInitialHint', label: localize('disableInitialHint', "Disable Initial Hint"), tooltip: localize('disableInitialHint', "Disable Initial Hint"), enabled: true, class: undefined, run: () => this.configurationService.updateValue(TerminalInitialHintSettingId.Enabled, false) } ]; } }); })); </ins> } return this.domNode; }

I've verified that I can see the terminal hint in insiders. Does this also need to be tested in stable?
Yes this needs a stable build as it checks quality. You could verify out of sources by setting quality to stable as well


Question: this.domNode = undefined; })); <ins> this.toDispose.add(dom.addDisposableListener(this.domNode, dom.EventType.CONTEXT_MENU, (e) => { this.contextMenuService.showContextMenu({ getAnchor: () => { return new StandardMouseEvent(dom.getActiveWindow(), e); }, getActions: () => { return [{ id: 'workench.action.disableTerminalInitialHint', label: localize('disableInitialHint', "Disable Initial Hint"), tooltip: localize('disableInitialHint', "Disable Initial Hint"), enabled: true, class: undefined, run: () => this.configurationService.updateValue(TerminalInitialHintSettingId.Enabled, false) } ]; } }); })); </ins> } return this.domNode; }

Can this support right click to toggle the setting to hidden? !
right click shows our terminal context menu, perhaps we should just put it in there rather than adding a new one? !
this isn't a feature the others offer, thus not a bug IMO


Question: "@vscode/l10n": "^0.0.11", "jsonc-parser": "^3.2.0", "request-light": "^0.7.0", <del> "vscode-json-languageservice": "^5.3.1", </del> <ins> "vscode-json-languageservice": "^5.3.2", </ins> "vscode-languageserver": "^8.1.0", "vscode-uri": "^3.0.7" },

On Windows: clone open workspace look at the workspace settings: all files are associated with schema . Note that this is a relative path to the workspace file open both files and check that code completion gives back property . You can also click on the JSON language selector ( next to JSON in the status bar) to see the schema that is associated :bug: No code code completion or schema association
76 candidate PR:


Question: } switch (e.data.type) { <del> case 'setScale': </del> <ins> case 'setScale': { </ins> updateScale(e.data.scale); break; <del> case 'setActive': </del> <ins> } case 'setActive': { </ins> setActive(e.data.value); break; <del> case 'zoomIn': </del> <ins> } case 'zoomIn': { </ins> zoomIn(); break; <del> case 'zoomOut': </del> <ins> } case 'zoomOut': { </ins> zoomOut(); break; <ins> } case 'copyImage': { copyImage(); break; } </ins> } }); <ins> document.addEventListener('copy', () => { copyImage(); }); async function copyImage() { try { await navigator.clipboard.write([new ClipboardItem({ 'image/png': fetch(image.src).then(request => request.blob()) })]); } catch (e) { console.error(e); } } </ins> }());

<!-- 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: } switch (e.data.type) { <del> case 'setScale': </del> <ins> case 'setScale': { </ins> updateScale(e.data.scale); break; <del> case 'setActive': </del> <ins> } case 'setActive': { </ins> setActive(e.data.value); break; <del> case 'zoomIn': </del> <ins> } case 'zoomIn': { </ins> zoomIn(); break; <del> case 'zoomOut': </del> <ins> } case 'zoomOut': { </ins> zoomOut(); break; <ins> } case 'copyImage': { copyImage(); break; } </ins> } }); <ins> document.addEventListener('copy', () => { copyImage(); }); async function copyImage() { try { await navigator.clipboard.write([new ClipboardItem({ 'image/png': fetch(image.src).then(request => request.blob()) })]); } catch (e) { console.error(e); } } </ins> }());

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: } } <del> private count(): number { return this.panes.reduce((count, view) => (<ExtensionsListView>view).count() + count, 0); </del> <ins> private getFirstExpandedPane(): ExtensionsListView | undefined { for (const pane of this.panes) { if (pane.isExpanded() && pane instanceof ExtensionsListView) { return pane; } } return undefined; </ins> } private focusListView(): void { <del> if (this.count() > 0) { this.panes[0].focus(); </del> <ins> const pane = this.getFirstExpandedPane(); if (pane && pane.count() > 0) { pane.focus(); </ins> } }

! Testing
I'll try to deal with this
I'm sorry, I would like to ask a simple question. If I want to use this accessibility mode, do I need a software like NVDA to make it work? Or if I only have VS Code, can I still trigger this functionality?
Hey you can enable this with the command - a status bar indicator will appear
I used to be able to trigger , but now when I trigger it, it will show up in the lower left corner, but it won't have any function, which is a bit strange, are and the same function, I didn't find
Yes that's what I had meant. Hm, maybe a recent regression? Last time I tried this, it worked for me. I'll investigate tomorrow
Also, re the question of do you need to use a screen reader, it depends on what you're trying to do/ test. With that mode on, certain audio cues will (should) be enabled by default for example.
I have used this function once before, and it is true that the audio will play after it is turned on, but this time there is no response, I will check again to see if it is a problem with my settings
you can test this - and it's working for me with: screen reader mode status bar item appears in the terminal hear sound screen reader mode status bar item disappears no sound
Thanks! This work for me
I started trying to solve the problem


Question: }); } <ins> function consoleLogFn(msg) { const type = msg.type(); const candidate = console[type]; if (candidate) { return candidate; } if (type === 'warning') { return console.warn; } return console.log; } </ins> function pkill(pid: number): Promise<void> { return new Promise((c, e) => { kill(pid, error => error ? e(error) : c());

They used to finish in 3m24s before - […]-5f82-0dbc-&t=-371d-5daa-d7a2-
I can confirm that tests started timing out after this commit - The first commit that is started happening is Checking what commits in between would have caused it. FYI
Assigning to as one of his commits has caused this timeout.
Mac seems to be passing pretty reliably now but now windows fails consistently on two tests Been adding a bunch of logging to investigate this. Here's the relevant new error: The service worker should be intercepting this request so it should never be going to the network at all here. Taking a look to see if I can figure out what is going on
Actually it's not windows specific: its Firefox specific. The windows browser tests just happen to be the only ones using Firefox Can reproduce on Mac too


Question: } const scopedContextKeyService = this._register(_contextKeyService.createScoped(this._wrapperElement)); <ins> this._scopedContextKeyService = scopedContextKeyService; </ins> this._scopedInstantiationService = instantiationService.createChild(new ServiceCollection( [IContextKeyService, scopedContextKeyService] ));

Type: <bBug</bPinning a terminal editor does not set some of the context variables that are normally set when pining a text editor. Here are the ones I've noticed: activeEditorIsDirty activeEditorIsFirstInGroup activeEditorIsLastInGroup activeEditorIsNotPreview activeEditorIsPinned In the case of activeEditorIsPinned this makes it impossible to detect if the current terminal editor is pinned. Since there is no command to toggle the pin on an editor this means it's not possible to create a single keybinding that can intelligently pin and unpin the current terminal editor. In the case of activeEditorIsLastInGroup it means it's not possible to create a keybinding to move a terminal editor out of the "pinned section" of editors in the current group. When editors are pinned they are moved to the left side of the current editor group. When moving an editor to the previous position in the current group if it happens to cross into the pinned section it will become pinned. But the inverse is not possible: you cannot move a pinned editor out of the pinned section unless there happens to be something else unpinned to the right of it. So I have a keybinding to unpin the current editor if it's the last editor in the current group. Since terminal editors don't set the required context they break this binding. Steps to Repro: Open a terminal in the editor area Pin the terminal editor Inspect context keys Notice activeEditorIsPinned is not set VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
The type of editor should not play any role in this. I somewhat doubt this is a bug in our code, so setting label that we need confirmation. Open for help, investigation, suggested fixes, PR.
This one I cannot confirm or reproduce. See this gif where I open a terminal, pin it and then inspect the context keys: ! What are some exact steps?
Looks like it depends where you click when inspecting context keys.


Question: } const scopedContextKeyService = this._register(_contextKeyService.createScoped(this._wrapperElement)); <ins> this._scopedContextKeyService = scopedContextKeyService; </ins> this._scopedInstantiationService = instantiationService.createChild(new ServiceCollection( [IContextKeyService, scopedContextKeyService] ));

I'm clicking inside the terminal, where my cursor is, because I'm attempting to make keybindings that work when using the terminal. You're clicking the editor tab. So it appears the context is set for the editor, but when you focus the terminal within it that context is removed. Interestingly I still see some of the context so not all of it is removed.
Quite likely that the terminal itself sets its own context keys.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified, but while confirming the fix I noticed more issues with these context keys


Question: { "open": "{", "close": "}" }, { "open": "(", "close": ")" }, { "open": "'", "close": "'", "notIn": ["string", "comment"] }, <del> { "open": """, "close": """, "notIn": ["string"] } </del> <ins> { "open": """, "close": """, "notIn": ["string"] }, { "open": "/*", "close": " */", "notIn": ["string", "comment"] } </ins> ], "surroundingPairs": [ ["{", "}"],

Description Currently, when editing a file, the command <kbdctrl</kbd+<kbdshift</kbd+<kbda</kbd(toggle block comment) generates the following comment placeholder . I wonder if it might be also wise to include this as an auto-closing pair so that when users attempt to write the closing is automatically like other languages (ex: Typescript).
This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the for VS Code. See also our guidelines. Happy Coding!
I'm not quite sure as to who or where the owner is for the extension. Looking at the I noticed multiple past updates to support additional features. Isn't the proposed feature request present in the issue similar to those past updates?
Oh, you are right. This part is us, not the extension. Sorry for the confusion...
Looks like a good change to me. Feel free to make a pull request.
Not able to reproduce ctrl+shift+a not having any effect.
I assume you are editing a file, but sorry the keybinding I mentioned is for Linux, on macOS for example the keybinding is . The easiest way to test is to simply run the command from the menu 🡒 :)
Got it, in windows it is Shift+Alt+A.
I forgot to mention I won't be able to submit a PR myself due to my company policy. If anyone would like to take on the issue, please feel free to do so :)
In that case, I am more than happy to make a pull request for this. Thanks for the information. I will submit one soon.
thank you!


Question: { "open": "{", "close": "}" }, { "open": "(", "close": ")" }, { "open": "'", "close": "'", "notIn": ["string", "comment"] }, <del> { "open": """, "close": """, "notIn": ["string"] } </del> <ins> { "open": """, "close": """, "notIn": ["string"] }, { "open": "/*", "close": " */", "notIn": ["string", "comment"] } </ins> ], "surroundingPairs": [ ["{", "}"],

VSCode Version: 1.36.0 OS Version: Windows 10 / Mac OS Steps to Reproduce: any c++ code inside of a .cpp/h/hpp etc file. "/" at the begging of of a line that has already been written "/" gets automatically afterwards, but before the code, so nothing actually gets commented out Simple example, where "|" denotes the cursor position: "/*" shouldn't auto-add the end symbol of the comment block by default, should be setting controlled, and should be able to recognize when it's been entered at the start of a line. Does this issue occur when all extensions are disabled?: Yes Originally reported here: They forwarded me to you folks, so I'm assuming this was to the "C/C++ Language Basics" built-in extension without a setting to control it. Please for the love of god fix this. It's super annoying.
Found a temporary workaround: to: (User Folder)AppDataLocalProgramsMicrosoft VS Coderesourcesappextensions "cpp" to (User Folder).vscodeextensions it something like "cpp.language-basics-custom" to avoid any later confusion. "language-" & comment out (or remove) this line: the trailing comma in the previous line (might not be necessary) VS Code. The custom version should take precedence over the built-in version. Comment blocks will no longer auto-close.
Also, of note: Neither javascript nor typescript contains that in their language- files, but uses the same style of block comments. I think it's safe to say it should just be removed from the cpp language-
It looks like C# and json use the as an auto closing pair, but java, javascript, php, and typescript use the . For C languages we whould use since it is more consistent.
Fix will be available in next insiders if you want it ASAP. It installs side by side with stable, so you can have both:
the C/C++ extension already registers a custom , including for . Please don't add autoClosingPairs for comments since there is no way to disable them in vscode. There are only settings for and . I seem to recall these all being controlled by a single setting at some point, but now there are only 2 out of 3 available.


Question: { "open": "{", "close": "}" }, { "open": "(", "close": ")" }, { "open": "'", "close": "'", "notIn": ["string", "comment"] }, <del> { "open": """, "close": """, "notIn": ["string"] } </del> <ins> { "open": """, "close": """, "notIn": ["string"] }, { "open": "/*", "close": " */", "notIn": ["string", "comment"] } </ins> ], "surroundingPairs": [ ["{", "}"],

Visual Studio Code lacks support for automatic comment-block ending in C and C++. If you were to start a comment-block with , an automatic will not be as it would be in the traditional Visual Studio. When I type , it should automatically be turned into and the text cursor should be between the two ``. It isn't that big of a deal but it would be really nice to have this feature in Visual Studio Code.
Ugh. I currently have the exact OPPOSITE problem: I want to DISABLE this feature. This is happening for me and I can't figure out how to turn it OFF. There are a large number of developers who just don't ever want their text editor to ever, under any circumstances, insert a character that did not correspond exactly 1:1 to a specific keystroke. I push "A", I get "A". And so on. "Surprises" break my flow worse than any other kind of interruption. Obviously, there are a lot of developers in the other camp. But the upshot is that the fact that both camps exist, and both camps are large, means that when features like this exist, it needs to be possible to disable them. I have encouraged many projects for years to consider adding a "dumb as a brick" switch that will just globally disable all of these. In the absence of a master switch, we at least need configuration switches that can shut these things off-- preferably arranged hierarchically, so that we can shut off entire branches. But the absolute lowest rung on the ladder is that individual switches must exist to disable these things.
Let's track in


Question: import { Codicon } from 'vs/base/common/codicons'; import { registerIcon } from 'vs/platform/theme/common/iconRegistry'; import { UntitledTextEditorInputSerializer, UntitledTextEditorWorkingCopyEditorHandler } from 'vs/workbench/services/untitled/common/untitledTextEditorHandler'; <del> import { DynamicEditorGroupAutoLockConfiguration } from 'vs/workbench/browser/parts/editor/editorConfiguration'; </del> <ins> import { DefaultBinaryEditorConfiguration, DynamicEditorGroupAutoLockConfiguration } from 'vs/workbench/browser/parts/editor/editorConfiguration'; </ins> //#region Editor Registrations

We don't want to officially have the hex editor be recommended for non-textual files, but what about a setting like that can be used to open a binary file in a given editor instead of showing the "binary file" message? ! I would love it if I could have all non-text files automatically opened in the hex editor.
To verify ensure the setting works as expected. Setting it to a custom editor should automatically have that editor be opened when a file is detected as binary.


Question: export const InteractiveWindowSetting = { interactiveWindowAlwaysScrollOnNewCell: 'interactiveWindow.alwaysScrollOnNewCell', <del> interactiveWindowHotExit: 'interactiveWindow.hotExit' </del> <ins> interactiveWindowRestore: 'interactiveWindow.restore' </ins> };

Testing microsoft/vscode-jupyter The setting description says that the 'interactive window session' is restored. But after a reload, it seems that the state has been forgotten e.g. Open the interactive window run run prints 9 reload the window the output is restored but running again will show Note that I had to retype print(x) as there was no way to rerun the previously shown cells What's restored seems to be the last output. Maybe the settings description can clarify that?


Question: export const InteractiveWindowSetting = { interactiveWindowAlwaysScrollOnNewCell: 'interactiveWindow.alwaysScrollOnNewCell', <del> interactiveWindowHotExit: 'interactiveWindow.hotExit' </del> <ins> interactiveWindowRestore: 'interactiveWindow.restore' </ins> };

Testing microsoft/vscode-jupyter IMO is about restoring a editor with unsaved changes, but the interactiveWindow doesn't seem to have a dirty state. Maybe just call it 'interactiveWindow.restore`? It's actually not really a window ;-)
Good point Martin, I think calling it makes better sense. is a bit ambiguous, we can revisit the name for it in the core when we stabilize the API.


Question: model.dispose(); mode.dispose(); }); <ins> test('issue #45369: Select to Bracket with multicursor', () => { let mode = new BracketMode(); let model = TextModel.createFromString('{  }   {   }   { }', undefined, mode.getLanguageIdentifier()); withTestCodeEditor(null, { model: model }, (editor, cursor) => { let bracketMatchingController = editor.registerAndInstantiateContribution<BracketMatchingController>(BracketMatchingController); // cursors inside brackets become selections of the entire bracket contents editor.setSelections([ new Selection(1, 3, 1, 3), new Selection(1, 10, 1, 10), new Selection(1, 17, 1, 17) ]); bracketMatchingController.selectToBracket(); assert.deepEqual(editor.getSelections(), [ new Selection(1, 1, 1, 5), new Selection(1, 8, 1, 13), new Selection(1, 16, 1, 19) ]); // cursors to the left of bracket pairs become selections of the entire pair editor.setSelections([ new Selection(1, 1, 1, 1), new Selection(1, 6, 1, 6), new Selection(1, 14, 1, 14) ]); bracketMatchingController.selectToBracket(); assert.deepEqual(editor.getSelections(), [ new Selection(1, 1, 1, 5), new Selection(1, 8, 1, 13), new Selection(1, 16, 1, 19) ]); // cursors just right of a bracket pair become selections of the entire pair editor.setSelections([ new Selection(1, 5, 1, 5), new Selection(1, 13, 1, 13), new Selection(1, 19, 1, 19) ]); bracketMatchingController.selectToBracket(); assert.deepEqual(editor.getSelections(), [ new Selection(1, 1, 1, 5), new Selection(1, 8, 1, 13), new Selection(1, 16, 1, 19) ]); bracketMatchingController.dispose(); }); model.dispose(); mode.dispose(); }); </ins> });

Issue Type: <bBug</bmultiple brackets "" Expected: All cursors at brackets become selections starting where the original cursor was and and ending at its matching bracket. Actual: Only the first cursor becomes a selection, the rest dissapear. VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.3.0 </detailsReproduces without extensions <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.531 --- <!-- score: 0.527 --- <!-- score: 0.498 --- <!-- score: 0.498 --<!-- potentialduplicatescomment --


Question: } get persistentProcessId(): number | undefined { return this._processManager.persistentProcessId; } <del> get shouldPersist(): boolean { return this._processManager.shouldPersist; } </del> <ins> get shouldPersist(): boolean { return this._processManager.shouldPersist && !this.shellLaunchConfig.disablePersistence; } </ins> /** * Create xterm.js instance and attach data listeners.

Currently we enable the persistent terminal/reconnect feature if a terminal is launched by an extension, unlike the env var relaunch where we disable outright because it can cause issues with the extension as it loses access to the terminal upon relaunch. Relaunching the PowerShell extension right now for example is a bit of a weird experience though because it creates the "PowerShell Integrated Console", and that reconnects upon reload but is no longer managed by the extension. Before reload: ! After reload it is restored, but no longer owned by the extension: ! Assigning to March for exploration. Thoughts
I think just allowing opt-out/opt-in on this behavior would be more than enough for PowerShell's case.
Has there been any progress on this? Now that persistent terminals are the default, this gets quite annoying and bothers users when extension-owned terminals come back but aren't actually connected.
No progress, we'll try get it in the next version
proposal:
Is this still ongoing and targeted for February?
Yes it is


Question: } private onReady(container: HTMLElement, recentlyOpened: TPromise<{ files: URI[]; workspaces: (IWorkspaceIdentifier | ISingleFolderWorkspaceIdentifier)[]; }>, installedExtensions: TPromise<IExtensionStatus[]>): void { <del> const enabled = isWelcomePageEnabled(this.configurationService); </del> <ins> const enabled = isWelcomePageEnabled(this.configurationService, this.contextService); </ins> const showOnStartup = <HTMLInputElement>container.querySelector('#showOnStartup'); if (enabled) { showOnStartup.setAttribute('checked', 'checked');

When you open a recent project from the welcome screen, the last one remains opened in a tab. VSCode Version: 1.9.1 OS Version: macOS Sierra 10.12.3 Steps to Reproduce: a new VSCode window. a recent project from the welcome screen. project is opened and the welcome screen remains opened.
The current behavior was chosen in the hope that this would help new users by staying in the same context.
I agree that the welcome screen should be closed after taking an action from it. Especially in my case, where I prefer to use the setting, having to close the otherwise empty welcome window after opening from the 'Recents' list or via FileOpen feels like a bug.
You can just not show it at all. Or do you need any of the actions on it? (I'm trying to preserve the new user experience here which relies much more on guidance.)
It's ok showing the welcome screen, but it should be closed after opening a project from there.
With we change the Welcome editor to open in preview mode, this way it will close when the next editor opens. (If preview mode is not disabled in settings.)
This could be an additional value for the setting.
Hey, I could look into this. Got any tips on where I should start ?
Great: Add an additional enum literal here: Check for that literal and the 'open folder' condition here:
Hey , I've ran into some questions which you might be able to help me with: should I name the enum literal? I can't seem to come up with the right name would I check for the 'open folder' condition?
You could use . Check for no folder being open: . You can get at the context service by adding it to the constructor of the calling class, similar to:
Hey everything seems to be working now, just one last question which is confusing me: isn't the objective of this issue to NOT show the Welcome Page when opening a new project? So why is your enum suggestion welcomePageInEmptyWorkbench? What is happening right now after my additions is: upon opening a new project, no Welcome Page is shown. Is this right?
Show it only in the empty workbench. :)
Hey Now I'm getting upon opening a new window (empty workbench). Any ideas? I did the comparison as you said for no folder being open.
Is the ?


Question: } private onReady(container: HTMLElement, recentlyOpened: TPromise<{ files: URI[]; workspaces: (IWorkspaceIdentifier | ISingleFolderWorkspaceIdentifier)[]; }>, installedExtensions: TPromise<IExtensionStatus[]>): void { <del> const enabled = isWelcomePageEnabled(this.configurationService); </del> <ins> const enabled = isWelcomePageEnabled(this.configurationService, this.contextService); </ins> const showOnStartup = <HTMLInputElement>container.querySelector('#showOnStartup'); if (enabled) { showOnStartup.setAttribute('checked', 'checked');

You can debug it either in VS Code or in the Developer Tools (Help Toggle Developer Tools in the window running from source).
Upon opening a new window, it isn't undefined (verified by a console log) but then it turns undefined (verified by the same console log). Edit: and immediately after Edit2: Found it! Seems like isWelcomePageEnabled() is called twice, once in the class constructor and the other one in the onReady method. I'll make the PR in a bit


Question: MenuRegistry.appendMenuItem(MenuId.EditorTitle, { command: { id: TOGGLE_MAXIMIZE_EDITOR_GROUP, title: localize('maximizeGroup', "Maximize Group") }, group: '8_group_operations', order: 5, when: ContextKeyExpr.and(EditorPartMaximizedEditorGroupContext.negate(), EditorPartMultipleEditorGroupsContext) }); MenuRegistry.appendMenuItem(MenuId.EditorTitle, { command: { id: TOGGLE_MAXIMIZE_EDITOR_GROUP, title: localize('unmaximizeGroup', "Unmaximize Group") }, group: '8_group_operations', order: 5, when: EditorPartMaximizedEditorGroupContext }); MenuRegistry.appendMenuItem(MenuId.EditorTitle, { command: { id: TOGGLE_LOCK_GROUP_COMMAND_ID, title: localize('lockGroup', "Lock Group"), toggled: ActiveEditorGroupLockedContext }, group: '8_group_operations', order: 10, when: IsAuxiliaryEditorPartContext.toNegated() /* already a primary action for aux windows */ }); <ins> MenuRegistry.appendMenuItem(MenuId.EditorTitle, { command: { id: ConfigureEditorAction.ID, title: localize('configureEditor', "Configure Editor ...") }, group: '9_configure', order: 10 }); </ins> function appendEditorToolItem(primary: ICommandAction, when: ContextKeyExpression | undefined, order: number, alternative?: ICommandAction, precondition?: ContextKeyExpression | undefined): void { const item: IMenuItem = {

! is not very discoverable. If it would be a submenu of the context menu, it would be much easier to tweak this setting.
...
I'm for making these types of settings more discoverable, however, I do not want to add these types of settings to the contextmenu. We mainly use the context menu to change the visibility of elements/features but we don't really use it to configure them/change appearance. Also, the context menu is already pretty full and I don't want to overload it.
I'm open to other ideas to make them more discoverable. Maybe a "configure" entry in the overflow menu of the toolbar?
Yeah I like the idea of an action in the "..." menu to configure all things editor related by narrowing down a settings search in the settings editor.
verification steps: Right click on the tab bar (not on a tab) At the bottom of the context menu there is an action "Configure Tabs...", press it Settings editor should open with tabs related settings


Question: { "name": "code-oss-dev", "version": "1.83.0", <del> "distro": "46e7bb69af9f06de037c3d7e8f61de4a679f9ef1", </del> <ins> "distro": "c13fa037c20b672a48c9e7990df10998974196f9", </ins> "author": { "name": "Microsoft Corporation" },

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: { "name": "code-oss-dev", "version": "1.83.0", <del> "distro": "46e7bb69af9f06de037c3d7e8f61de4a679f9ef1", </del> <ins> "distro": "c13fa037c20b672a48c9e7990df10998974196f9", </ins> "author": { "name": "Microsoft Corporation" },

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: * Given a stable rendered state, checks every rendered element whether it needs * to be probed for dynamic height. Adjusts scroll height and top if necessary. */ <del> private _rerender(renderTop: number, renderHeight: number): void { </del> <ins> private _rerender(renderTop: number, renderHeight: number, updateScrollTop: boolean = true): void { </ins> const previousRenderRange = this.getRenderRange(renderTop, renderHeight); // Let's remember the second element's position, this helps in scrolling up

Issue Type: <bBug</bWhen : one mouse wheel scroll in extension view: moves 100px one mouse wheel scroll in settings editor: moves 100px When : one mouse wheel scroll in extension view: moves 100px, with slight animation one mouse wheel scroll in settings editor: moves 15~25px, without animation I'm using a Logitech G502 Lightspeed mouse, without any scrolling tweaking softwares. ! VS Code version: Code - Insiders 1.48.0-insider (, 2020-08-05T05:30:25.429Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
I don't see this, any idea
I believe this setting is ignored for macOS. Duplicate of
Actually not a duplicate. Interesting. I need to get my hands on a mouse to see if I can repro.
Created a PR that fixes this:


Question: } if (shadowElement) { <del> this.updateShadowElement(shadowElement, dimension, position); </del> <ins> this.updateShadowElement(shadowElement, dimension, /*position*/ undefined); </ins> } if (this._shadowElementViewInfo && this._shadowElementViewInfo.width <= 0 && this._shadowElementViewInfo.height <= 0) {

I've seen this a lot over the past month and it seems like a major issue for notebooks, please consider investigating further for November ! ! ! ! While running integration tests today (23rd November): ! Version: 1.74.0-insider (user setup) Commit: Date: 2022-11-23T05:25:25.108Z Electron: 19.1.3 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
it's likely related to the position performance optimization this month.
Can you try debugging. I can never reproduce this The best place to start debugging is: Let me know if you want to pair on this later this afternoon too
Was finally able to repo this but not reliably. It seems to rely on a new being created, but this doesn't always happen. The most reliable repo for me: with a notebook and text editor in a single editor group the notebook editor down to create a new group below the text editor grab the notebook editor and drag it right to move the bottom editor to the right I think the root cause is that the notebook widget is passed the wrong position. I'm going to work around this by making the notebook editor ignore the position it is given, however this will also undo the performance fixes we made this iteration for notebook layout I don't fully understand the grid layout code but it seems that is being set incorrectly in cases where a new BranchNode/SplitView is created. Here's what I see happening after step 3 of the repo above: setter is called calls which creates a new the constructor, a new Split View is created is called on it. At this point, of the split view is: the time layout is called on the notebook editor widget, is computed as zero. This results in the wrong layout. Looking at the code, we can see that is passed in as the absolute offset in step 4: <img width="1104" alt="Screenshot 2022-11-30 at 12 48 54 PM" src="https://user-"If I then slightly resize the window, here's what happens: call on the split View for the new group now is: we layout the notebook editor, is now correctly computed as
Created new issue: , thanks for the steps


Question: const userExtensions = await this.webExtensionsScannerService.scanUserExtensions(profileLocation ?? this.userDataProfileService.currentProfile.extensionsResource); extensions.push(...userExtensions); } <del> return Promise.all(extensions.map(e => toLocalExtension(e))); </del> <ins> return extensions.map(e => toLocalExtension(e)); </ins> } async install(location: URI, options: InstallOptions = {}): Promise<ILocalExtension> {

All of a sudden, I no longer have GHPRI installed. When I go into I see Settings Sync removed it 11 hours ago, but I'm 100% sure I never uninstalled it. I know I have Settings Sync enabled in both and are those scenarios doing unexpected things to my settings sync? !
I am sure that 4 days ago I re- the extension. Today, I'm on another machine, and GHPRI is again gone.
Lets sync on this
Closing as I couldn't repro.
I was able to reproduce this issue. will sometimes remove and then readd the GitHub Repositories, Issues & PR, and remotehub extensions, except it doesn't readd the keypair to the config, so when I return to my local installation the extensions will sometimes disappear. Not sure why it doesn't always reinstall though. Sometimes won't readd the missing extensions in time, so it gets removed. When the extensions are without the keypair, the local machine can occasionally readd the missing config and keep the extension installed; other times it won't and the extension is removed. Local machine logs from yesterday: Extension config history: Remote removes extensions: Remote readds extensions, but not marked as installed: After I reinstall the extensions locally: logs from a repro today: Extension sync history: Removed extensions: Readd extensions:
Thanks for logs and info. Reopening for investigation.
I am able to reproduce this with following steps: 1: Install GHPRI pre-release extension and sync .dev: Trigger Sync. Note that this is a builtin extension here. 2: Trigger Sync - Make sure GHPR extension is installed. 1: Uninstall GHPRI extension 2: Trigger Sync - Make sure GHPR extension is uninstalled. .dev: Trigger Sync. Make sure GHPRI extension exists in builtin extensions. 1: Trigger Sync. Nothing changes. 2: Trigger Sync. Nothing changes. This step and above step are important because, even though nothing has changed, these machines update their last sync state to have GHPRI extension has builtin extension. 1: Install GHPRI pre-release extension and sync 2: Trigger Sync GHPRI extension is not installed. Come back to Desktop 1: GHPRI extension is removed.
Improved extensions merging to make sure the builtin extensions are handled properly.


Question: const userExtensions = await this.webExtensionsScannerService.scanUserExtensions(profileLocation ?? this.userDataProfileService.currentProfile.extensionsResource); extensions.push(...userExtensions); } <del> return Promise.all(extensions.map(e => toLocalExtension(e))); </del> <ins> return extensions.map(e => toLocalExtension(e)); </ins> } async install(location: URI, options: InstallOptions = {}): Promise<ILocalExtension> {

Each machine remembers what builtin extensions it syncs and make sure it won't remove them while syncing. Also some logs to get more information if the issue still occurs.
If I uninstall GHPRI from desktop and then Sync Now in , the extension appears to be 'uninstalled' on , is that expected? ! After reloading the extension is still installed though.
I don't have a second desktop to verify with at the moment.
Yeah in your case it is expected because, GHPRI extension seems to be user installed and settings sync is removing that.


Question: } getScopedEnvironmentVariableCollection(scope: vscode.EnvironmentVariableScope | undefined): IEnvironmentVariableCollection { <del> if (this._extension && scope) { // TODO: This should be removed when the env var extension API(s) are stabilized checkProposedApiEnabled(this._extension, 'envCollectionWorkspace'); } </del> const scopedCollectionKey = this.getScopeKey(scope); let scopedCollection = this.scopedCollections.get(scopedCollectionKey); if (!scopedCollection) {

For example: Context:
As we anticipate we might need shell scoping as well in the future, use something similar to instead. Updated proposal: One issue with this is that carries optional properties. Hence an alternative could be:
The required would need to be removed when we a second one anyway, we can just treat and the same as
Sorry what do you mean by the "second one"? Mostly I was trying to follow : But I guess we don't have to strictly follow it?
by a second one I mean a second scope, we don't want the user to explicitly enumerate all the scopes to set it which would do.
Updated proposal:
Closing in favor of as these issues were only open to finalize proposed API.
Moving this out of June as it's a feature request.
I was expecting this so it's easier to understand for an API user:
That's what I had initially had , you're the one who recommended that perhaps we should put it inside itself:
API sync also seemed to be in agreement with that, but maybe we should check again.
my mistake, I forgot some of the conversations as this has gone through a few iterations
Based on discussion in API sync, we should probably deprecate existing API and merge it with the scoped one (similar to )
Assigning myself too so it's easier for me to track
When viewing contributions, is it possible to open the preview of the markdown directly instead of the file? ! as opposed to ! I can open preview using: !
since this is an advanced feature I think the raw markdown is more flexible as the user can navigate and copy section of it better. So I don't think this is a necessary change personally
Feedback before finalization: Add an interface implements Add to the Clarify how scoped interacts with the non-scoped collection Don't deprecate
Should we also call out how it's applied in addition to (and after) the global collection? Looks good otherwise
Sure, I have modified the docstrings to append it I plan to have the implementation ready but only merge and adopt it in Python extension next week to avoid multiple iterations.


Question: }); } <ins> private onDidChangeActivityBarLocation(): void { this.updateTitleArea(); const id = this.getActiveComposite()?.getId(); if (id) { this.onTitleAreaUpdate(id!); } this.updateActivityBarVisiblity(); this.rememberActivityBarVisiblePosition(); } </ins> override updateStyles(): void { super.updateStyles();

Steps to Reproduce: the Activity Bar Position as Hidden Command: View: Focus Activity Bar Then: ! Activity Bar still takes up screen space, but doesn't display the icons Version: 1.84.0 Commit: Date: 2023-11-01T11:29:04.398Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.84.0 Chrome/114.0.5735.289 Electron/25.9.2 Safari/537.36
Probably depends on
Probably
Not related to
!


Question: // folder.1=>folder.2 if (isFolder && name.match(/(d+)$/)) { <del> return name.replace(/(d+)$/, (match: string, ...groups: any[]) => { return strings.pad(parseInt(groups[0]) + 1, groups[0].length); }); </del> <ins> return name.replace(/(d+)$/, (match: string, ...groups: any[]) => { let number = parseInt(groups[0]); return number < maxNumber ? strings.pad(number + 1, groups[0].length) : strings.format('{0}.1', groups[0]); }); </ins> } // 1.folder=>2.folder if (isFolder && name.match(/^(d+)/)) { <del> return name.replace(/^(d+)/, (match: string, ...groups: any[]) => { return strings.pad(parseInt(groups[0]) + 1, groups[0].length); }); </del> <ins> return name.replace(/^(d+)(.*)$/, (match: string, ...groups: any[]) => { let number = parseInt(groups[0]); return number < maxNumber ? strings.pad(number + 1, groups[0].length) + groups[1] : strings.format('{0}{1}.1', groups[0], groups[1]); }); </ins> } // file/folder=>file.1/folder.1

Have file named in explorer Copy/paste it Window hangs This is from We shouldn't attempt this when the number is = Number.MAXSAFEINTEGER. It loops forever here: This bug will happen whenever incrementFileName fails to modify the file name.
I guess only interesting thing about this what we should do in this case as we need to create some new file name? Add without changing the original number?
that sounds reasonable


Question: // Each line and column clause have 6 groups (ie no. of expressions in round brackets) export const lineAndColumnClauseGroupCount = 6; <del> const MAX_LENGTH = 2000; </del> <ins> const InvalidLinkResult = 'Invalid Link Result'; const MAX_LENGTH = 2000; let map = new Map<string, TerminalLink | string>(); </ins> export class TerminalValidatedLocalLinkProvider extends TerminalBaseLinkProvider { constructor( private readonly _xterm: Terminal,

Logging errors from the file service I notice that the terminal seems to stat the terminal prompt multiple times: ! Notice the at the end of the file path.
When you hover a line in the terminal links are resolved, one of the link providers gets confirmation on whether it's a file or directory and gives a high confidence link (underline shows when you hover without cmd) and on macOS we treat as a valid path character. This is how it's always worked. but we could cache this stat result with a TTL (10s?) so it doesn't spam so many stat calls and will be able to return the link faster on successive hovers.


Question: }) ); } <del> export const foldBackgroundBackground = registerColor('editor.foldBackground', { light: transparent(editorSelectionBackground, 0.3), dark: transparent(editorSelectionBackground, 0.3), hcDark: null, hcLight: null }, nls.localize('foldBackgroundBackground', "Background color behind folded ranges. The color must not be opaque so as not to hide underlying decorations."), true); export const editorFoldForeground = registerColor('editorGutter.foldingControlForeground', { dark: iconForeground, light: iconForeground, hcDark: iconForeground, hcLight: iconForeground }, nls.localize('editorGutter.foldingControlForeground', 'Color of the folding control in the editor gutter.')); </del>

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When folded, folding ranges are displayed in the editor as a single line with darkened background. Hovever (as of ), on the minimap, the background of this line is not darkened. This makes it harder to navigate using the minimap. !
Either this isn't working or steps are non trivial
Ok, see this working unless I have render characters enabled


Question: import { TerminalStatus } from 'vs/workbench/contrib/terminal/browser/terminalStatusList'; import Severity from 'vs/base/common/severity'; import { ICommandService } from 'vs/platform/commands/common/commands'; <ins> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; </ins> export class EnvironmentVariableInfoStale implements IEnvironmentVariableInfo { readonly requiresAction = true;

Testing Show extension display name instead of extension id. You can also make them links to open the extension editor. <img width="522" alt="image" src="https://user-"
what's the right way to do this? I had a look and could only see async methods to do this which seemed odd to me (and would require some refactoring to get the tooltip to work with async).
1 I see this as well
There are multiple ways depending upon the source of this extension id. Since it is a running extension, I would prefer to use this api since you do not want to have async
thanks will use that. You don't have an id -name map to avoid iterating over it multiple times though?
There exists one, but it is async


Question: } } <ins> export class LineSequence implements ISequence { constructor( private readonly trimmedHash: number[], private readonly lines: string[] ) { } getElement(offset: number): number { return this.trimmedHash[offset]; } get length(): number { return this.trimmedHash.length; } getBoundaryScore(length: number): number { const indentationBefore = length === 0 ? 0 : getIndentation(this.lines[length - 1]); const indentationAfter = length === this.lines.length ? 0 : getIndentation(this.lines[length]); return 1000 - (indentationBefore + indentationAfter); } } function getIndentation(str: string): number { let i = 0; while (i < str.length && (str.charCodeAt(i) === CharCode.Space || str.charCodeAt(i) === CharCode.Tab)) { i++; } return i; } </ins> class Slice implements ISequence { private readonly elements: Int32Array; private readonly firstCharOnLineOffsets: Int32Array;

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: declare function require(path: string): any; <del> const enabledSetting = 'markdown.math.enabled'; </del> <ins> const markdownMathSetting = 'markdown.math'; </ins> export function activate(context: vscode.ExtensionContext) { function isEnabled(): boolean {

It would be nice to have a entry in the configuration section of markdown-math extension. A place where users could put their custom math macros.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


Question: displayName: Extract openssl prebuilt # inspired by: https://github.com/emk/rust-musl-builder/blob/main/Dockerfile <del> - bash: | set -e sudo apt-get update sudo apt-get install -yq build-essential curl file git graphviz musl-dev musl-tools linux-libc-dev pkgconf zip unzip xutils-dev ninja-build sudo ln -s "/usr/bin/g++" "/usr/bin/musl-g++" || echo "link exists" displayName: Install build dependencies </del> <ins> - ${{ if or(eq(parameters.VSCODE_BUILD_LINUX_ALPINE_ARM64, true), eq(parameters.VSCODE_BUILD_LINUX_ALPINE, true)) }}: - bash: | set -e sudo apt-get update sudo apt-get install -yq build-essential musl-dev musl-tools linux-libc-dev pkgconf xutils-dev sudo ln -s "/usr/bin/g++" "/usr/bin/musl-g++" || echo "link exists" displayName: Install musl build dependencies </ins> - ${{ if eq(parameters.VSCODE_BUILD_LINUX_ARMHF, true) }}: - bash: | set -e sudo apt-get install -yq gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf binutils-arm-linux-gnueabihf <del> displayName: Install cross compilation toolchains </del> <ins> displayName: Install arm32 toolchains - ${{ if eq(parameters.VSCODE_BUILD_LINUX_ARM64, true) }}: - bash: | set -e sudo apt-get install -yq gcc-aarch64-linux-gnu g++-aarch64-linux-gnu binutils-aarch64-linux-gnu displayName: Install arm64 toolchains </ins> - task: NodeTool@0 inputs:

The stage is now a bottleneck to having the platform specific stages run: ! Each job compiles each target serially. We could further parallelize all targets across different jobs. !


Question: // do not scroll the viewport if resized element is out of viewport heightDiff = size - originalSize; } else { <del> if (anchorIndex !== null && anchorIndex > index && anchorIndex <= lastRenderRange.end) { </del> <ins> if (anchorIndex !== null && anchorIndex > index && anchorIndex < lastRenderRange.end) { </ins> // anchor in viewport // resized element in viewport and above the anchor heightDiff = size - originalSize;

a notebook that has several cells, and put this code in the second to last cell the cell so that it has output, and shrink the window so that the single cell+output takes up the whole scrollable region the cell again with shift+enter :bug: the notebook ends up scrolling up, instead of showing the full output and next cell. !
The current behavior of the list view is to use the second visible element as an anchor which can cause some strange behavior. In this scenario: next cell is focused and revealed, making that cell the anchor as second visible, since the executing cell takes up the rest of the visible region. output is removed, moving more elements into view from above is and the initial anchor is no longer the second element, so it is scrolled out of view I'll try to play around with some options, but my initial thought would be to use the executing cell as the anchor. The output could expand and push the next cell out of view, but typing in that cell will bring it back into view. cc
I wanted to see the behavior locally. I really can't seem to repro this, my notebook stays pretty stable as the cell shrinks and grows. What am I missing?
I think I found it. I believe you have disabled, am I correct? Can you reproduce this when flipping that setting back to the default value of ?
It repro's with or without - you just need to scroll down enough so that the resized cell is only partially visible. The strange behavior is due to the notebook cell list setting different anchors depending on whether the element top is above the render top.
As I looked into the remaining open issue and PR , I was trying to grasp what the issue really is, what has been actually fixed and what's left to fix. Then, I pulled latest and ran out of sources and this is even worse than my last recording. Everything jumps around even when the cell is fully in view: Did just break this even more? I suggest reverting , pausing, simplifying the problem, narrowing in on a solution and consider fixing it in debt week so as to not cause regressions during this endgame week. cc
thanks for the testing, the two recordings you posted above were using different execution commands so I want to ensure we refer to the same behavior: in , it's re-executing the active cell (ctrl+enter), which should always stay visually stable.


Question: // do not scroll the viewport if resized element is out of viewport heightDiff = size - originalSize; } else { <del> if (anchorIndex !== null && anchorIndex > index && anchorIndex <= lastRenderRange.end) { </del> <ins> if (anchorIndex !== null && anchorIndex > index && anchorIndex < lastRenderRange.end) { </ins> // anchor in viewport // resized element in viewport and above the anchor heightDiff = size - originalSize;

I think it still works this way out from source in the latest , from what I saw, it's running shift+enter: run cell and move to next This command moves focus to the next cell, so the cell is now the focused cell Then the output of the previous cell (which is no longer focused) starts to grow The change introduced via 's last PR was to ensure that the focused cell stay visually stable, once they are revealed into view can you confirm if this is what you are seeing?
I captured a recording for what probably was comparing, right side is Stable and left side Insiders In both setup, the next cell is fully visible In Stable, shift+enter moves the next cell up, and then push it down, but the new focused cell is still visible in the viewport at the end In Insiders, shift+enter moves the next cell up, and when the previous starts to grow, it does not move the focused cell downwards Even though the new behavior is more self explanatory (from our perspective), but unluckily is not the same as Jupyter Lab. It means we are changing from one custom behavior (our previous heuristics) to another (always keep focused cell stable)
Thanks for clarifying this It was not clear to me that (1) shift+enter and clicking the run cell action did different things, nor that (2) this bug was only about one of these actions.
fixed by


Question: // do not scroll the viewport if resized element is out of viewport heightDiff = size - originalSize; } else { <del> if (anchorIndex !== null && anchorIndex > index && anchorIndex <= lastRenderRange.end) { </del> <ins> if (anchorIndex !== null && anchorIndex > index && anchorIndex < lastRenderRange.end) { </ins> // anchor in viewport // resized element in viewport and above the anchor heightDiff = size - originalSize;

Currently the scroll top position update is not context-aware, meaning when we have cell height changes, we don't know if it's because output height change, or users re-run a cell and outputs are updated/replaced, or users shift+enter to run cell and navigate to next cell. Users might have different expectations for each scenario but currently our heuristics for updating the scroll top didn't take the context into account. Let's use this issue to finalize the desired behavior of scroll top update. The polished/new design should cover [ ] Update element height API respects context (execution, execute+create, output update) [ ] Reveal API should handle out of sync view/content height Click the run button or press Ctrl+Enter to run focused cell If there is no enough room/space after the cell (e.g., the focused cell is the last cell) Users have disabled [ ] There is no output before execution, the view should scroll up to reveal the output fully [ ] Some users might want the bottom of the output to be fully revealed, when the output is larger than the viewport [ ] There is output before execution, the cell position should be persistent Users have enabled [ ] Reveal cell output If there is enough room after the cell [ ] Reveal cell output [ ] If the cell input is larger than the viewport, execute cell should reveal the output properly [ ] Collapse focused cell output should always keep the cell in viewport [ ] Type/Pasting content into focused cell should keep the cell in viewport [x] [ ] Notebook cell list reveal api might reveal a position on a cell whose view height is not synced with real editor height yet. [ ] Execute non-focused cell, should it keep the focused cell position persistent or keep the top of the target cell persistent? [ ] Non focused cell output height change should not change scroll top on scroll [ ] Shift+enter executes and moves focus to next cell, then new focused cell should always be in viewport [x] Scroll top position of inactive notebook editor should not change if the first partially visible cell's height change
I noticed an issue recently, is this related? Paste a large amount of text into a code cell The notebook scrolls down so far that the focused code cell is out of the viewport I can open a separate issue if you want
I guess what you were seeing is , I'll update the description to include this.
Couple cases discovered in the latest notebook sync.


Question: // do not scroll the viewport if resized element is out of viewport heightDiff = size - originalSize; } else { <del> if (anchorIndex !== null && anchorIndex > index && anchorIndex <= lastRenderRange.end) { </del> <ins> if (anchorIndex !== null && anchorIndex > index && anchorIndex < lastRenderRange.end) { </ins> // anchor in viewport // resized element in viewport and above the anchor heightDiff = size - originalSize;

both of these are likely tied to outputLineLimit being large @ 100 when the shift-enter behavior is set to "firstline" the events are as follows: first line of next cell is focused and shown at the bottom of the viewport output is cleared and the focused cell is pulled upwards against the currently executing cell output streams and pushes the focused cell out of the viewport. my ideal thoughts: anchor the focused cell (with setting), maintaining the first line visible. output will stream in, pushing the executing cell upwards out of the viewport shift-enter set to "fullCell" and next cell has a large output focus shifts to next cell, and the viewport exposes the bottom of the output for that cell. there is no cell editor in the viewport my thoughts: "fullCell" behavior should show the top of the next cell editor at the top of the viewport


Question: const computedSliderRatio = (maxMinimapSliderTop) / (scrollHeight - viewportHeight); const sliderTop = (scrollTop * computedSliderRatio); <del> if (minimapLinesFitting >= lineCount) { </del> <ins> let extraLinesAtTheBottom = 0; if (options.scrollBeyondLastLine) { const expectedViewportLineCount = viewportHeight / lineHeight; extraLinesAtTheBottom = expectedViewportLineCount; } if (minimapLinesFitting >= lineCount + extraLinesAtTheBottom) { </ins> // All lines fit in the minimap const startLineNumber = 1; const endLineNumber = lineCount;

Issue Type: <bBug</bThe preview in the minimap slider is wrong when: The minimap is NOT overflown (doesn't need to scroll internally when the editor is scrolled) is (default value) When is set to , the preview is shown as expected. Reproducible without extensions: Yes ! The slider preview ends at the beginning of the block comment, while it should contain a portion of it. VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: Windows_NT x64 10.0. <details<summaryExtensions (15)</summaryExtensionVersion ------ gitstash2.1.0 bracket-pair-colorizer-20.0.28 vscode-eslint1.8.2 todo-tree0.0.129 svg0.1.4 tag-rename0.2.1 vscode-simple-icons1.11.4 dotenv1.0.1 vscode-docker0.6.1 vscode-javascript-booster0.10.2 code-settings-sync3.2.9 markdown-preview-enhanced0.3.13 code-spell-checker1.7.0 language-pde1.3.0 markdown-all-in-one2.2.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
A new observation: It's not about the state of the window (maximized/restored), it's about weather the minimap is overflown or not (needs to scroll internally when the editor is scrolled). I edited the issue accordingly.
Another observation: has no effect on the issue either. The problem is that the minimap height is not calculated correctly when is , the extra lines that this setting adds are not accordingly to the minimap height, only when it's NOT overflown (i.e. when ).


Question: let goToSymbolHint = ''; if (providerHasSymbols) { if (goToSymbolKb) { <del> goToSymbolHint = localize('goToSymbolHint', 'Go to a symbol ({0})', goToSymbolKb); </del> <ins> goToSymbolHint = localize('goToSymbolHint', 'Go to a symbol ({0}).', goToSymbolKb); </ins> } else { goToSymbolHint = localize('goToSymbolHintNoKb', 'To go to a symbol, configure a keybinding for the command Go To Symbol in Accessible View'); }

Testing In the screenshot below, "Chat: Insert at Cursor" should be "Chat: Insert into New File" !


Question: let goToSymbolHint = ''; if (providerHasSymbols) { if (goToSymbolKb) { <del> goToSymbolHint = localize('goToSymbolHint', 'Go to a symbol ({0})', goToSymbolKb); </del> <ins> goToSymbolHint = localize('goToSymbolHint', 'Go to a symbol ({0}).', goToSymbolKb); </ins> } else { goToSymbolHint = localize('goToSymbolHintNoKb', 'To go to a symbol, configure a keybinding for the command Go To Symbol in Accessible View'); }

Testing There's a double close parenthesis here: <img width="305" alt="image" src=""
Also a missing on the line


Question: <del> <svg xmlns="http://www.w3.org/2000/svg" width="12" height="18" viewBox="0 0 12 18"><style>.st0{fill:#fff}</style><title>flipped-cursor-mac</title><path d="M4.3 16.5l1.6-4.6H1.1L11.5 1.2v14.4L8.7 13l-1.6 4.5z"/><path class="st0" d="M11 14.5l-2.5-2.3L7 16.7 5 16l1.6-4.5h-4l8.5-9M0 12.5h5.2l-1.5 4.1L7.5 18 9 14.2l2.9 2.3V0L0 12.5z"/></svg> </del>  No newline at end of file <ins> <svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 13 19" style="enable-background:new 0 0 13 19;" width="13" height="19"><style type="text/css">.st0{stroke:#FFFFFF;stroke-miterlimit:10;}</style><title>flipped-cursor-mac</title><path class="st0" d="M5.3,16.6l1.6-4.7H2.1L12.5,1.2v14.4L9.7,13l-1.6,4.6c-0.2,0.5-0.8,0.8-1.3,0.6L6,17.9 C5.4,17.7,5.1,17.2,5.3,16.6z"/></svg> </ins>

VSCode Version:1.30.2 OS Version: Applies to Windows and OS X When the cursor flips on line numbers the SVG used has inconsistency's with the system defaults, e.g. tail is shorter Does this issue occur when all extensions are disabled?: Yes


Question: *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; <del> import { IWorkingCopy, IWorkingCopyBackup } from 'vs/workbench/services/workingCopy/common/workingCopyService'; </del> <ins> import { IWorkingCopy, IWorkingCopyBackup, WorkingCopyCapabilities } from 'vs/workbench/services/workingCopy/common/workingCopyService'; </ins> import { URI } from 'vs/base/common/uri'; import { Emitter } from 'vs/base/common/event'; import { Disposable } from 'vs/base/common/lifecycle';

<!-- 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: ) { super(); <ins> this._widget = this._register(this._instantiationService.createInstance(ResizableHoverWidget, this._editor)); </ins> // Instantiate participants and sort them by `hoverOrdinal` which is relevant for rendering order. this._participants = []; for (const participant of HoverParticipantRegistry.getAll()) {

When you hover over a type in a TypeScript file, the tooltip that appears has a very low max width, making it difficult to read long type signatures.
I would include a screenshot but it's not easy to take a screenshot keeping the tooltip on screen!
! Errors are quite unreadable if the width does not adapt to the font size.
! it would be nice if the tip used the available space instead of wrapping at an arbitrary point in c# too
!
! Same problem using rust's language server.
General styling control would be very helpful. Also line-height. Another approach would be to have a bottom panel that displays the full error and the tooltip displays a shortened version.
!
! When using the auto import feature it is often impossible to differentiate whats what as the import path is cut off due to the limited width of the suggestions window.
Is this something we can adjust with custom css? It makes snippet infoormation very difficult to read as well. !
Same in Python. We have to jump through hoops trying to flow doc nicely. And when it appears OK on Windows, it breaks on Mac... ! And it is inconsistent. Ex, hover is OK ! But completion list decides to wrap. What gives? ! Looks like hover respects markdown while completion item doc is plain string and gets wrapped randomly.
!
Someone say long type signatures? !
Here is a workaround by hacking the file "C:Program FilesMicrosoft VS Coderesourcesappoutvsworkbench" Simply append the code above after the original content of file, and restart VSCode. (Title bar may alert a warning message "Not Supported" and hacked changes would be overridden by updating VSCode) !
It would be nice to have some control on the width. The above does work but vscode presents the message your installation may be corrupt on restarting.
Instead of hacking the CSS directly as mentioned above, I recommend using the to just override the current CSS. That way when VSCode updates, you can just reload the custom css file that you have specified (personally, I have a project where I hold configurations for my shell, Spacemacs, etc. and this custom CSS file goes there). Until it's officially supported, hacking the CSS is likely the best route.


Question: ) { super(); <ins> this._widget = this._register(this._instantiationService.createInstance(ResizableHoverWidget, this._editor)); </ins> // Instantiate participants and sort them by `hoverOrdinal` which is relevant for rendering order. this._participants = []; for (const participant of HoverParticipantRegistry.getAll()) {

The suggested widths above were a bit much for me, so I settled on the following values for now:
What is preventing the devs from providing a configuration option for this? This issue has been open for almost 2 years, and it bugs me on a daily basis. Would love to see it fixed.
(since you seem like the most relevant person to ping) is anything likely to be done about this?
I would love to hear an explanation from devs too. What are the difficulties of implementing this? I imagine it's settings a dynamic max-width and adding some more lines to add it in Settings. Are there other design blockers?
Will you take a look at this? In 3 days it will be a 2 year anniversary for this simple feature request.
Assigned to and as I remember we are going to have some UX improvements for editor tooltips and so on.
maybe now is the time to take this on? current iteration tries to solve parameter hints ux and this is not that much different
! I employed CSS and put together full instructions: [Custom CSS and JS Loader extension][1] macOS VS Code: VS Code Insiders: Linux: : [1]: Restart VSCode Ignore "VSCode is corrupt" error You can choose to suppress this notice forever Run command "Reload Custom CSS and JS"
just as a disclaimer, if anyone modifies the CSS/JS of the app, it comes up at “corrupted” in diagnostic checks, and you’ll typically get pushback if you report issues and include diagnostic information. Or, at least, I received pushback when I had custom CSS/JS enabled, and wouldn’t receive help until I turned it off (even though it was harmless/not related to the issue I was having). While this is indeed an okay workaround, we should just keep making our voices heard so that this is natively supported.
100% agree. This is just a workaround. It's hard enough to read TypeScript lint as it is! :)
Currenlty using VSCode 1.30.2, followed instructions step by step, but it's not working. I don't even get the VSCode corrupt error. I'm running Windows 10 (V.1803). Edit: It was my mistake. For anyone who's having trouble, make sure to run Enable Custom CSS and JS from the command palette. Simply restarting won't work.


Question: ) { super(); <ins> this._widget = this._register(this._instantiationService.createInstance(ResizableHoverWidget, this._editor)); </ins> // Instantiate participants and sort them by `hoverOrdinal` which is relevant for rendering order. this._participants = []; for (const participant of HoverParticipantRegistry.getAll()) {

This issue seems to be fixed in 1.32.0-insider (1.32.0-insider) . I hope this is an intended behavior. I want to thank the developers.
This change is related to . I confirmed that the max width of is still small as mentioned above. <img width="867" alt="2019-02-22 17 06 19" src="https://user-"
Update: in , only the hovers for problems and the hovers with code blocks become to have larger width. Others have smaller width.
Hello there,your solution is great,but I want to ask how to get rid of the word at the title.As sort of OCD,sufferring from that. thx a lot!
This extension was created specifically for solving this:
This has been a long standing annoyance, with an issue that's like 2 and a half year ago. It shouldn't take much effort to have a config property that overrides the width/height of the tooltip, surely? Like, 10 mins of effort? <img width="525" alt="Screen Shot 2019-07-18 at 6 41 15 PM" src="https://user-"
if it's really 10 mins of effort, then I'm sure you can submit a PR for this? I definitely can't do this in anywhere close to 10 mins, so it would be much appreciated!
Seriously, I want instead of this: ! At least something like this (with syntax highlighting it will be even better): !
There's already been a PR. I really don't understand this. I figure most VScode devs develop VScode in VScode, are they comfortable with the current state?
fyi, it would be great if the hover could be resized
How is this issue 4 years old and such a basic thing still isn't implemented?
Is there any word on whether we could see this soon? The suggestion widget has had resizing enabled since v1.51 in October, 2020. Is this tooltip widget considerably harder to add this feature for or are there additional considerations to be made? Whether it's a click to resize, or a manual adjustment in settings, could we have an update on the status of this addition? Opening new editor tabs just to properly read code annotations for some more descriptive components on my large monitors does feel like an unnecessary extra step.


Question: ) { super(); <ins> this._widget = this._register(this._instantiationService.createInstance(ResizableHoverWidget, this._editor)); </ins> // Instantiate participants and sort them by `hoverOrdinal` which is relevant for rendering order. this._participants = []; for (const participant of HoverParticipantRegistry.getAll()) {

might be very related and close to what you did here:
Hi, Instead of configuring the max width as the title says, could the tooltip hover be resizable ? (Also check for more info on what was done with the suggest widget)
It's sad to see that it's still not a thing.. I would really like to adjust the height of hover description tooltips.. The big brother Visual Studio does a much better job already. Let VS Code catch up a little..
another possible view for this issue
It is 2022/11/11. Christmas is close and I made sure Santa knows what I want!
"Excuse me, it's 2023"
This one will be my favorite. Copilot suggestions and TS errors just can't be seen in this tooltip. It's time to fix it.
If this is still open and no one is looking at it, I'll take a crack at it. Feel free to assign it to me if that's alright.
Hey all, thank you for your patience. A PR has been made which is currently under work but nearing its completion. You may find it here: Once this PR is merged, you will be able to resize content hovers within Insiders.
Would you add "Reset Hover Widget Size" command in Command Palette? Like we have for suggest widget: "Reset Suggest Widget Size". It would be good if we could reset the size to the initial one.
Thank you very much. 1 Is it correct, that this would not stay across different sessions? 2 The default max width is very small, is there any consideration, of increasing that?
Will this feature also allow us to define the window size of a hover provider in a extension above the current limitations?
Hi if is is decided that the hover widget size should be configurable, there will be a command to clear the persisted sizes. This feature is still under discussion. Hi depending on the implementation, it is possible that the persisted sizes are persisted or not across different sessions. This is still under discussion. Currently the implementation is such that the maximum natural width is the same as before. Hi the current implementation does not provide this functionality. This could be addressed in a separate issue as it is related to the usage of the hover widget by extensions. The current PR that is worked on is the following:
Thanks a lot.


Question: ) { super(); <ins> this._widget = this._register(this._instantiationService.createInstance(ResizableHoverWidget, this._editor)); </ins> // Instantiate participants and sort them by `hoverOrdinal` which is relevant for rendering order. this._participants = []; for (const participant of HoverParticipantRegistry.getAll()) {

And do you consider increasing the default size, that is unfitting to most real world scenarios? The windows is so small, that I feel the need to increase it even on my WXGA Laptop.
Hey all, thank you for the patience. A PR has been merged in order to make the content hover resizable. The change should be visible in tomorrow's VS Code insiders version and in the next stable release which will happen in the coming two weeks. There currently is no mechanism to save the content hover - we are discussing how best to approach it. You may track the issue on persisting the hover content here: we are currently not thinking about increasing the default maximum size. However it is possible that we implement the persisting mechanism as follows: when you increase the content hover size to a specific size, this size is persisted, and it is applied as maximum default size on the next hover appearances. This potential implementation is still under discussion by our team.
Just want to say thank you you seem to have been tackling a lot of these high-level nitpicks that have been in the VSCode backlog for years, and for that I am very appreciative.
I can't find a command to clear/reset hover widget size, is this has been ?
Hi currently the command does not exist because a persisting mechanism has not been put into place as of yet. It will appear when the latter is .
Oh okay, thanks a lot


Question: font-weight: normal; } <ins> h1 code, h2 code, h3 code, h4 code, h5 code, h6 code { font-size: inherit; line-height: auto; } </ins> a:hover { color: #4080D0; text-decoration: underline;

In Markdown preview, inline formats in single backticks (`) seems small sized in heading. Headings of different sizes have this problem in common. !
fyi
Yes, this collides with our font-size rule for the code block which is not ideal. I am happy to accept PRs for making markdown CSS better. The CSS is defined in
Still happens with our new markdown extension: !


Question: const err = new Error('An extension called process.crash() and this was prevented.'); console.warn(err.stack); }; <ins> // Set ELECTRON_RUN_AS_NODE environment variable for extensions that use // child_process.spawn with process.execPath and expect to run as node process // on the desktop. // Refs https://github.com/microsoft/vscode/issues/151012#issuecomment-1156593228 process.env['ELECTRON_RUN_AS_NODE'] = '1'; </ins> } interface IRendererConnection {

Testing <img width="348" alt="image" src="https://user-"
Extension fails to launch child_process during initialization Will check if the issue is isolated to this extension with a minimal example using module
Was able to isolate the issue, firstly as pointed above the extension makes an attempt to launch a child process via the helper which basically emulates options and passes them eventually into Since variant relies on when node executable path is not provided, this will default to use the Electron executable that is used to create the extension host. Now there are two problems with this usage, (i) execa module will not add the env variable, so the exectuable cannot be launched as intended. (ii) We also disable calling Electron executable as unless flag is provided in the call site. For the (ii) we automatically add the flag at both and callsites internally in the runtime, so this should not be a concern for the extension authors. As for (i), if the extension author used the vanilla then the env variable would be set internally by the runtime. But since the call is done via a 3rd party module, I think it is upto the extension authors to ensure the env variable is provided if they rely on the Electron executable. I feel like there is no action required from runtime/VSCode core for this issue, but we should loop in the extension author to fix this on their end. Thoughts ?
So what exactly is different in the utility process vs. child process today? I did not fully understand.
When extension host is created via , internally the runtime would launch the process with env variable set and we never remove this variable explicitly in the extension host after launch (i-e) , this would indirectly help above scenarios since the env gets inherited by extensions. This is not the case with utility process since there is no runtime induced env variable, the extensions have to explicitly add them if they rely on the electron executable. I would say the previous behavior was a hidden bug and is visible now with the utility process api.
Oh yeah understood! I think I somewhat agree that we need to just document this to extension authors.
btw, since this is a public issue, I've shared it with the dendron extension author directly to track
hey, dendron author here. thanks for looping us in on this. so as I understand, we have two options: either use vanilla or set when using the module.


Question: const err = new Error('An extension called process.crash() and this was prevented.'); console.warn(err.stack); }; <ins> // Set ELECTRON_RUN_AS_NODE environment variable for extensions that use // child_process.spawn with process.execPath and expect to run as node process // on the desktop. // Refs https://github.com/microsoft/vscode/issues/151012#issuecomment-1156593228 process.env['ELECTRON_RUN_AS_NODE'] = '1'; </ins> } interface IRendererConnection {

is this an accurate understanding?
yup that is correct. To clarify, only when ends up using on the desktop extension host.
Got it. What's the timeline for us patching this? Is this already live in insider?
The change is not default in insiders yet, it is currently behind an environment variable , can give more context on the timeline.
after discussing with the team, we have decided to push a workaround in core to avoid breaking the extension community with the new process type for extension host. You don't need to make the adjustments outlined in


Question: *--------------------------------------------------------------------------------------------*/ import { Event } from 'vs/base/common/event'; <del> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IDebugService, VIEWLET_ID, IDebugSession } from 'vs/workbench/contrib/debug/common/debug'; </del> <ins> import { IDisposable, dispose } from 'vs/base/common/lifecycle'; </ins> import { IProgressService, ProgressLocation } from 'vs/platform/progress/common/progress'; <del> import { dispose, IDisposable } from 'vs/base/common/lifecycle'; </del> <ins> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IDebugService, IDebugSession, VIEWLET_ID } from 'vs/workbench/contrib/debug/common/debug'; </ins> import { IViewsService } from 'vs/workbench/services/views/common/viewsService'; <del> import { NotificationPriority } from 'vs/platform/notification/common/notification'; </del> export class DebugProgressContribution implements IWorkbenchContribution {

I am writing a debugger adapter. I use ProgressStartEvent/ProgressUpdateEvent/ProgressEndEvent to report some debug opertions' progress information. In previous versions, the progress information was shown in right-bottom corner, however, in 1.86.0, the progress information is shown in status bar instead. I think this is not a good idea, as user might not be able to notice the progress information. If there is a workaround if I still want to show progress information in right-bottom corner of VS code? Thanks! Bill Zhang
I haven't yet found a 1.86 commit that specifically changes this behaviour. Have you perhaps been trying out this new 1.86 feature?
If this is a confirmed regression, it would help to know which change caused it. We maintain a based CLI tool  that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression. Steps: install (if not yet done) follow the instructions until you found the offending build (its fine to leave the commit empty) report back the commit range in this issue Thanks!
The progress information was shown in status bar, not a pop-up window as before versions, so I have no way to enable/disable notification. In addition, notification was shown as before in right-bottom corner.
85 does not have this issue.
If you cannot find the actual commit causing this using , then you need to provide a minimal repro for us to try out.