Question: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import { IListRenderer, IListVirtualDelegate } from 'vs/base/browser/ui/list/list'; import { List } from 'vs/base/browser/ui/list/listWidget'; import { range } from 'vs/base/common/arrays'; import { timeout } from 'vs/base/common/async'; suite('ListWidget', function () { test('Page up and down', async function () { const element = document.createElement('div'); element.style.height = '200px'; element.style.width = '200px'; const delegate: IListVirtualDelegate<number> = { getHeight() { return 20; }, getTemplateId() { return 'template'; } }; let templatesCount = 0; const renderer: IListRenderer<number, void> = { templateId: 'template', renderTemplate() { templatesCount++; }, renderElement() { }, disposeTemplate() { templatesCount--; } }; const listWidget = new List<number>('test', element, delegate, [renderer]); listWidget.layout(200); assert.strictEqual(templatesCount, 0, 'no templates have been allocated'); listWidget.splice(0, 0, range(100)); listWidget.focusFirst(); listWidget.focusNextPage(); assert.strictEqual(listWidget.getFocus()[0], 9, 'first page down moves focus to element at bottom'); // scroll to next page is async listWidget.focusNextPage(); await timeout(0); assert.strictEqual(listWidget.getFocus()[0], 19, 'page down to next page'); listWidget.focusPreviousPage(); assert.strictEqual(listWidget.getFocus()[0], 10, 'first page up moves focus to element at top'); // scroll to previous page is async listWidget.focusPreviousPage(); await timeout(0); assert.strictEqual(listWidget.getFocus()[0], 0, 'page down to previous page'); listWidget.dispose(); }); test('Page up and down with item taller than viewport #149502', async function () { const element = document.createElement('div'); element.style.height = '200px'; element.style.width = '200px'; const delegate: IListVirtualDelegate<number> = { getHeight() { return 200; }, getTemplateId() { return 'template'; } }; let templatesCount = 0; const renderer: IListRenderer<number, void> = { templateId: 'template', renderTemplate() { templatesCount++; }, renderElement() { }, disposeTemplate() { templatesCount--; } }; const listWidget = new List<number>('test', element, delegate, [renderer]); listWidget.layout(200); assert.strictEqual(templatesCount, 0, 'no templates have been allocated'); listWidget.splice(0, 0, range(100)); listWidget.focusFirst(); assert.strictEqual(listWidget.getFocus()[0], 0, 'initial focus is first element'); // scroll to next page is async listWidget.focusNextPage(); await timeout(0); assert.strictEqual(listWidget.getFocus()[0], 1, 'page down to next page'); // scroll to previous page is async listWidget.focusPreviousPage(); await timeout(0); assert.strictEqual(listWidget.getFocus()[0], 0, 'page up to next page'); listWidget.dispose(); }); }); </ins>

Open Select the top cell and page down a few times Focus hits a cell that is longer than the viewport, which is maybe important, then the next page down moves to a higher cell
When a list item is larger than the viewport, and it's also the only element in the viewport, pressing page down will reveal to the previous element, this is because we did a here (the catch is, the last page element is also the first page element)


Question: } private async computeAndUpdateEnablement(): Promise<void> { <ins> this.enabled = false; this.class = UpdateAction.DisabledClass; this.label = this.getLabel(); </ins> if (!this.extension) { <del> this.enabled = false; this.class = UpdateAction.DisabledClass; this.label = this.getLabel(); </del> <ins> return; } if (this.extension.deprecationInfo) { </ins> return; }

Code, search for "bracket pair colorizer" how it is nicely rendered as deprecated on install -notice dialog The dialog should offer a third button to configure built-in settings instead. Same if an extension had an alternative extension. Example: ! fyi
I assume you want the extra button to replicate this link in the hover tip, right? ! As an aside, any doc yet about how an extension gets tagged as deprecated?
yes, a button that will replicate that behaviour correct. No docs yet written. I plan to add them soon. The process is to write an email to us or to ping us on GitHub. In the future we will have a more straightforward approach when MP adds UI.
I feel, the third option would be a general options like More Information... clicking on this shall open the extension editor. This will be consistent and useful so that user will get enough info before taking an action
"More Information..." might work, but in order to have one less hop we could render: "Install EXTENSION_NAME Instead" "Enable Native Settings Instead" That would just do the action right straight away. I am not sure if those button names are too long. So just a suggestion. Whatever you prefer...
Yah I see your point, but going to extension editor gives user more information and an opportunity to look at the alternative extension before installing. And also I do not like that this button changes with extension. More Information... would be consistent.
That's fair. We can start with your proposal and see how it goes. My only concern with "More Information" is that the user might think it is more information about the deprecation. While we actually want to guide the user to a solution. So it is something like "More about the alternative". I am not sure if there is a good button label to represent this.
<img width="308" alt="image (1)" src="https://user-"
Changed the second button as follows ! !
Awesome!!


Question: export class SettingsChangeRelauncher extends Disposable implements IWorkbenchContribution { <del> private titleBarStyle: 'native' | 'custom' | undefined; private windowControlsOverlayEnabled: boolean | undefined; private windowSandboxEnabled: boolean | undefined; private nativeTabs: boolean | undefined; private nativeFullScreen: boolean | undefined; private clickThroughInactive: boolean | undefined; private updateMode: string | undefined; </del> <ins> private readonly titleBarStyle = new ChangeObserver<'native' | 'custom'>('string'); private readonly windowControlsOverlayEnabled = new ChangeObserver('boolean'); private readonly windowSandboxEnabled = new ChangeObserver('boolean'); private readonly nativeTabs = new ChangeObserver('boolean'); private readonly nativeFullScreen = new ChangeObserver('boolean'); private readonly clickThroughInactive = new ChangeObserver('boolean'); private readonly updateMode = new ChangeObserver('string'); </ins> private accessibilitySupport: 'on' | 'off' | 'auto' | undefined; <del> private workspaceTrustEnabled: boolean | undefined; private settingsProfilesEnabled: boolean | undefined; private experimentsEnabled: boolean | undefined; private enablePPEExtensionsGallery: boolean | undefined; </del> <ins> private readonly workspaceTrustEnabled = new ChangeObserver('boolean'); private readonly settingsProfilesEnabled = new ChangeObserver('boolean'); private readonly experimentsEnabled = new ChangeObserver('boolean'); private readonly enablePPEExtensionsGallery = new ChangeObserver('boolean'); </ins> constructor( @IHostService private readonly hostService: IHostService,

I think a class like this could be helpful: Usage: Originally posted by in
please let me know if you like this!
This class is primarily owned by Hence assigning to him.
Yes, feel free, I can review a PR, thanks.


Question: let waitMarkerError: Error; const randomTmpFile = paths.join(os.tmpdir(), Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 10)); try { <del> writeFileAndFlushSync(randomTmpFile, ''); </del> <ins> fs.writeFileSync(randomTmpFile, ''); </ins> waitMarkerFilePath = randomTmpFile; argv.push('--waitMarkerFilePath', waitMarkerFilePath); } catch (error) {

This is very useful when working with the commandline, and to pass the result directly into the editor. It's especially useful for getting a file out of git's history, eg: FWIW, this works in Sublime.
+1
Here is my workaround (I'm on OSX so might need to adjust accordingly): create ~/bin/codestdin: Then run: Now git log, git show, git diff pipe correctly into vscode
Similar to approach, I've this to my bash profile to wrap the command... definitely not flawless, but it works for my use cases (so far). e.g.
For you have to modify the function a bit and use , because is a BUILTIN in and will return the function itself: What does not work is something like
Hello, For using the redirect, does this express the intent of getting of copy of the file contents assigned to an anonymous file buffer? Would that be similar to for intents sake? I wonder if are the only thing to care for that scenario? Thank you. Good day.
hello yes this should be equivalent as as I know.
Can we get some priority for this issue? It's been open since 2016 (that's 552 days!) and it's a bit ridiculous that VSCode still doesn't provide this extremely rudimentary shell interoperability.
+1
Pushed a change to feed the contents of stdin to a file and have it open in VS Code ( is implied when doing so): ! This currently works by or not, which is a bit brittle. If someone spawns VS Code without terminal emulation we might wrongly assume that data is coming in via stdin and open a tmp file. If it turns out that there are too many regressions, I might have to add a startup argument (, ) to explicitly enable this. If someone has a better idea how to detect if data is flowing in via stdin let me know.
This is great to see! Thanks so much! Is Atom's implementation the same?
as far as I know, Atom does not support this.
huh, I really thought it did, but local tests (and ) suggest not. Anyway, thanks again!
Hello, would you be kind enough to update your OP to note that Atom did and does not as of writing actively support this (probably just taking it out).


Question: let waitMarkerError: Error; const randomTmpFile = paths.join(os.tmpdir(), Math.random().toString(36).replace(/[^a-z]+/g, '').substr(0, 10)); try { <del> writeFileAndFlushSync(randomTmpFile, ''); </del> <ins> fs.writeFileSync(randomTmpFile, ''); </ins> waitMarkerFilePath = randomTmpFile; argv.push('--waitMarkerFilePath', waitMarkerFilePath); } catch (error) {

There is the PR for them, but it is nice to have the proper perspective that VSCode is in the forefront of this kind of feature. Its no harm to stay, just misleading. Thank you. Good day.
done
Thanks for the feature, very nice. Just my 2 cents on feedback, the implied seems unnecessary. EG: when I pipe to TextMate it gives me my prompt back. There might be other reasons though for having the wait that I'm not thinking about though. Regardless, cheers and thanks for the work!
the calling process is waiting because it is not clear how long data is being sent to . It could be that the editor is already opened but data is still flowing. A workaround on your side would probably to send the command to the background by appending "" at the end?
Hrm, wasn't aware that was even possible. I feel like most commands I pipe complete then output is sent to the editor.
A terminal can have a specific encoding set which my solution did not yet account for. I pushed a change to try a little bit of terminal encoding guessing but I think the solution is not ideal. If someone has a better idea ( ?), let me know: Linux/macOS: use the output of running as encoding Windows: use by default any OS: if you specify an environment variable it will always win over the guessing This will not help if you change the encoding of the terminal ad-hoc as that does not seem to cause any configuration change that the command would detect. On Windows I see the  command but the output of that command seems to be intertwined with human readable text and not just the encoding. If someone has a better idea for Windows, please speak up.


Question: /* No Tab Close Button */ .monaco-workbench > .part.editor > .content > .one-editor-silo > .container > .title .tabs-container > .tab.close-button-off { <del> padding-right: 28px; /* make room for dirty indication when we are running without close button */ </del> <ins> padding-right: 12px; transition: padding-right ease-in-out 100ms; </ins> } .monaco-workbench > .part.editor > .content > .one-editor-silo > .container > .title .tabs-container > .tab.close-button-off.dirty { background-repeat: no-repeat; background-position-y: center; background-position-x: calc(100% - 6px); /* to the right of the tab label */ <ins> padding-right: 28px; /* make room for dirty indication when we are running without close button */ </ins> } .vs .monaco-workbench > .part.editor > .content > .one-editor-silo > .container > .title .tabs-container > .tab.close-button-off.dirty {

If user does not want the close button to be visible - vscode could make tabs more narrow to show more tabs. Tabs with changed content could get wider to show the 'dot' denoting unsaved file ! !
[ ] Verify: when the tab close button is disabled, the tabs are not leaving room for the dirty indicator until the editor is actually dirty.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Found this stack while scanning through some failing smoke test runs From Deepak:
What are some verification steps for this issue?
I did check logs last week and could no longer find this.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Type: <bBug</bIn the most recent insiders version, audio cues no longer play. I ensured that the audio cues I expect are enabled (e.g. error) and entered the following json as an example: I ensured that the error was reported when moving through errors with f8, yet the cue doesn't play when I come across the line with up/down arrow keys VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-05T07:36:58.753Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
cc
We didn't touch anything there the last months, maybe it is caused by an electron update. Will investigate for the next release.
I can reproduce this. Easy repros steps: 1 list audio cues command cues do not produce sound Works fine on latest stable. Does not work on Insiders. fyi since most likely caused by Electron update (thus adding label). Maybe our future planned ffmpeg change will fix this? thanks a lot for reporting this, and sorry about this breakage.
You're welcome, I'm running insiders for a reason Looking forward to a fix.
Let me also assign since we will now support would you like that all our audio cues are in format? If yes, would you like me to reach out to our sound designer for this? Thanks
can you track the conversion in a separate issue, this particular issue is a regression with the ffmpeg build shipped with internal builds. There was a recent build architecture change and it impacted this. I would like to close this issue as part of the next Electron version update :)
makes sense, thanks! There is actually already this one which we can use for the conversion
The same problem using code-insiders into a fedora workstation 36.
It is working again with orca.
lovely, thanks for confirming. Adding verified label.
For me it also works like a charm on Windows.
For some reason I can't explain, this issue seems to have returned on my fedora workstation. No sound is played when I move the cursor to lines that contain breakpoints, errors and etc. Version: 1.71.0-insider Commit:
Confirmed on Windows. Could tests for this be somehow?


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

Sorry for the regression, but this is a temporary expected breakage because we are updating our supported audio formats , audio cues will be updated to new format this iteration as part of /cc
Sorry about that We just pushed a fix, and the VS Code insiders from tomorrow will have the fix.
Thanks Given this feature turns out to be pretty important for us visually impaired users, would it be possible to create a system test for this? I assume it should be possible to throw a audio cue at FFMPEG and make it fail if the sound doesn't play?
that's a good idea. However I leave this up to since he is driving this from engineering and would have better ideas how we could test it exactly.
We would need a way to ask the OS if an application played some sound.
It works again, at least on my environment. Thanks.
awesome, thanks for letting us know.
I can confirm that it works here as well. Hopefully it stays that way


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at .


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up!


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"

I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- 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: import { editorBackground, editorForeground, inputBackground } from 'vs/platform/theme/common/colorRegistry'; import { ChatModel } from 'vs/workbench/contrib/chat/common/chatModel'; import { Range } from 'vs/editor/common/core/range'; <ins> import { ServiceCollection } from 'vs/platform/instantiation/common/serviceCollection'; import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </ins> export class InlineChatContentWidget implements IContentWidget {

Just asked hi: ! Expected: ! Version: 1.88.0-insider (user setup) Commit: Date: 2024-03-25T05:49:32.344Z Electron: 28.2.6 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. GitHub Copilot Chat v0.14. (pre-release)
because of
To verify configure have a very wide view port ask AI to change some code make sure the input widget is full width of the zone widget


Question: import { editorBackground, editorForeground, inputBackground } from 'vs/platform/theme/common/colorRegistry'; import { ChatModel } from 'vs/workbench/contrib/chat/common/chatModel'; import { Range } from 'vs/editor/common/core/range'; <ins> import { ServiceCollection } from 'vs/platform/instantiation/common/serviceCollection'; import { IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </ins> export class InlineChatContentWidget implements IContentWidget {

cmd+i now cmd+backspace invokes instead of deleting the line in the text editor The ChatWidget is writing its context keys to the editor's ContextKeyService, so we need a scoped CKS at some point, either inside the ChatWidget or outside in the inline widgets
pushing a fix to use a scoped CKS but this does look like debt. Isn't a better fix to reset context keys when hiding/dispose the chat widget?
I don't think those context keys should be applied on the editor at all, they are intended to just be active inside the widget's dom tree.


Question: } else if (minimapSide === 'right') { this._rootDomNode.style.marginLeft = '0px'; } <ins> this._rootDomNode.style.zIndex = '11'; </ins> } public getId(): string {

VSCode Version: Code 1.7.2 (, 2016-11-21T22:14:18.217Z) OS Version: Linux x64 4.8.0-26-generic Focus on debug: ! Focus on extensions: ! Can the bright one be on debug as well?
For me all viewlets show the same feedback once focussed: ! Please clarify the issue you see.
Oh I mean via tab focus.
! still they all look the same to me?
I see what you mean, when you focus into the current active viewlet, the orange bar to the left shows up stronger. I am not sure who this, I think might be the one?
This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our for filing issues. Thank you for your contributions.
Closing as designed, no plans to change it currently.


Question: .monaco-action-bar .action-item .monaco-select-box { cursor: pointer; <del> min-width: 110px; </del> <ins> min-width: 70px; </ins> min-height: 18px; padding: 2px 23px 2px 8px; }

Issue Type: <bBug</bthe integrated console viewlets to a vertical layout the viewlet narrow When wide enough: ! Once narrowed: ! Expected result: Debug Console search bar shrinks/hides itself in order to show other tabs first (like in the first screenshot). The 3 dots "works", but is, at least in my opinion, more annoying than not being able to search in the Debug Console when the viewlet is narrow. VS Code version: Code 1.63.2 (, 2021-12-15T09:40:02.816Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --
The min width is 300, I think that can be narrower. The problems view filter input goes into the body when the view is too narrow, which is sorta cool <img width="571" alt="image" src="https://user-"but I won't implement that right now
Actually it was easy to opt into that. I tweaked the min widths and also when the pane is narrow, the filter box will move down into the body
Holy, I forgot about this issue! Love the idea of copying the behaviour of the Problems tab! Excited to try it on Insiders :) Thanks !


Question: __vsc_command_complete() { builtin local __vsc_history_id=$(builtin history | tail -n1 | awk '{print $1;}') <del> if [[ "$__vsc_history_id" == "$__vsc_last_history_id" ]]; then builtin printf "033]633;D007" else builtin printf "033]633;D;%s007" "$__vsc_status" __vsc_last_history_id=$__vsc_history_id </del> <ins> # Don't write the command complete sequence for the first prompt without an associated command if [[ "$__vsc_initialized" == "1" ]]; then if [[ "$__vsc_history_id" == "$__vsc_last_history_id" ]]; then builtin printf "033]633;D007" else builtin printf "033]633;D;%s007" "$__vsc_status" __vsc_last_history_id=$__vsc_history_id fi </ins> fi __vsc_update_cwd }

!
updated Insider's and the problem remains
I think this is the same as We will need to always send the exit code and have it get evaluated on the renderer against the extracted command name to fix these problems.
sometimes reproduces on mac
you can check if this is the same issue () by running a command a few times and then when is run if it's a single entry or multiple in the output.
interesting to me that it allows repro on linux/WSL and does so inconsistently on mac. here's linux: !
K, let's try understand this a little better then, that shouldn't happen as the initial history id is 0:
Oh I figured out when it reproes on mac - if you run the same command in a different terminal, then the second and beyond ones don't have an exit code
Running the command again in the terminal where you first ran the command works every time and does not repro on mac. So mac steps are: in terminal 1 - again in terminal 1 - in terminal 2 - Linux: a terminal and run any command - placeholder decoration shown for the first one regardless of exit code
It would be nice to fix this since is the default shell used
Think I see the problem, PR incoming.


Question: public fulfillOverlayWidget(detail: string): IMouseTargetOverlayWidget { return MouseTarget.createOverlayWidget(this.target, this._getMouseColumn(), detail); } <del> public withTarget(target: HTMLElement | null): HitTestRequest { return new HitTestRequest(this._ctx, this.editorPos, this.pos, this.relativePos, target); } </del> } interface ResolvedHitTestRequest extends HitTestRequest {

<!-- 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: 1.88.0-insider in Safari OS Version: macOS Steps to Reproduce: Safari open a file with: to the right of any the cursor goes to the beginning of the line not the end This does not repro in stable
I didn't do any changes the last couple of milestones that could (easily) explain this. Can you reproduce this in the monaco editor? If so, can you do a bisect?
I bisected it to this commit: (the commit before it) does not repro the issue. This wasn't in Monaco editor, I just used run code web:
This commit is just a rename refactoring. It is very unlikely it causes this... This does not reproduce in chrome, right?
The bug does not reproduce in Edge on macOS, but it repros in Safari.
Unfortunately, I don't have access to Safari. Can you double check that this is caused by that commit? Can you locally rename the class back to the original name and see if it still happens? It does not make any sense that this commit would cause this behavior only on Safari.
Ok and I paired a bit on this and are really stumped. Bad news: That commit I called out seems to be a red herring. Good news: we can repro in the Monaco Editor Playground.


Question: public fulfillOverlayWidget(detail: string): IMouseTargetOverlayWidget { return MouseTarget.createOverlayWidget(this.target, this._getMouseColumn(), detail); } <del> public withTarget(target: HTMLElement | null): HitTestRequest { return new HitTestRequest(this._ctx, this.editorPos, this.pos, this.relativePos, target); } </del> } interface ResolvedHitTestRequest extends HitTestRequest {

Here's a side by side of two versions of the dev build: <img width="1680" alt="image" src=""You can see when I click to the right of a line, the older (working) build has the correct position here, while the newer broken build has column 1. Here are the links to these versions: Working: Broken: I believe this is out of both of our depths at this point so I'm passing to you This is a regression so I think it should be fixed before we release (assuming I'm not the only one to repro)
Did a bisect using and it points to
In that case, it is most likely .


Question: let uninitializedPromise: TPromise<any> | null = null; const emitter = new Emitter<any>({ onFirstListenerAdd: () => { <del> uninitializedPromise = this.whenInitialized().then(() => { </del> <ins> uninitializedPromise = this.whenInitialized(); uninitializedPromise.then(() => { </ins> uninitializedPromise = null; this.send(request.raw); });

Open a large workspace Start a text search Press esc See busy process still running is never called here:


Question: .settings-editor > .settings-body .settings-tree-container .setting-item.setting-item-list .setting-list-sibling, .settings-editor > .settings-body .settings-tree-container .setting-item.setting-item-list .setting-list-object-widget .setting-list-object-key, .settings-editor > .settings-body .settings-tree-container .setting-item.setting-item-list .setting-list-object-widget .setting-list-object-value { <del> white-space: normal; overflow-wrap: normal; </del> <ins> white-space: nowrap; text-overflow: ellipsis; overflow: hidden; </ins> } .settings-editor > .settings-body .settings-tree-container .setting-item-bool .setting-value-checkbox {

Repro: Add a long string item to a list setting, e.g., . Try an item without spaces (like a really long identifier) or with spaces. Expected: Overflow of the item is handled somehow, e.g., elision, broken to separate lines with enough spaces. Actual: The item text overflows horizontally and vertically (depending on spaces in the item), overlapping other UI elements. E.g., <img width="854" alt="Screenshot 2024-02-27 at 11 31 47" src=""<img width="815" alt="image" src=""Version: 1.86.2 Commit: User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Embedder:


Question: "vscode-debugprotocol": "1.10.0", "vscode-textmate": "2.0.1", "winreg": "1.2.0", <del> "xterm": "git+https://github.com/sourcelair/xterm.js.git#55fb5db", </del> <ins> "xterm": "git+https://github.com/sourcelair/xterm.js.git#5e662d0", </ins> "yauzl": "2.3.1" }, "devDependencies": {

VSCode Version: 1.2.0-insider OS Version: OS X El Capitan 10.11.5 Steps to Reproduce: by default settings !
Cannot type cyrillic as well
Upstream issue
This is one of the issues I want to focus on for v1.4


Question: } protected abstract _showTerminalCloseConfirmation(): TPromise<boolean>; <ins> protected abstract _showNotEnoughSpaceToast(): void; </ins> public abstract createTerminal(shell?: IShellLaunchConfig, wasNewTerminalAction?: boolean): ITerminalInstance; public abstract createTerminalRenderer(name: string): ITerminalInstance; public abstract createInstance(terminalFocusContextKey: IContextKey<boolean>, configHelper: ITerminalConfigHelper, container: HTMLElement, shellLaunchConfig: IShellLaunchConfig, doCreateProcess: boolean): ITerminalInstance;

With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.


Question: accessor.get(IAccessibleViewService).next(); } } <ins> registerAction2(AccessibleViewNextAction); </ins> class AccessibleViewPreviousAction extends Action2 { static id: 'editor.action.accessibleViewPrevious'; constructor() { super({ <del> id: AccessibleViewPreviousAction.id, </del> <ins> id: 'editor.action.accessibleViewPrevious', </ins> precondition: accessibleViewIsShown, keybinding: { primary: KeyMod.Alt | KeyCode.BracketLeft,

One way of resolving this would be repeating the position information when I press any of the commands, even if there is no change. Another possibility would be to prevent the widget from refocusing when I am in the first / last element, and I try to move beyond that element. In that way pressing the next command will not produce any feedback if I am in the last one, and the previous will not produce any feedback if I am in the first one. Does it make sense? In any case, this would be a refinement, not something that would prevent someone from using the feature. Originally posted by in
Something else to consider when fine tuning the responses. Right now, position information is announced using an alert in macOS, and a status message in Windows. This is a situation where it makes sense to use an alert in all platforms so that screen readers prioritize this over other events. For example, right now JAWS is announcing position information after reannouncing the widget.
Huh, I'm using for all platforms here which appears to be platform agnostic I think it might just be a JAWS issue - does this repro when using NVDA?
It doesn't, but NVDA handles aria-live differently. You may be right dough. I'll debug NVDA on Monday and we'll know for sure which event it is seeing. JAWS may be simply prioritizing the focus event.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Focus an accessible view for which there are several elements (like chat responses or notifications). Verify that if you are on the first or last element, pressing next or previous does not result in repeated alerts. it should not notify the screen reader user as nothing has changed.
Note to verifier there's an issue to disable these actions when they cannot be taken, which is the better fix.
Verified. With NVDA, if I press enter on the Next button while on the last chat response, the focus goes back to the response text instead of staying on the button, though that might be by design.


Question: }); }); <del> test('updateElementHeight with anchor #121723: focus element out of viewport', async function () { </del> <ins> test('updateElementHeight with no scrolling', async function () { config.setUserConfiguration(NotebookSetting.scrollToRevealCell, 'none'); await withTestNotebook( [ ['# header a', 'markdown', CellKind.Markup, [], {}], ['var b = 1;', 'javascript', CellKind.Code, [], {}], ['# header b', 'markdown', CellKind.Markup, [], {}], ['var b = 2;', 'javascript', CellKind.Code, [], {}], ['# header c', 'markdown', CellKind.Markup, [], {}] ], async (editor, viewModel, disposables) => { viewModel.restoreEditorViewState({ editingCells: [false, false, false, false, false], editorViewStates: [null, null, null, null, null], cellTotalHeights: [50, 100, 50, 100, 50], cellLineNumberStates: {}, collapsedInputCells: {}, collapsedOutputCells: {}, }); const cellList = createNotebookCellList(instantiationService, disposables); cellList.attachViewModel(viewModel); // render height 210, it can render 3 full cells and 1 partial cell cellList.layout(210, 100); // init scrollTop and scrollBottom assert.deepStrictEqual(cellList.scrollTop, 0); assert.deepStrictEqual(cellList.getViewScrollBottom(), 210); // scroll to 5 cellList.updateElementHeight2(viewModel.cellAt(0)!, 50); cellList.scrollTop = 5; assert.deepStrictEqual(cellList.scrollTop, 5); assert.deepStrictEqual(cellList.getViewScrollBottom(), 215); cellList.setFocus([1]); cellList.updateElementHeight2(viewModel.cellAt(0)!, 100); assert.deepStrictEqual(cellList.scrollHeight, 400); // Any change in cell size should not affect the scroll height with scrollToReveal set to none assert.deepStrictEqual(cellList.scrollTop, 5); cellList.updateElementHeight2(viewModel.cellAt(0)!, 50); assert.deepStrictEqual(cellList.scrollTop, 5); cellList.updateElementHeight2(viewModel.cellAt(0)!, 250); assert.deepStrictEqual(cellList.scrollTop, 5); }); }); test('updateElementHeight with no scroll setting and cell editor focused', async function () { config.setUserConfiguration(NotebookSetting.scrollToRevealCell, 'none'); await withTestNotebook( [ ['# header a', 'markdown', CellKind.Markup, [], {}], ['var b = 1;', 'javascript', CellKind.Code, [], {}], ['# header b', 'markdown', CellKind.Markup, [], {}], ['var b = 2;', 'javascript', CellKind.Code, [], {}], ['# header c', 'markdown', CellKind.Markup, [], {}] ], async (editor, viewModel, disposables) => { viewModel.restoreEditorViewState({ editingCells: [false, false, false, false, false], editorViewStates: [null, null, null, null, null], cellTotalHeights: [50, 100, 50, 100, 50], cellLineNumberStates: {}, collapsedInputCells: {}, collapsedOutputCells: {}, }); const cellList = createNotebookCellList(instantiationService, disposables); cellList.attachViewModel(viewModel); // render height 210, it can render 3 full cells and 1 partial cell cellList.layout(210, 100); // init scrollTop and scrollBottom assert.deepStrictEqual(cellList.scrollTop, 0); assert.deepStrictEqual(cellList.getViewScrollBottom(), 210); cellList.setFocus([1]); editor.focusNotebookCell(cellList.viewModel?.cellAt(1)!, 'editor'); cellList.updateElementHeight2(viewModel.cellAt(0)!, 100); assert.deepStrictEqual(cellList.scrollHeight, 400); // We have the cell editor focused, so we should anchor to that cell assert.deepStrictEqual(cellList.scrollTop, 50); cellList.updateElementHeight2(viewModel.cellAt(0)!, 50); assert.deepStrictEqual(cellList.scrollTop, 0); cellList.updateElementHeight2(viewModel.cellAt(0)!, 250); assert.deepStrictEqual(cellList.scrollTop, 250 + 100 - cellList.renderHeight); }); }); test('updateElementHeight with focused element out of viewport', async function () { </ins> await withTestNotebook( [ ['# header a', 'markdown', CellKind.Markup, [], {}],

Ideas to experiment with: Don't shrink a cell while it is executing -less jumpy as output is replaced change the anchor heuristic from "if the resizing cell is partially visible" to "if the cell's output will shrink out of view" Anchor to a focused cell if the focus is in the cell's editor cc
For the new heuristics we are adding (growing upwards or downwards), they should probably be interrupted the moment users start to scroll, for example, if I scroll manually to a specific position, I would expect the scroll top not to change.
I disagree - That could mean if you have a cell focused and anchored, and you scroll to get it higher in the view, it would then start getting pushed down as the previous cell grows.
If I scroll to get it lower in the view, as I want to read the cells above, and since it's still in the view and focused/anchored, the cells I was reading will then pushed upwards, right? This feels unnatural compared to how browser handles scrolling or Terminal. Terminal scenario might be closer to this, as it usually sticks to the bottom when the shell is streaming outputs, but the very moment we scroll upwards, it stops sticking to the bottom.


Question: } this.handlers.set(id, handler); <del> this.proxy.$registerProfileContentHandler(id, handler.name, extension.identifier.value); </del> <ins> this.proxy.$registerProfileContentHandler(id, handler.name, handler.description, extension.identifier.value); </ins> return toDisposable(() => { this.handlers.delete(id);

Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.


Question: "@microsoft/1ds-post-js": "^3.2.13", "@vscode/iconv-lite-umd": "0.7.0", "@vscode/vscode-languagedetection": "1.0.21", <del> "@xterm/addon-canvas": "0.6.0-beta.16", "@xterm/addon-image": "0.7.0-beta.14", "@xterm/addon-search": "0.14.0-beta.16", "@xterm/addon-serialize": "0.12.0-beta.16", "@xterm/addon-unicode11": "0.7.0-beta.16", "@xterm/addon-webgl": "0.17.0-beta.16", "@xterm/xterm": "5.4.0-beta.16", </del> <ins> "@xterm/addon-canvas": "0.6.0-beta.17", "@xterm/addon-image": "0.7.0-beta.15", "@xterm/addon-search": "0.14.0-beta.17", "@xterm/addon-serialize": "0.12.0-beta.17", "@xterm/addon-unicode11": "0.7.0-beta.17", "@xterm/addon-webgl": "0.17.0-beta.17", "@xterm/xterm": "5.4.0-beta.17", </ins> "jschardet": "3.0.0", "tas-client-umd": "0.1.8", "vscode-oniguruma": "1.7.0",

<!-- 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.85.0 (Universal) OS Version: Darwin arm64 22.5.0 Terminal input doesn't work ( is too slow almost feels like not working ) when using in Aux Window. Steps to Reproduce: Open Aux Terminal Window In Full Screen Mode or make it Full screen afterwords.
This seems to be working in OSS Dev container.
This looks to me like a case of scheduling something on the main window which gets throttled once hidden. is the terminal using scheduler for rendering such as RAF or ?
I can reproduce and its pretty bad.
off-topic: is there a way to move panel to separate window. e.g. bottom drawer or individually like terminal, debug console ?
PR fixing it


Question: keybinding: { primary: KeyMod.Alt | KeyCode.KeyW, mac: { primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.KeyW }, <del> when: ContextKeyExpr.or(TerminalContextKeys.focusInAny, TerminalContextKeys.findFocus), </del> <ins> when: TerminalContextKeys.findVisible, </ins> weight: KeybindingWeight.WorkbenchContrib }, precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated),

Type: <bBug</bAlt+C or Alt+W or Alt+R Now if area with code is in focus, broken search parameter selector will appear without search panel itself. If terminal is in focus, search panel will appear. I think it is completely unneccesary to intercept alt+c globally when no search panel is opened. In my setup it leads to conflict with alt+c fzf's key binding in terminal. VS Code version: Code 1.86.2 (, 2024-02-13T19:41:37.860Z) OS version: Linux x64 6.7.6-arch1-1 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ vscode-nginx-conf0.3.2 vscode-cython0.3.10 vscode-docker1.29.0 autopep82023.8.0 debugpy2024.2.0 isort2023.10.1 python2024.2.1 vscode-pylance2024.2.2 jupyter2024.1.1 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.348.0 cmake-tools1.17.17 cpptools1.19.4 cpptools-extension-pack1.3.0 rust-analyzer0.3.1860 cmake0.0.17 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This is feature - it influences bahavior of Add Selection To Next Find Match (<kbdCtrl</kbd+<kbdD</kbd) and Select all occurrences of current selection (<kbdCtrl</kbd+<kbdShift</kbd+<kbdL</kbd). However not sure how regexp is useful here, except it would be applied for next find.
Can you share a screen recording? I'm not sure if I understand what you're talking about.


Question: keybinding: { primary: KeyMod.Alt | KeyCode.KeyW, mac: { primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.KeyW }, <del> when: ContextKeyExpr.or(TerminalContextKeys.focusInAny, TerminalContextKeys.findFocus), </del> <ins> when: TerminalContextKeys.findVisible, </ins> weight: KeybindingWeight.WorkbenchContrib }, precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated),

This video shows the behavior of vscode after pressing alt+c
This video shows what I expected after pressing alt+c in terminal It is configured with following lines in .zshrc:
I can repro when the widget is visible even if my focus is in the editor
Never mind, the little toolbar in the editor is coming from the editor command , not our terminal one.


Question: ] }, [TerminalSettingId.EnablePersistentSessions]: { <del> description: localize('terminal.integrated.enablePersistentSessions', "Persist terminal sessions for the workspace across window reloads."), </del> <ins> description: localize('terminal.integrated.enablePersistentSessions', "Persist terminal sessions/history for the workspace across window reloads."), </ins> type: 'boolean', default: true }, [TerminalSettingId.PersistentSessionReviveProcess]: { <del> markdownDescription: localize('terminal.integrated.persistentSessionReviveProcess', "When the terminal process must be shutdown (eg. on window or application close), this determines when the previous terminal session contents should be restored and processes be recreated when the workspace is next opened.nnCaveats:nn- Restoring of the process current working directory depends on whether it is supported by the shell.n- Time to persist the session during shutdown is limited, so it may be aborted when using high-latency remote connections."), </del> <ins> markdownDescription: localize('terminal.integrated.persistentSessionReviveProcess', "When the terminal process must be shutdown (eg. on window or application close), this determines when the previous terminal session contents/history should be restored and processes be recreated when the workspace is next opened.nnCaveats:nn- Restoring of the process current working directory depends on whether it is supported by the shell.n- Time to persist the session during shutdown is limited, so it may be aborted when using high-latency remote connections."), </ins> type: 'string', enum: ['onExit', 'onExitAndWindowClose', 'never'], markdownEnumDescriptions: [

I'm always returning to projects and see the terminal messages filled with the same repeated message and would like to clean them up and not be shown as I see no value in them for myself. <img width="630" alt="CleanShot 2022-06-14 at 09 10 55 src="https://user-"<img width="622" src="https://user-"
This bugs me too, tracks only showing it once in this case by avoiding saving new parts if there is no terminal input, similar to how it only saves and restored in the first place if the terminal has been interacted with. I don't think we should be hiding the message all together as it's misleading what is part of this shell's session, command decorations would be broken for the ones that aren't part of this session (look like a bug) and it would show up like this which is a bit weird: !
Would it be possible to have an option to hide the previous session altogether and just show a new session? That would be a simple approach that would work for me personally, similar to <img width="566" alt="CleanShot 2022-06-14 at 09 40 18 src="https://user-"
you can just create a new terminal altogether by setting to false
thank you! I was searching for a setting and didn't ever find that one, kept looking for "terminal history" and "terminal clear"
the name is definitely not discoverable. I wonder if we should change it
or can we add any meta data or keywords to settings that will be picked up by search? cc
I guess?
Oh that doesn't work, do we have a way to do search keywords?
you actually want , the setting will disable process reconnect across window reloads.


Question: } this._register(browser.onDidChangeZoomLevel(_ => this._recomputeOptions())); <ins> this._register(browser.onDidChangeEditorZoomLevel(_ => this._recomputeOptions())); </ins> } private _onReferenceDomElementSizeChanged(): void {

VSCode Version: 1.1.1 OS Version: Windows 7 x64 It would be great if holding the key + spinning the mouse wheel would increase / decrease the VS Code zoom value.
I am not sure we want to zoom the entire UI when you use the mousewhell, I would expect only the editor font to increase. Thereby moving to
yes you are correct.
Didn't this feature used to work, or am I just failing to remember correctly? I was just going to report this as a bug, but maybe it never actually worked. I jump between different computer setups fairly regularly, so maybe I am just not remembering. Anyway, I found this dupe, and didn't want to submit a new issue. Thanks for your efforts By the way, I think I would expect this feature to work the same way that and work. VSCode's UI deviates from many other UIs in that it scales well, so I think I'd expect this to scale the entire UI consistently with the keyboard commands.
If this zooms only the editor, shouldn't it be seperate from ?
I would expect and to zoom only the editor. That behaviour would be consistent with most (all?) other editors and apps. Scaling the entire interface is an accessibility feature IMO, so maybe it doesn't need to use such a commonly used shortcut by default? Beyond Ctrl+Wheel, pinch to zoom should also zoom the editor.
Can this be disabled? I'm constantly accidentally zooming my text to a tiny size when I ctrl-click and accidentally brush my fingers over the trackpad.
This is disabled by default, so you must have enabled it in the past --
Thanks - I came here to vote for this feature, and it turns out I just had to turn it on! Shouldn't this issue be closed?
:+1: Closing since this is implemented. The feature is disabled by default due to numerous issues reported by users using touchpads where we begin to unexpectedly zoom in/zoom out when e.g. using ballistic scrolling and pressing the ctrl/cmd modifier. The root problem is that we cannot differentiate events coming in from a real mouse with a wheel from those coming in from touchpads / trackpads.


Question: } const originalProfile = this.userDataProfileService.currentProfile; <del> await this.userDataProfileImportExportService.createTemporaryProfile(this.userDataProfileService.currentProfile, localize('troubleshoot issue', "Troubleshoot Issue"), true); </del> <ins> await this.userDataProfileImportExportService.createTroubleshootProfile(); </ins> this.state = new TroubleShootState(TroubleshootStage.EXTENSIONS, originalProfile.id); await this.resume(); }

Testing I started the Troubleshoot issue flow and it took a long time to create my initial profile. All I had was a status bar item which took me a while to discover (I actually thought something else went wrong). I would love to see and editor / web view better guiding me through that process by: listing the steps and adding check marks when done showing me the number of bisects still necessary giving me a final report.
<img width="258" alt="capture" src=""
We should also have a UI to always stop the process (see ) for a situation where this is useful
I now see that there is a notification for each step. This makes it better, so may be a simple thing to do is to show a notificatio with progress when the profile is created instead of a simple status bar item.
Actually, setting up the trouble shooting profile should be fast and instant.
Was not for me :-(
Following notification is shown now !


Question: return; } runAccessibilityHelpAction(accessor, codeEditor, 'panelChat'); <del> }, CONTEXT_IN_CHAT_INPUT)); </del> <ins> }, CONTEXT_IN_CHAT_SESSION)); </ins> } }

Here's what I am seeing. It looks like the accessibility help always gets the content from the editor. Here's a gif: I might be doing something wrong ! Originally posted by in


Question: if (settingId !== this.currentColorTheme.settingsId) { await this.internalSetColorTheme(theme.id, undefined); } else if (theme !== this.currentColorTheme) { <ins> await theme.ensureLoaded(this.extensionResourceLoaderService); </ins> theme.setCustomizations(this.settings); await this.applyTheme(theme, undefined, true); }

Open a new folder Trust the workspace Some of the colors in the window become wrong An editor has the wrong background color Opening the theme picker fixes it !
I originally filed because I encountered this during Settings Sync but think it's not related as I also saw this when opening files: !
Step to verify connect to settings sync install and set the Dracula theme () notice that the remote indicator is violet open a new folder that is not yet trusted the trust dialog shows up, approve verify that the remote indicator is still violet, not blue


Question: this.toDispose.push(this.editor.onMouseDown((e: IEditorMouseEvent) => this.onEditorMouseDown(e))); this.toDispose.push(this.editor.onMouseMove((e: IEditorMouseEvent) => this.onEditorMouseMove(e))); this.toDispose.push(this.editor.onMouseLeave((e: IEditorMouseEvent) => { <ins> this.provideNonDebugHoverScheduler.cancel(); </ins> const hoverDomNode = this.hoverWidget.getDomNode(); if (!hoverDomNode) { return;

To be verified with: : : set the new config options start debugging The hover provider should be invoked.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.8.4: version "25.8.4" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.4.tgz#b50877aac7d96323920437baf309ad86382cb455" integrity sha512-hUYS3RGdaa6E1UWnzeGnsdsBYOggwMMg4WGxNGvAoWtmRrr6J1BsjFW/yRq4WsJHJce2HdzQXtz4OGXV6yUCLg== </del> <ins> electron@25.9.1: version "25.9.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.9.1.tgz#cc4baecbebe346b050b9cf9db9882d3d00fc4abd" integrity sha512-Uo/Fh7igjoUXA/f90iTATZJesQEArVL1uLA672JefNWTLymdKSZkJKiCciu/Xnd0TS6qvdIOUGuJFSTQnKskXQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

Type: <bBug</bThis issue is related to the Julia extension. I filed an issue , but I also filing it here (as suggested by As per the initial post of the above link, all extension work perfectly fine when the Julia extension is disabled. here are dmp files as per VS Code version: Code 1.79.2 (, 2023-06-14T08:57:04.379Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (50)</summaryExtensionVersion ------ rainbow-brackets0.0.6 vscode-django1.10.0 python-environment-manager1.0.4 python-extension-pack1.7.0 code-runner0.12.0 copilot1.94.220 vscode-github-actions0.25.8 vscode-pull-request-github0.66.2 nbpreviewer1.2.2 language-julia1.47.2 vsc-python-indent1.18.0 vscode-github0.30.7 vscode-opn1.1.2 MagicPython1.1.0 vscode-azureappservice0.24.9 vscode-azureresourcegroups0.7.5 vscode-docker1.25.2 csharp1.26.0 isort2022.8.0 python2023.10.1 vscode-pylance2023.6.40 jupyter2023.5.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.8.4: version "25.8.4" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.4.tgz#b50877aac7d96323920437baf309ad86382cb455" integrity sha512-hUYS3RGdaa6E1UWnzeGnsdsBYOggwMMg4WGxNGvAoWtmRrr6J1BsjFW/yRq4WsJHJce2HdzQXtz4OGXV6yUCLg== </del> <ins> electron@25.9.1: version "25.9.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.9.1.tgz#cc4baecbebe346b050b9cf9db9882d3d00fc4abd" integrity sha512-Uo/Fh7igjoUXA/f90iTATZJesQEArVL1uLA672JefNWTLymdKSZkJKiCciu/Xnd0TS6qvdIOUGuJFSTQnKskXQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

jupyter-keymap1.1.2 jupyter-renderers1.0.15 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.295.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.79.5 vscode-remote-extensionpack0.24.0 azure-account0.11.5 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 powershell2023.6.0 remote-explorer0.4.0 remote-server1.2.1 autodocstring0.6.1 r-debugger0.5.4 r2.8.1 vscode-open0.1.0 spellchecker1.4.0 python0.2.3 rmarkdown0.0.14 cmake0.0.17 vscode-counter3.2.1 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 jinja0.0.8 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
As mentioned in the linked issue, it happens for me as well. I can reproduce it with Insiders version too and the same happens with a few older julia-vscode extensions I tested. <details<summaryVS Code version</summary</details
There seems to be an issue with spawning a process. The symbolicated logs seem to have the same form.
I'd expect that this happens when we try to spawn the Julia process that powers the LS. Any chance we can debug this further? I assume we can't handle libuv failing to spawn a process anywhere in the extension code, right?
As asked in the I want to add that I can reproduce this as well. From the linked thread:
Sorry for the delayed response, can you please provide the output of the following steps to understand the error 1) In a terminal set the following env variable 2) Launch VSCode from the same terminal session with arguments that redirect stdout and stderr to a file as seen below, replace the file paths where appropriate Additionally, once the extension host crashes open command palette in VSCode and run and attach the output from the tab of the developer tools that got opened.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.8.4: version "25.8.4" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.4.tgz#b50877aac7d96323920437baf309ad86382cb455" integrity sha512-hUYS3RGdaa6E1UWnzeGnsdsBYOggwMMg4WGxNGvAoWtmRrr6J1BsjFW/yRq4WsJHJce2HdzQXtz4OGXV6yUCLg== </del> <ins> electron@25.9.1: version "25.9.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.9.1.tgz#cc4baecbebe346b050b9cf9db9882d3d00fc4abd" integrity sha512-Uo/Fh7igjoUXA/f90iTATZJesQEArVL1uLA672JefNWTLymdKSZkJKiCciu/Xnd0TS6qvdIOUGuJFSTQnKskXQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

unfortunately this is a fatal error that cannot be handled in the application layer. But we should be able to see the output of from the above logs.
I have done this, see attached.
Same here
Thanks for the logs, in both cases the launching of child process triggers a fatal error from at due to . I would like to understand if this can repro with outside VSCode since we haven't done any modification to the spawn API. I have simplified the Julia language server process spawn call from your logs into the following script, can you run it with node v18.15.0 which can be downloaded from , the steps would be 1) Save the following script to 2) Install v18.15.0 3) From terminal, run and attach the generated output
Apparrently Julia expects 8 arguments. Not sure why though.... if length(Base.ARGS) != 8 error("Invalid number of arguments passed to julia language server.") end
can you help with above error, I would like to create a minimal repro outside VSCode since this is an issue with
It seems we need additional arguments in in the .js file see or here
I two empty arguments in the file However, I have no idea if these arguments are relevant. Then things seem to work Are we expecting the server to shut down at the end? EDIT: the process only shuts down if I hit enter. If I don't press any key it keeps running and the last message is 'Received new data from Julia Symbol Server..." output is:
Thanks for fixing the test case No, I was expecting the error to show up
Can you run our bisect tool in the terminal . In each step install the Julia extension (if not present) and if the extension host terminates with the above error, mark it as bad commit. This would help us narrow down if a change from our side introduced the regression.
Looking at the above, the argument right after is In the test case, I set this argument to empty though
I think it is fine to skip the pipe name, looking at the code it is only responsible for monitory crashes from the language server.


Question: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.8.4: version "25.8.4" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.4.tgz#b50877aac7d96323920437baf309ad86382cb455" integrity sha512-hUYS3RGdaa6E1UWnzeGnsdsBYOggwMMg4WGxNGvAoWtmRrr6J1BsjFW/yRq4WsJHJce2HdzQXtz4OGXV6yUCLg== </del> <ins> electron@25.9.1: version "25.9.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.9.1.tgz#cc4baecbebe346b050b9cf9db9882d3d00fc4abd" integrity sha512-Uo/Fh7igjoUXA/f90iTATZJesQEArVL1uLA672JefNWTLymdKSZkJKiCciu/Xnd0TS6qvdIOUGuJFSTQnKskXQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

Only on the first run I had to open my project () install the julia extension trust the authors of the folder open a .jl file in my project
I will add that, when I run the above code the extension server fails every time except for the first time. The first time I get the ERROR below, but the Language Server seems to restart. Also it actually takes ages (maybe 2 or 3 minutes) for the LanguageServer to start. <img width="1194" alt="image" src=""
Thanks for the bisect results, can you confirm if the extension host terminates with julia extension in . Download links available at
yes. it terminates
Sorry I should have provided link to , can you try it again with this version. I am trying to confirm if Electron 22 update was the trigger.
I don't have time for this right now. Interestingly I get another error now (I am using the most recent VS Code version now 1.81.1) Not sure if this is connected though....
can you also confirm , thanks!
I can reproduce the extension host termination with VSCode 1.77.3 and julia-vscode v1.47.2.
Thanks for confirming, that eliminates the allocator changes we adopted for Electron 22 update. Refs
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Thanks for looking into this, Do you need any more info about the extension?
Might be fixed by
Once the libuve PR us merged, do I need to wait for the next minor julia release?
Thanks for sharing the fix , I will backport the fix into Electron as next step.
Steps for verification: 1) Open extension in latest stable, add the following changes 2) Debug extension, run command 3) Stop the debug session 4) Start debug extension again, run command 5) It should crash the extension host Perform steps 1-4 again in latest insiders with the fix and it should not crash.
Seems to be specific to windows, I cannot repro the crash on a Mac.
Yeah, the seems to be in the Windows kernel.
Yes बुध, 25 अक्तू॰ 2023, 11:15 pm को Sebastian Pfitzner < लिखा:


Question: "config.inputValidation": "Controls when to show commit message input validation.", "config.detectSubmodules": "Controls whether to automatically detect git submodules.", "config.detectSubmodulesLimit": "Controls the limit of git submodules detected.", <ins> "config.alwaysSignOff": "Controls the signoff flag for all commits", </ins> "colors.modified": "Color for modified resources.", "colors.deleted": "Color for deleted resources.", "colors.untracked": "Color for untracked resources.",

For some projects, every commit has to have the signed off by tag. It would be very helpful if there was a workspace level setting that enabled signed off by flag when committing.
Verified !


Question: private _updateTabActionBar(profiles: ITerminalProfile[]): void { const actions = getTerminalActionBarArgs(TerminalLocation.Panel, profiles, this._getDefaultProfileName(), this._terminalProfileService.contributedProfiles, this._terminalService, this._dropdownMenu); <ins> this._registerDisposableActions(actions.dropdownAction, actions.dropdownMenuActions); </ins> this._newDropdown?.update(actions.dropdownAction, actions.dropdownMenuActions); }

I was trying to understand the usage of and the lifecycle of actions created while creating it. I think this originated with the terminal, so looked at the terminal code, but it seems like the problem isn't solved here either. instantiates some Actions which extend Disposable, but they are never tracked or disposed. The ActionViewItems returned from are apparently owned by whatever calls that and get disposed, but not these extra actions that we have to create. So, one solution would be for them to be owned and disposed by although that feels unexpected. But otherwise, there isn't a technically correct way for the code in to know when they should be disposed. Wondering whether I'm missing something or if you have any thoughts.
I spent some time investigating this and the issue is that we use in some places and in others. Only the latter is disposable. This would be a bit involved to rework


Question: const newCellListHeight = Math.max(newBodyHeight - topInserToolbarHeight, 0); if (this._list.getRenderHeight() < newCellListHeight) { // the new dimension is larger than the list viewport, update its additional height first, otherwise the list view will move down a bit (as the `scrollBottom` will move down) <del> this._list.updateOptions({ additionalScrollHeight: this._allowScrollBeyondLastLine() ? Math.max(0, (newCellListHeight - 50)) : topInserToolbarHeight, overrideStyles: this._listStyleOverride }); </del> <ins> this._list.updateOptions({ additionalScrollHeight: this._allowScrollBeyondLastLine() ? Math.max(0, (newCellListHeight - 50)) : topInserToolbarHeight }); </ins> this._list.layout(newCellListHeight, dimension.width); } else { // the new dimension is smaller than the list viewport, if we update the additional height, the `scrollBottom` will move up, which moves the whole list view upwards a bit. So we run a layout first. this._list.layout(newCellListHeight, dimension.width); <del> this._list.updateOptions({ additionalScrollHeight: this._allowScrollBeyondLastLine() ? Math.max(0, (newCellListHeight - 50)) : topInserToolbarHeight, overrideStyles: this._listStyleOverride }); </del> <ins> this._list.updateOptions({ additionalScrollHeight: this._allowScrollBeyondLastLine() ? Math.max(0, (newCellListHeight - 50)) : topInserToolbarHeight }); </ins> } this._overlayContainer.style.visibility = 'visible';

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


Question: if (action instanceof MenuItemAction) { const location = { viewColumn: ACTIVE_GROUP }; const actions = getTerminalActionBarArgs(location, this._terminalProfileService.availableProfiles, this._getDefaultProfileName(), this._terminalProfileService.contributedProfiles, this._terminalService, this._dropdownMenu); <ins> this._registerDisposableActions(actions.dropdownAction, actions.dropdownMenuActions); </ins> const button = this._instantiationService.createInstance(DropdownWithPrimaryActionViewItem, action, actions.dropdownAction, actions.dropdownMenuActions, actions.className, this._contextMenuService, { hoverDelegate: options.hoverDelegate }); return button; }


Question: } public show(top: number, newContent: string | undefined, metadata: NotebookCellMetadata | undefined): void { <del> this.element.style.visibility = 'visible'; </del> <ins> this.element.style.visibility = ''; </ins> this.element.style.top = `${top}px`; if (typeof newContent === 'string' || metadata) { this.updateContentAndRender(newContent ?? this._content.value, metadata ?? this._content.metadata);

Collapse an output, it is not hidden in the webview <img width="596" alt="image" src="https://user-"
maybe ?


Question: "dependencies": { "@vscode/extension-telemetry": "0.5.1", "request-light": "^0.5.8", <del> "vscode-languageclient": "^8.0.1", </del> <ins> "vscode-languageclient": "^8.0.2-next.4", </ins> "vscode-nls": "^5.0.1" }, "devDependencies": {

Version: 1.68.0-insider Commit: Date: 2022-06-02T05:17:01.962Z open the Settings JSON editor add some unnecessary commas no problems reported in the problems view. open the JSON Language Server log. Observe that there are no diagnostic requests. Other requests are sent and completed, so the language server is running.
Maybe unrelated: I was expecting "trailing comma" warnings in (we recently changed the schema to not accept them), but they only started showing after I flushed the schema cache (using the UI command) and reloaded the window (I can't completely rule out that a window reload alone would have helped).
I checked that with the fix the trailing commas are reported


Question: result.edits.push(<languages.IWorkspaceFileEdit>{ oldResource: entry.from, newResource: entry.to, <del> options: entry.options, </del> <ins> options: { ...entry.options, contentsBase64: entry.options?.contents && encodeBase64(VSBuffer.wrap(entry.options.contents)) }, </ins> metadata: entry.metadata });

Add support for setting the contents of files created by workspace edits My proposed would be to add a option to : For , we want to support copying images from desktop into with drag and drop. Right now we have to use the apis to create the image file Using a workspace edit would let us express the entire operation in a single , which will play more nicely with undo/redo
Looks like support for this may already exist internally: However getting a of new file data from the extension host to the main process may be tricky. We can only efficiently serialize a if it is a top level argument to an RPC call or if the entire object is wrapped in a (which has a perf cost). Open to ideas on how to handle this
I do like the and believe the cost is manageable - we don't send edits is large frequencies and of large sizes. I can take a look at this but it honestly is stretch for June - there is some debt in how workspace edits are represented on the wire and I would take this issue as a reason to clean things up
work started here: I didn't bother with or hoisting the data to the top but instead it uses quick and dirty base64 encoding. I'd suggest we go with that and see how it works out over time.


Question: showMethods: true, showFunctions: true, showConstructors: true, <ins> showDeprecated: true, </ins> showFields: true, showVariables: true, showClasses: true,

I'd like a setting to optionally prevent deprecated things from showing up in intellisense suggestions. For example, I'd like a way to prevent from being suggested here, so that I don't use it despite a non-deprecated version being available. ! My linter can catch it, but it'd be even nicer never to see the deprecated option. There are several documentation systems that use the tag: JSDoc: TSDoc: JavaDoc: Yard (for Ruby): Other systems use different, similar tags. I'm not sure if this is an issue for the VSCode core, or for something language-specific.
Sorry if this is a duplicate or is already possible. There are enough issues here and questions/answers on Stack Overflow that it's hard to be confident. This issue is related:
Not showing deprecated suggestions can be implemented by individual language extensions today (not striking out but tracks that). Adding just to see this is something we want better VS Code api support for in some way Otherwise, we can track this as a feature request for js/s
I'd say this is a dupe of and it would be us adding some API flag and then allows users to configure how the suggest UX is handling that flag
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues . See also our guidelines. Happy Coding!
Okay, that makes sense. What does "js/s" mean?
is it possible to add a setting like , so I can disable it to prevent deprecated from showing up in suggestions list?
Hey any update on that?
Verify that the setting exists and that it filters deprecated elements from IntelliSense


Question: }); test('fuzzyScore2 (matching)', function () { <del> const target = 'HeLlo-World'; </del> <ins> const target = 'HelLo-World'; </ins> for (const offset of [0, 3]) { <del> let [score, matches] = _doScore2(offset === 0 ? target : `123${target}`, 'HeLlo-World', offset); </del> <ins> let [score, matches] = _doScore2(offset === 0 ? target : `123${target}`, 'HelLo-World', offset); </ins> assert.ok(score); assert.strictEqual(matches.length, 1);

I'm not certain if this is a bug (in the tests), but while looking at the completion ranking I noticed there are some tests cases for the fuzzy scoring annotated with "direct case match" that don't appear to match exactly - the order of the lowercase/capital is reversed: It's possible this is deliberate (because VS Code handles some swapped characters), but if so I would've thought an exact match would be included also (to ensure it ranks above the entry with the reverse characters) and the comment would be more explicit. There are other tests in the same file with the same mismatch.


Question: setCompositeBarItems(items: ICompositeBarItem[]): void { this.model.setItems(items); <del> this.updateCompositeSwitcher(); </del> <ins> this.updateCompositeSwitcher(true); </ins> } getPinnedComposites(): ICompositeBarItem[] {

have insiders with settings sync enabled add exploration build to the sync select replace local when prompted so that exploration because just like insiders over time insiders UI state gets ruined, e.g the side bar is populated with views I have carefully hidden and rearranged
This is caused due to the dependency between two states and . Values of both states changed together from outside Change event for first state is triggered. Updating to this change can cause view container changes like (registering or deregistering) This triggers internal change events to update pinned viewlets Updating pinned viewlets is updating the stored value for second state Bug is caused at the last step -pinned viewlets state is getting overriden without refreshing its in-memory state.
How would this be verified?
<!-- 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!
Since it cannot be reproduced easily, I would ask to verify this.
the steps are as easy as described in or the description of this issue. use settings sync onboard another machine :bug: view state of the main machine get's broken: views reappear, views are reordered etcpp
Can you please verify this? I believe this depends on some pre-existing state therefore not everyone can reproduce. This state is not trivial to set up. Since you have this state already, it might be easier for you to verify.


Question: //#endregion //#region Task <del> /** * Controls how the task is presented in the UI. */ export interface TaskPresentationOptions { /** * Controls whether the terminal is cleared before executing the task. */ clear?: boolean; } </del> export enum RerunBehavior { reevaluate = 1, useEvaluated = 2,

This clear option can be into the exiting task property and would be called : { "label": "ExampleTask", "type": "shell", "command": "echo hello", "presentation": { "echo": true, "reveal": "always", "focus": false, "panel": "shared", "showReuseMessage": true, "clear": false } } Added to : / Controls how the task is presented in the UI. / export interface TaskPresentationOptions { …. / Controls whether the terminal is cleared before executing the task. / clear?: boolean; }
This doesn't work for me: I run it multiple times and see all the output, the terminal is never cleared.
Turns out that if the only presentation option set is clear, this doesn't work. Thanks for finding!


Question: "textCodeBlock.background": "#F8F8F8", "textLink.activeForeground": "#005FB8", "textLink.foreground": "#005FB8", <del> "textPreformat.foreground": "#3B3B3B", </del> <ins> "textPreformat.foreground": "#A31515", </ins> "textPreformat.background":	"#0000001F", "textSeparator.foreground": "#21262D", "titleBar.activeBackground": "#F8F8F8",

Expected ! Actual !
Regressed in
The markdown preview in the chat is also broken for Dark Modern but is fixed by your change: !
And the markdown preview in the settings editor: !
I looked into this some more and have the following findings block rendering is broken for Dark Modern, Light Modern, Dark HC and Light HC What changed: we a new theme token, , adopted it in and , and updated the values for to look good with a different background color But we didn't adopt token for blocks in Markdown previews, which is why is broken for Markdown preview Some options Adopt for blocks in Markdown preview -- this amounts to a rather drastic styling change for Markdown previews ! Revert Revert the change to and drop the usage of so that Markdown preview, chat, and settings UI are in a reasonable state for all themes, which I attempted in
Also affects the Extensions Details page since it is a Markdown preview !
Verification: for Light/Dark Modern and Light/Dark HC, make sure that blocks are properly rendered in Markdown preview, settings UI and chat


Question: } const { result } = await this.dialogService.prompt<ImportProfileChoice>({ type: Severity.Info, <del> message: localize('profile already exists', "Profile with name '{0}' already exists. Do you want to overwrite it?", profileTemplate.name), </del> <ins> message: localize('profile already exists', "Profile with name '{0}' already exists. Do you want to overwrite it?", profileName), </ins> buttons: [ { label: localize({ key: 'overwrite', comment: ['&& denotes a mnemonic'] }, "&&Overwrite"),

<!-- 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. --<!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.76 Steps to Reproduce: Exported a user profile using the GitHub gist link . The user navigates to the link in their browser, where they enter , and the profile opens in the explore view. At the same time, the profile badge is to the settings icon prior to importing the profile. If the user clicks "Import Profile", they are prompted to overwrite an existing profile. The user has never imported a profile prior to this experience. !
thanks for great repro steps. I can nicely reproduce. Assigning to since it seems like the Profile got applied to before hitting the import button, and hitting the import would double-import.
thanks for fixing can you try with latest Insiders and if it works fine you can add the label. Thanks!
Verified, however the profile badge gets to the Settings icon and to the Profiles list prior to importing the profile, but if you click "Import Profile" it imports as expected. Is this as expected? My assumption was that those would not show up until the Profile is imported. !
Yes. This is to indicate user that the profile is applied in preview mode.


Question: private _removeCellDecoration(decorationId: string) { const options = this._resolvedCellDecorations.get(decorationId); <ins> this._resolvedCellDecorations.delete(decorationId); </ins> if (options) { <ins> for (const existingOptions of this._resolvedCellDecorations.values()) { // don't remove decorations that are applied from other entries if (options.className === existingOptions.className) { options.className = undefined; } if (options.outputClassName === existingOptions.outputClassName) { options.outputClassName = undefined; } if (options.gutterClassName === existingOptions.gutterClassName) { options.gutterClassName = undefined; } if (options.topClassName === existingOptions.topClassName) { options.topClassName = undefined; } } </ins> this._cellDecorationsChanged.fire({ added: [], removed: [options] }); <del> this._resolvedCellDecorations.delete(decorationId); </del> } }

Steps to Reproduce: a notebook with a markdown cell that has multiple headers e.g. the preview for the markdown cell - shift+enter symbols quickpick ctrl+shift+o and arrow down through the symbols list :bug: cell decoration appears for the first item but then is removed for the second


Question: } private _isDisposed = false; <ins> private _isReadonly = false; </ins> constructor( readonly viewType: string,

Type: <bBug</bDelete a notebook file in a git repo Open it from the SCM view It's editable ;( VS Code version: Code - Insiders 1.94.0-insider (Universal) (, 2024-09-11T05:04:03.124Z) OS version: Darwin arm64 23.6.0 Modes: <!-- generated by issue reporter --
Fixed by


Question: } } }); <ins> this.threads.forEach(t => { // Remove all old threads which are no longer part of the update #75980 if (threadIds.indexOf(t.threadId) === -1) { this.threads.delete(t.threadId); } }); </ins> const stoppedDetails = data.stoppedDetails; if (stoppedDetails) {

<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.35.1 (also tried current 1.36.0-insider) OS Version: Ubuntu 18.04 VSCode's view seems to show all threads that ever existed, not just the ones returned by latest request. Repro: and run mock-debug extension from this branch: the folder and start configuration. all threads in the thread list and start stepping line by line. After each step the adapter will reduce the number of active threads by one. requests for invalid thread ids will be failed. By line 5, there will be only one thread remaining, yet VSCode tries to display all 5.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.586 --- <!-- score: 0.462 --- <!-- score: 0.461 --- <!-- score: 0.461 --<!-- potentialduplicatescomment --
make sure that only the threads returned by the last thread request (plus additional threads coming reported via the "thread" event) are shown.
thanks for the nice repo steps. I have changed that we now always respect the request as the absolute truth. So if a thread is not returned as part of the response we will delete it. I have created a PR which tackles this and I will merge this PR in next week since now we are in endgame and I would like to get more insiders coverage so we catch potential extensions which might rely on the current bugy behavior.


Question: }, "autoCloseBefore": ";:.,={}])>` nt$", "wordPattern": { <del> "pattern": "(p{Alphabetic}|p{Number}|p{Nonspacing_Mark}){2,}", </del> <ins> "pattern": "(p{Alphabetic}|p{Number}|p{Nonspacing_Mark}){1,}", </ins> "flags": "u" } }

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- Version: 1.74.2 (user setup) Commit: Date: 2022-12-20T10:29:14.590Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No Steps to Reproduce: a snippet for latex that uses $TMSELECTED_TEXT. The following is an example that wraps selected text in auto-sized brackets: 'lr' over a selected text and hit TAB. The selected text is not included in the output. ! F1 + Insert Snippet, however, produces the desired output. I have only encountered the problem in latex environment, including inline math in markdown files. The issue was raised in and was fixed in 1.73 update via (I think). But came back in 1.74.
The problem is the which requires two characters to be typed... This is what happens overtyping happens, we capture the overtyped text, and "await" the next suggest session to start this doesn't happen because suggest only auto starts at word ends and a single character is no word the next character is typed, erasing the overtyped, captured value suggest starts because the 2nd character makes this a word looping you in here and wonder if you know why such a word definition was chosen and if it can be changed
I don't know why the definition specifies 2 characters.