Question: } private static _getLineDecorations(editor: IActiveCodeEditor, anchor: HoverAnchor): IModelDecoration[] { <del> if (anchor.type !== HoverAnchorType.Range) { </del> <ins> if (anchor.type !== HoverAnchorType.Range && !anchor.supportsMarkerHover) { </ins> return []; }

Hovering inlay hints should show problems "underneath": !
Came here to report the same thing https://user-
This happens because inlay hint have their own hover which are anchored on a . The diagnostics hover explicitly checks for that and . Would be OK to pretend to be a "normal" range hover anchor so that I can get all the hovers together? Or should the diagnostics hover not check for the hover type?
The is used both by inlay hints (via ) and ghost text (directly instantiates it). I think in the case of inlay hints you would want that markers are rendered in the hover, but perhaps ghost text wouldn't want that they appear in the hover, it might want to show only these actions: <img width="598" alt="image" src="https://user-"My suggestion would be to add something to to be able to distinguish the two cases.
Can still repro this
Please update this issue with a real code snippet that allows to reproduce this, please update this issue with what you have tried. Thanks
I just found a reduce function in VS Code sources such as and replace the returned value with the void keyword such as
Something like this only gives a squiggle for the return value, not the arguments or anything with inline hints. To clarify, this will only work for squiggles that spawn across inline hints <img width="699" alt="Screenshot 2023-01-26 at 14 49 07" src="https://user-"
Hmm, maybe it's because it's in a function so the return value becomes incorrect? This in <img width="917" alt="image" src="https://user-"
Thanks for updating
Looks good to me. Version: 1.75.0-insider Commit: !


Question: import { compareIgnoreCase } from 'vs/base/common/strings'; import { IExtensionIdentifier, IGalleryExtension, ILocalExtension, getTargetPlatform } from 'vs/platform/extensionManagement/common/extensionManagement'; <del> import { ExtensionIdentifier, IExtension, TargetPlatform } from 'vs/platform/extensions/common/extensions'; </del> <ins> import { ExtensionIdentifier, IExtension, TargetPlatform, UNDEFINED_PUBLISHER } from 'vs/platform/extensions/common/extensions'; </ins> import { IFileService } from 'vs/platform/files/common/files'; import { isLinux, platform } from 'vs/base/common/platform'; import { URI } from 'vs/base/common/uri';

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When developing an extension, I sometimes mess around with versions, e.g. install an (unpublished) extension with different content using the same version, or going back a version. It can happen then that I can install the extension (via file) successfully, the extension appears, I get the notification to reload VSCode which I accept, and the extension is gone after the reload. It does not load, and it does not appear in the list of installed extensions. There is no warning nor any trace in the extension host output pane. I recently figured out that this appears to be caused by an auto-generated entry in the file, listing the installed version of my extension. There might be a bug here, since it also lists the highest version ever installed. However, this feature request is about the lack of notifications why the extension is not loaded. I would appreciate if you could tell the user, e.g. via a warning during install and maybe during every load, that an extension has been blocked because it's obsolete. Furthermore I suggest listing the extension as installed in the extension pane, as deactivated/obsolete with a warning attached to it.
Can you please provide exact steps to reproduce this behaviour?
I did not mean this as a bug report, but rather as a request to add additional messages telling the user what's going on. However, I've tried to reproduce it and it seems you can get this issue if you do: a for some extension E in version 0.0.1 E in version 0.0.1 from vsix (I'm doing this on a remote machine using the Remote SSH extension). . a for E in version 0.0.2 E in version 0.0.2 that now contains an entry making E in version 0.0.1 obsolete . E in version 0.0.1 . that now contains both an entry making E in version 0.0.1 obsolete as well as version 0.0.2 obsolete. that the extension is not loaded. At this point, you can also install E in version 0.0.2 and it still won't load.
I am not seeing this behaviour.


Question: import { compareIgnoreCase } from 'vs/base/common/strings'; import { IExtensionIdentifier, IGalleryExtension, ILocalExtension, getTargetPlatform } from 'vs/platform/extensionManagement/common/extensionManagement'; <del> import { ExtensionIdentifier, IExtension, TargetPlatform } from 'vs/platform/extensions/common/extensions'; </del> <ins> import { ExtensionIdentifier, IExtension, TargetPlatform, UNDEFINED_PUBLISHER } from 'vs/platform/extensions/common/extensions'; </ins> import { IFileService } from 'vs/platform/files/common/files'; import { isLinux, platform } from 'vs/base/common/platform'; import { URI } from 'vs/base/common/uri';

When I install 0.0.1, .obsolete file now contains 0.0.2 version only.
Sorry for taking so long to answer. I've now taken a fresh VM (Ubuntu 22.04) and a new extension (, just modified the so it would package) and could reproduce it. No "Remote - SSH" involved either. The steps: Generate two versions of an extension, 0.0.1 and 0.0.2 Install VS Code. At this point, does not exist yet. Install 0.0.1 and reload. Install 0.0.2 and reload. This creates the file with a single entry . Install 0.0.1 and reload. The file now contains . The extension is not loaded and does not appear in the list of installed extensions. Even if you "only" end up with an entry for version 0.0.2, this would still probably cause an issue if you try to re-install 0.0.2 since there are no diagnostics emitted - neither during installation nor during startup.
Ok there is a bug at the last step - Installing 0.0.1 shall not add 0.0.1 to the file. This bug happens only when the has no set. Can you please set the property in the and retry?
To verify: Formulate an extension without property in Generate a VSIX 0.0.1 with version Generate a VSIX 0.0.2 with version Install VSIX 0.0.1 and make sure 0.0.1 version is installed Install VSIX 0.0.2 and make sure 0.0.2 version is installed Again Install VSIX 0.0.1 and make sure 0.0.1 version is installed


Question: import { localize } from 'vs/nls'; import { URI } from 'vs/base/common/uri'; import { IResourceEditorInput, IEditorOptions } from 'vs/platform/editor/common/editor'; <del> import { IEditorPane, IEditorCloseEvent, EditorResourceAccessor, IEditorIdentifier, GroupIdentifier, EditorsOrder, SideBySideEditor, IUntypedEditorInput, isResourceEditorInput, isEditorInput, isSideBySideEditorInput, EditorCloseContext, IEditorPaneSelection, EditorPaneSelectionCompareResult, EditorPaneSelectionChangeReason, isEditorPaneWithSelection, IEditorPaneSelectionChangeEvent, IEditorPaneWithSelection, IEditorWillMoveEvent } from 'vs/workbench/common/editor'; </del> <ins> import { IEditorPane, IEditorCloseEvent, EditorResourceAccessor, IEditorIdentifier, GroupIdentifier, EditorsOrder, SideBySideEditor, IUntypedEditorInput, isResourceEditorInput, isEditorInput, isSideBySideEditorInput, EditorCloseContext, IEditorPaneSelection, EditorPaneSelectionCompareResult, EditorPaneSelectionChangeReason, isEditorPaneWithSelection, IEditorPaneSelectionChangeEvent, IEditorPaneWithSelection, IEditorWillMoveEvent, GroupModelChangeKind } from 'vs/workbench/common/editor'; </ins> import { EditorInput } from 'vs/workbench/common/editor/editorInput'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; import { GoFilter, GoScope, IHistoryService } from 'vs/workbench/services/history/common/history';

Steps to Reproduce: recently opened ("Clear Editor History") quick open and search for a file (such as a TS file) to see symbols (notice how the file opens in the background) to a symbol = when you open quick open again, the file is not part of the recently opened section //cc this is a regression from the transient work we did


Question: this._terminalTabs = []; this._configHelper = this._instantiationService.createInstance(TerminalConfigHelper); ipc.on('vscode:openFiles', (_event: any, request: IOpenFileRequest) => { // if the request to open files is coming in from the integrated terminal (identified though // the termProgram variable) and we are instructed to wait for editors close, wait for the

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: import { NotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookProvider'; import { NotebookPerfMarks } from 'vs/workbench/contrib/notebook/common/notebookPerformance'; import { IFilesConfigurationService } from 'vs/workbench/services/filesConfiguration/common/filesConfigurationService'; <ins> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; import { localize } from 'vs/nls'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; </ins> export interface NotebookEditorInputOptions { startDirty?: boolean;

Testing a new notebook and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , :bug: The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
can you maybe check from the notebook side?
Luna paint behaves similarly with one extra step: a new image and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , (different) and the switch profile operation is blocked switch profiles again The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
Somehow today I cannot reproduce an issue with insiders: ! Please give me more detailed steps and see if you still find this.
still seeing it. Did you try making edits after switching? that's when the dirty indicator doesn't show up anymore. ! I saved as a different filename in the gif, but keeping the untitled filename still doesn't show a dirty indicator, nor does it auto-save.
This seems to me like something notebooks need to handle better: if you enter an extension host that does not have the notebook extension and you make edits, the editor should probably not allow that. I.e. the editor should maybe turn readonly once the extension is disabled or not present.
- the notebook extension is built-in so it's still available in an empty profile. The repro steps can even start with an empty profile -and make an edit to the first cell profile to default and save as 1.ipynb when prompted an edit in the notebook :bug: file is not dirty
oh nice, sounds like an issue related to EH restart then, will update the title With your working copy knowledge you might be even able to figure this out ;)
It looks like the issue in the notebook scenario is that it's calling save directly on the workingCopy in the : In the untitled case, that will delegate to saveAs, which will dispose the untitled workingcopy without opening a new editor with the resulting . The editor is left open with its underlying WorkingCopy disposed. For non-built-in custom editors though, it seems like we should just close them if we don't know if they will be supported in the new profile.


Question: import { NotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookProvider'; import { NotebookPerfMarks } from 'vs/workbench/contrib/notebook/common/notebookPerformance'; import { IFilesConfigurationService } from 'vs/workbench/services/filesConfiguration/common/filesConfigurationService'; <ins> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; import { localize } from 'vs/nls'; import { IEditorService } from 'vs/workbench/services/editor/common/editorService'; </ins> export interface NotebookEditorInputOptions { startDirty?: boolean;

I don't see how we can expect a custom editor to support a scenario where its source extension isn't installed - is that even possible? I went over the issue with and concluded that we can defer to next release since the previous stable version also didn't handle this scenario well.
fyi I just created which is a similar issue for custom editors. Here for notebooks I suggest the following: if the EH restarts and still has the notebook extension for the opened notebooks, reconnect to the EH and allow to further make edits on the editor (I actually thought this was already implemented based on the work did) if the EH restarts and there is no more extension for the notebook editor, turn the notebook readonly and inform the user somehow Does that make sense?
The previous change just doesn't account for untitled notebooks, but I think I can fix that. That makes sense, although I'm surprised that we would require all custom editors to handle this (asked about it in the other issue)


Question: } this._textEditor = editor; <ins> if (this._isReadonly) { editor.updateOptions({ readOnly: this._isReadonly }); } </ins> if (this._editorViewStates) { this._restoreViewState(this._editorViewStates); } else {

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: 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.1: version "25.8.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.1.tgz#092fab5a833db4d9240d4d6f36218cf7ca954f86" integrity sha512-GtcP1nMrROZfFg0+mhyj1hamrHvukfF6of2B/pcWxmWkd5FVY1NJib0tlhiorFZRzQN5Z+APLPr7aMolt7i2AQ== </del> <ins> electron@25.8.2: version "25.8.2" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.2.tgz#5e8ea742b68a7d1427bf78902ec40a5b7231a58b" integrity sha512-AM1ra6b16EQuO1bJtiA8ZiWqqFLLgVfxD56ykiy+EA5C63Hkx8OmIbe+5JAsLiTwRVvBZ4oCAj6wa2qT+iq8ww== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

<!-- 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. --Something has changed in the latest Insiders so our CI started to fail with errors (any branch but here is an ): Do you have any idea what might cause it so we can make changes on our side? Might it be something with your dependencies?
Runtime has no changes with insiders, this seems like a regression from the recent http proxy changes based on in upstream. Passing onto From a quick look the extension relies on package which makes network connection. it would be great if you can reduce the test case to a minimal extension sample for us to debug this issue further. Thanks!
Unfortunately, we haven't been able to isolate the issue for a minimal extension sample so far. To reproduce the problem, you can follow these steps: the and install the extension. the following commands in the terminal: When running all tests, you may observe multiple failures with the . However, when running the failed tests separately, they randomly may or may not fail again, which makes it hard to identify the cause of the issue. It is possible that your proxy patches might be the right place to look for further investigation.
Maybe a related discussion:
Found it. The place in our code that fails with the latest Insiders is . I created a so you can try it, but here is the code snippet for a quick look:
Thanks for putting together this test! My investigation so far: is called with resulting in the reported error when it calls here: The check at would prevent from being called when , but that is only with in 19.0.0.


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.1: version "25.8.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.1.tgz#092fab5a833db4d9240d4d6f36218cf7ca954f86" integrity sha512-GtcP1nMrROZfFg0+mhyj1hamrHvukfF6of2B/pcWxmWkd5FVY1NJib0tlhiorFZRzQN5Z+APLPr7aMolt7i2AQ== </del> <ins> electron@25.8.2: version "25.8.2" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.2.tgz#5e8ea742b68a7d1427bf78902ec40a5b7231a58b" integrity sha512-AM1ra6b16EQuO1bJtiA8ZiWqqFLLgVfxD56ykiy+EA5C63Hkx8OmIbe+5JAsLiTwRVvBZ4oCAj6wa2qT+iq8ww== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

Still need to check older versions to see if that check was backported and see if there is a way to test this assessment.
is available in 18.8.0 and 16.18.0, our exploration builds based on Node v18 has this change, you can use the builds from to verify the assessment.
The test does not reproduce the issue in the exploration build. Still trying to understand what is happening (please ignore the above code pointers) by looking at the code at the tag. I see the failing call to being triggered in : What I don't quite understand is that the callstack to with comes from : But at that line is supposed to call not as it appear in the callstack: Could you point me at the source that went into Electron? I believe that is not the exact same as that at
Electron pulls source from when building, what you are looking at is the correct one. I think the async stack is missing a trampoline calll, but you are seeing a write after shutdown stack same as
Thanks This looks like an upstream issue to me, should not be called when is already . I don't see the change in 18.15.0 (the version the exploration build is using) yet that might have fixed it.
We have reverted to the previous way of loading certificates as we are getting close to a release ().
We're seeing this again in our macos and Windows CI jobs for VSCode "Insiders" (not current VSCode stable version 1.82.2). Was node or electron updated in the last 2 days on VSCode Insiders?
There is fix in upstream for the above scenario, I will backport it to relevant release lines.
Could you confirm that todays Insiders build fixes the problem? Thanks!
Confirmed, thanks!


Question: this.repositoryDisposables.clear(); } } <ins> export class SCMActiveResourceContextKeyController implements IWorkbenchContribution { private contextKey: IContextKey<boolean>; private disposables = new DisposableStore(); private repositoryDisposables = new Set<IDisposable>(); constructor( @IContextKeyService readonly contextKeyService: IContextKeyService, @IEditorService private readonly editorService: IEditorService, @ISCMService private readonly scmService: ISCMService, @IUriIdentityService private readonly uriIdentityService: IUriIdentityService ) { this.contextKey = contextKeyService.createKey('scmActiveResourceHasChanges', false); this.scmService.onDidAddRepository(this.onDidAddRepository, this, this.disposables); for (const repository of this.scmService.repositories) { this.onDidAddRepository(repository); } editorService.onDidActiveEditorChange(this.updateContextKey, this, this.disposables); } private onDidAddRepository(repository: ISCMRepository): void { const onDidChange = Event.any(repository.provider.onDidChange, repository.provider.onDidChangeResources); const changeDisposable = onDidChange(() => this.updateContextKey()); const onDidRemove = Event.filter(this.scmService.onDidRemoveRepository, e => e === repository); const removeDisposable = onDidRemove(() => { disposable.dispose(); this.repositoryDisposables.delete(disposable); this.updateContextKey(); }); const disposable = combinedDisposable(changeDisposable, removeDisposable); this.repositoryDisposables.add(disposable); } private updateContextKey(): void { const activeResource = EditorResourceAccessor.getOriginalUri(this.editorService.activeEditor); if (activeResource && activeResource.scheme === Schemas.file) { for (const repository of this.scmService.repositories) { for (const resourceGroup of repository.provider.groups.elements) { if (resourceGroup.elements.find(scmResource => { return this.uriIdentityService.extUri.isEqual(activeResource, scmResource.sourceUri); })) { this.contextKey.set(true); return; } } } } this.contextKey.set(false); } dispose(): void { this.disposables = dispose(this.disposables); dispose(this.repositoryDisposables.values()); this.repositoryDisposables.clear(); } } </ins>

<!-- Do you have a question? Please ask it on --VSCode Version: 1.12.1 OS Version: OS X EI Capitan 10.11.3 Steps to Reproduce: some project from GitHub. a file A.cs which has no fresh changes at all. on the editor of A.cs, and notice the button of on the top right corner above the editor doesn't display as disbled! Clicking it has no effect of course, but it should display as disable in this case just like what in the old versions.
Can't fix without , closing for now.
since it connot be fixed without , should this be kept open and linked to then?
Sure.
To keep the number of issues in our inbox on a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: We look at the number of votes the issue has received and the number of duplicates issues filed. Thanks for your understanding. Happy coding!
Hoping to re-open this because I got this as a feedback item from a few CS educators. They notice their students clicking it accidentally and being confused when there is no apparent action.
I think this has regressed, I now miss this button when a file is staged.
Fixed regression with
There is another regression (), so I will be reverting this fix for this, and will refactor it.


Question: <del> db3e9eb9f47f465bb63d15de486ea1d9274233b24bbe451038bfbaf48f9b0e39 *electron-v25.8.4-darwin-arm64-symbols.zip 5d83e2094a26bfe22e4c80e660ab088ec94ae3cc2d518c6efcac338f48cc0266 *electron-v25.8.4-darwin-arm64.zip 6fdd506328c65a9d8205425a463098210743c9ef79a546738b91a91d56100447 *electron-v25.8.4-darwin-x64-symbols.zip d4015cd251e58ef074d1f7f3e99bfbbe4cd6b690981f376fc642b2de955e8750 *electron-v25.8.4-darwin-x64.zip b46da627829a84cdf84b5570f95e044d38660fb0e58712757e834ff13b43c72d *electron-v25.8.4-linux-arm64-symbols.zip fbb6e06417b1741b94d59a6de5dcf3262bfb3fc98cffbcad475296c42d1cbe94 *electron-v25.8.4-linux-arm64.zip 2569c260b4bb90894c5e63e175d3ee9665525e928d7c70158c6a9d98cb82f6a9 *electron-v25.8.4-linux-armv7l-symbols.zip 6301e6fde3e7c8149a5eca84c3817ba9ad3ffcb72e79318a355f025d7d3f8408 *electron-v25.8.4-linux-armv7l.zip 63580a081a4481eec2773606e9cd50c3468758741f11a14d6c47ab716c064896 *electron-v25.8.4-linux-x64-symbols.zip 0cbbcaf90f3dc79dedec97d073ffe954530316523479c31b11781a141f8a87f6 *electron-v25.8.4-linux-x64.zip 8860faaaabcc15a531733dd164c858a1cc1bffefdbba7ec54f7687db796f93f3 *electron-v25.8.4-win32-arm64-pdb.zip e909628b4c984b3472c58b3897214e59f55ce69bee99229cdf1451a281865176 *electron-v25.8.4-win32-arm64-symbols.zip 1355293a73da3e5d3f06a6c95c81a5124c4f26be2ec1035ccfcfeccd4c766f5d *electron-v25.8.4-win32-arm64.zip fef9e5ec4d146e6b310137140cee2a1172964e7584540088b1bc7fd1df15f1ff *electron-v25.8.4-win32-x64-pdb.zip 1227ec90ae2fb30e01d4c6814af1adae983b78ea832dea0520caaa8a05ac0390 *electron-v25.8.4-win32-x64-symbols.zip 0bbe72439cab1e72dee5fb850fdb1b17ea16fef61aa3dae93c562687737084f1 *electron-v25.8.4-win32-x64.zip 41e5b5392efcb1b47826f20e2f867dac6026dd435b92f50acb58bfae99b96e08 *ffmpeg-v25.8.4-darwin-arm64.zip bad5ed7f10eef768c95a134cbd6754e9c347eb8bfae871e65975afb96cc49b86 *ffmpeg-v25.8.4-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.8.4-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.8.4-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.8.4-linux-x64.zip 84ec373f124f628ce7d8964e000e79cd1448acec05b92417207baecf9b0f039a *ffmpeg-v25.8.4-win32-arm64.zip 7506346ff7a98377eca26464370a7c5a8c44d010d5c46a8357fa107980582fac *ffmpeg-v25.8.4-win32-x64.zip </del> <ins> 4a472f48b54e92855ad77606f11a620523f3abe4ee1bc2997a300ae72da4b2f5 *electron-v25.9.1-darwin-arm64-symbols.zip 247daa6c9faf711162dc623832fcb189d3c1ef6a15884084cb45c8da3a037b6b *electron-v25.9.1-darwin-arm64.zip 7d8ec9d3272dbe356deb09b47ccfda30c421b32f7e906f1186ea26f894b22dc1 *electron-v25.9.1-darwin-x64-symbols.zip 35fc99808ea026a21afeca537c218ace398d299fba7ab73d2630be513f1e1617 *electron-v25.9.1-darwin-x64.zip bfcd6ac66f067cfec08b6d18ed80b519e6d70a96d9b1d31dc2cfcf86f4a9af96 *electron-v25.9.1-linux-arm64-symbols.zip 1c8aa3f13ade23858664b687ad334634ccd698ec7d627554d16cbb596ffa7a0f *electron-v25.9.1-linux-arm64.zip dcfb4a1d6b2ceffa7a8d9a60b9de027d006753eae1278f07de907c474e71c270 *electron-v25.9.1-linux-armv7l-symbols.zip f4320f1888354e17595fb6901c03c383f45325bfba5e6e1b91b4200ff696049f *electron-v25.9.1-linux-armv7l.zip 772dd276d328549e0111b93b43d395de51ff46eba550be48c649c386997125a8 *electron-v25.9.1-linux-x64-symbols.zip 35529c411275791abf9aa46f0a2e216b0affa542757583afb438a76047f6b90c *electron-v25.9.1-linux-x64.zip 5b0b4595691da19258ce0b2c09f58ba969987d24ae8160661a715eaadf42c16b *electron-v25.9.1-win32-arm64-pdb.zip 1e67a35b41927962765a8d8cb01ce73e8c28db6453323f2661e63afd8fdf49e8 *electron-v25.9.1-win32-arm64-symbols.zip a378f5fc44e872f05d037c3ca7f03802ed3a9b2611f59741ce933f500557af7c *electron-v25.9.1-win32-arm64.zip b50f8675b12eda5d0717f83179e40b411ba3254f81bd7142821745c00b566560 *electron-v25.9.1-win32-x64-pdb.zip 8ddaa416e51bac1e93c63d1223bec37b6dd78b00c860e5b91912da09af7ff7b5 *electron-v25.9.1-win32-x64-symbols.zip f6762a98193baa9877f443c9414b1f825f99b7cf1094be579d5202b72442b5be *electron-v25.9.1-win32-x64.zip a0c2566efff0a796f751cfc63cddd52d6c4153b35b6ad582bbdd15a2c4317bc9 *ffmpeg-v25.9.1-darwin-arm64.zip b8cd9d93cdf8ebbd3caf68581b6504529b8bf2dea984b6e5f637343ea9d61946 *ffmpeg-v25.9.1-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.9.1-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.9.1-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.9.1-linux-x64.zip 2467f6567356340e8d9872753a3df486555334b7c868c0d12991f80f2353ce1f *ffmpeg-v25.9.1-win32-arm64.zip fe4676a13bf9d6f87353f3496e0fb37cd3db151fcea13dad7610a2835d238062 *ffmpeg-v25.9.1-win32-x64.zip </ins>

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: <del> db3e9eb9f47f465bb63d15de486ea1d9274233b24bbe451038bfbaf48f9b0e39 *electron-v25.8.4-darwin-arm64-symbols.zip 5d83e2094a26bfe22e4c80e660ab088ec94ae3cc2d518c6efcac338f48cc0266 *electron-v25.8.4-darwin-arm64.zip 6fdd506328c65a9d8205425a463098210743c9ef79a546738b91a91d56100447 *electron-v25.8.4-darwin-x64-symbols.zip d4015cd251e58ef074d1f7f3e99bfbbe4cd6b690981f376fc642b2de955e8750 *electron-v25.8.4-darwin-x64.zip b46da627829a84cdf84b5570f95e044d38660fb0e58712757e834ff13b43c72d *electron-v25.8.4-linux-arm64-symbols.zip fbb6e06417b1741b94d59a6de5dcf3262bfb3fc98cffbcad475296c42d1cbe94 *electron-v25.8.4-linux-arm64.zip 2569c260b4bb90894c5e63e175d3ee9665525e928d7c70158c6a9d98cb82f6a9 *electron-v25.8.4-linux-armv7l-symbols.zip 6301e6fde3e7c8149a5eca84c3817ba9ad3ffcb72e79318a355f025d7d3f8408 *electron-v25.8.4-linux-armv7l.zip 63580a081a4481eec2773606e9cd50c3468758741f11a14d6c47ab716c064896 *electron-v25.8.4-linux-x64-symbols.zip 0cbbcaf90f3dc79dedec97d073ffe954530316523479c31b11781a141f8a87f6 *electron-v25.8.4-linux-x64.zip 8860faaaabcc15a531733dd164c858a1cc1bffefdbba7ec54f7687db796f93f3 *electron-v25.8.4-win32-arm64-pdb.zip e909628b4c984b3472c58b3897214e59f55ce69bee99229cdf1451a281865176 *electron-v25.8.4-win32-arm64-symbols.zip 1355293a73da3e5d3f06a6c95c81a5124c4f26be2ec1035ccfcfeccd4c766f5d *electron-v25.8.4-win32-arm64.zip fef9e5ec4d146e6b310137140cee2a1172964e7584540088b1bc7fd1df15f1ff *electron-v25.8.4-win32-x64-pdb.zip 1227ec90ae2fb30e01d4c6814af1adae983b78ea832dea0520caaa8a05ac0390 *electron-v25.8.4-win32-x64-symbols.zip 0bbe72439cab1e72dee5fb850fdb1b17ea16fef61aa3dae93c562687737084f1 *electron-v25.8.4-win32-x64.zip 41e5b5392efcb1b47826f20e2f867dac6026dd435b92f50acb58bfae99b96e08 *ffmpeg-v25.8.4-darwin-arm64.zip bad5ed7f10eef768c95a134cbd6754e9c347eb8bfae871e65975afb96cc49b86 *ffmpeg-v25.8.4-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.8.4-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.8.4-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.8.4-linux-x64.zip 84ec373f124f628ce7d8964e000e79cd1448acec05b92417207baecf9b0f039a *ffmpeg-v25.8.4-win32-arm64.zip 7506346ff7a98377eca26464370a7c5a8c44d010d5c46a8357fa107980582fac *ffmpeg-v25.8.4-win32-x64.zip </del> <ins> 4a472f48b54e92855ad77606f11a620523f3abe4ee1bc2997a300ae72da4b2f5 *electron-v25.9.1-darwin-arm64-symbols.zip 247daa6c9faf711162dc623832fcb189d3c1ef6a15884084cb45c8da3a037b6b *electron-v25.9.1-darwin-arm64.zip 7d8ec9d3272dbe356deb09b47ccfda30c421b32f7e906f1186ea26f894b22dc1 *electron-v25.9.1-darwin-x64-symbols.zip 35fc99808ea026a21afeca537c218ace398d299fba7ab73d2630be513f1e1617 *electron-v25.9.1-darwin-x64.zip bfcd6ac66f067cfec08b6d18ed80b519e6d70a96d9b1d31dc2cfcf86f4a9af96 *electron-v25.9.1-linux-arm64-symbols.zip 1c8aa3f13ade23858664b687ad334634ccd698ec7d627554d16cbb596ffa7a0f *electron-v25.9.1-linux-arm64.zip dcfb4a1d6b2ceffa7a8d9a60b9de027d006753eae1278f07de907c474e71c270 *electron-v25.9.1-linux-armv7l-symbols.zip f4320f1888354e17595fb6901c03c383f45325bfba5e6e1b91b4200ff696049f *electron-v25.9.1-linux-armv7l.zip 772dd276d328549e0111b93b43d395de51ff46eba550be48c649c386997125a8 *electron-v25.9.1-linux-x64-symbols.zip 35529c411275791abf9aa46f0a2e216b0affa542757583afb438a76047f6b90c *electron-v25.9.1-linux-x64.zip 5b0b4595691da19258ce0b2c09f58ba969987d24ae8160661a715eaadf42c16b *electron-v25.9.1-win32-arm64-pdb.zip 1e67a35b41927962765a8d8cb01ce73e8c28db6453323f2661e63afd8fdf49e8 *electron-v25.9.1-win32-arm64-symbols.zip a378f5fc44e872f05d037c3ca7f03802ed3a9b2611f59741ce933f500557af7c *electron-v25.9.1-win32-arm64.zip b50f8675b12eda5d0717f83179e40b411ba3254f81bd7142821745c00b566560 *electron-v25.9.1-win32-x64-pdb.zip 8ddaa416e51bac1e93c63d1223bec37b6dd78b00c860e5b91912da09af7ff7b5 *electron-v25.9.1-win32-x64-symbols.zip f6762a98193baa9877f443c9414b1f825f99b7cf1094be579d5202b72442b5be *electron-v25.9.1-win32-x64.zip a0c2566efff0a796f751cfc63cddd52d6c4153b35b6ad582bbdd15a2c4317bc9 *ffmpeg-v25.9.1-darwin-arm64.zip b8cd9d93cdf8ebbd3caf68581b6504529b8bf2dea984b6e5f637343ea9d61946 *ffmpeg-v25.9.1-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.9.1-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.9.1-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.9.1-linux-x64.zip 2467f6567356340e8d9872753a3df486555334b7c868c0d12991f80f2353ce1f *ffmpeg-v25.9.1-win32-arm64.zip fe4676a13bf9d6f87353f3496e0fb37cd3db151fcea13dad7610a2835d238062 *ffmpeg-v25.9.1-win32-x64.zip </ins>

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: <del> db3e9eb9f47f465bb63d15de486ea1d9274233b24bbe451038bfbaf48f9b0e39 *electron-v25.8.4-darwin-arm64-symbols.zip 5d83e2094a26bfe22e4c80e660ab088ec94ae3cc2d518c6efcac338f48cc0266 *electron-v25.8.4-darwin-arm64.zip 6fdd506328c65a9d8205425a463098210743c9ef79a546738b91a91d56100447 *electron-v25.8.4-darwin-x64-symbols.zip d4015cd251e58ef074d1f7f3e99bfbbe4cd6b690981f376fc642b2de955e8750 *electron-v25.8.4-darwin-x64.zip b46da627829a84cdf84b5570f95e044d38660fb0e58712757e834ff13b43c72d *electron-v25.8.4-linux-arm64-symbols.zip fbb6e06417b1741b94d59a6de5dcf3262bfb3fc98cffbcad475296c42d1cbe94 *electron-v25.8.4-linux-arm64.zip 2569c260b4bb90894c5e63e175d3ee9665525e928d7c70158c6a9d98cb82f6a9 *electron-v25.8.4-linux-armv7l-symbols.zip 6301e6fde3e7c8149a5eca84c3817ba9ad3ffcb72e79318a355f025d7d3f8408 *electron-v25.8.4-linux-armv7l.zip 63580a081a4481eec2773606e9cd50c3468758741f11a14d6c47ab716c064896 *electron-v25.8.4-linux-x64-symbols.zip 0cbbcaf90f3dc79dedec97d073ffe954530316523479c31b11781a141f8a87f6 *electron-v25.8.4-linux-x64.zip 8860faaaabcc15a531733dd164c858a1cc1bffefdbba7ec54f7687db796f93f3 *electron-v25.8.4-win32-arm64-pdb.zip e909628b4c984b3472c58b3897214e59f55ce69bee99229cdf1451a281865176 *electron-v25.8.4-win32-arm64-symbols.zip 1355293a73da3e5d3f06a6c95c81a5124c4f26be2ec1035ccfcfeccd4c766f5d *electron-v25.8.4-win32-arm64.zip fef9e5ec4d146e6b310137140cee2a1172964e7584540088b1bc7fd1df15f1ff *electron-v25.8.4-win32-x64-pdb.zip 1227ec90ae2fb30e01d4c6814af1adae983b78ea832dea0520caaa8a05ac0390 *electron-v25.8.4-win32-x64-symbols.zip 0bbe72439cab1e72dee5fb850fdb1b17ea16fef61aa3dae93c562687737084f1 *electron-v25.8.4-win32-x64.zip 41e5b5392efcb1b47826f20e2f867dac6026dd435b92f50acb58bfae99b96e08 *ffmpeg-v25.8.4-darwin-arm64.zip bad5ed7f10eef768c95a134cbd6754e9c347eb8bfae871e65975afb96cc49b86 *ffmpeg-v25.8.4-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.8.4-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.8.4-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.8.4-linux-x64.zip 84ec373f124f628ce7d8964e000e79cd1448acec05b92417207baecf9b0f039a *ffmpeg-v25.8.4-win32-arm64.zip 7506346ff7a98377eca26464370a7c5a8c44d010d5c46a8357fa107980582fac *ffmpeg-v25.8.4-win32-x64.zip </del> <ins> 4a472f48b54e92855ad77606f11a620523f3abe4ee1bc2997a300ae72da4b2f5 *electron-v25.9.1-darwin-arm64-symbols.zip 247daa6c9faf711162dc623832fcb189d3c1ef6a15884084cb45c8da3a037b6b *electron-v25.9.1-darwin-arm64.zip 7d8ec9d3272dbe356deb09b47ccfda30c421b32f7e906f1186ea26f894b22dc1 *electron-v25.9.1-darwin-x64-symbols.zip 35fc99808ea026a21afeca537c218ace398d299fba7ab73d2630be513f1e1617 *electron-v25.9.1-darwin-x64.zip bfcd6ac66f067cfec08b6d18ed80b519e6d70a96d9b1d31dc2cfcf86f4a9af96 *electron-v25.9.1-linux-arm64-symbols.zip 1c8aa3f13ade23858664b687ad334634ccd698ec7d627554d16cbb596ffa7a0f *electron-v25.9.1-linux-arm64.zip dcfb4a1d6b2ceffa7a8d9a60b9de027d006753eae1278f07de907c474e71c270 *electron-v25.9.1-linux-armv7l-symbols.zip f4320f1888354e17595fb6901c03c383f45325bfba5e6e1b91b4200ff696049f *electron-v25.9.1-linux-armv7l.zip 772dd276d328549e0111b93b43d395de51ff46eba550be48c649c386997125a8 *electron-v25.9.1-linux-x64-symbols.zip 35529c411275791abf9aa46f0a2e216b0affa542757583afb438a76047f6b90c *electron-v25.9.1-linux-x64.zip 5b0b4595691da19258ce0b2c09f58ba969987d24ae8160661a715eaadf42c16b *electron-v25.9.1-win32-arm64-pdb.zip 1e67a35b41927962765a8d8cb01ce73e8c28db6453323f2661e63afd8fdf49e8 *electron-v25.9.1-win32-arm64-symbols.zip a378f5fc44e872f05d037c3ca7f03802ed3a9b2611f59741ce933f500557af7c *electron-v25.9.1-win32-arm64.zip b50f8675b12eda5d0717f83179e40b411ba3254f81bd7142821745c00b566560 *electron-v25.9.1-win32-x64-pdb.zip 8ddaa416e51bac1e93c63d1223bec37b6dd78b00c860e5b91912da09af7ff7b5 *electron-v25.9.1-win32-x64-symbols.zip f6762a98193baa9877f443c9414b1f825f99b7cf1094be579d5202b72442b5be *electron-v25.9.1-win32-x64.zip a0c2566efff0a796f751cfc63cddd52d6c4153b35b6ad582bbdd15a2c4317bc9 *ffmpeg-v25.9.1-darwin-arm64.zip b8cd9d93cdf8ebbd3caf68581b6504529b8bf2dea984b6e5f637343ea9d61946 *ffmpeg-v25.9.1-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.9.1-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.9.1-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.9.1-linux-x64.zip 2467f6567356340e8d9872753a3df486555334b7c868c0d12991f80f2353ce1f *ffmpeg-v25.9.1-win32-arm64.zip fe4676a13bf9d6f87353f3496e0fb37cd3db151fcea13dad7610a2835d238062 *ffmpeg-v25.9.1-win32-x64.zip </ins>

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: <del> db3e9eb9f47f465bb63d15de486ea1d9274233b24bbe451038bfbaf48f9b0e39 *electron-v25.8.4-darwin-arm64-symbols.zip 5d83e2094a26bfe22e4c80e660ab088ec94ae3cc2d518c6efcac338f48cc0266 *electron-v25.8.4-darwin-arm64.zip 6fdd506328c65a9d8205425a463098210743c9ef79a546738b91a91d56100447 *electron-v25.8.4-darwin-x64-symbols.zip d4015cd251e58ef074d1f7f3e99bfbbe4cd6b690981f376fc642b2de955e8750 *electron-v25.8.4-darwin-x64.zip b46da627829a84cdf84b5570f95e044d38660fb0e58712757e834ff13b43c72d *electron-v25.8.4-linux-arm64-symbols.zip fbb6e06417b1741b94d59a6de5dcf3262bfb3fc98cffbcad475296c42d1cbe94 *electron-v25.8.4-linux-arm64.zip 2569c260b4bb90894c5e63e175d3ee9665525e928d7c70158c6a9d98cb82f6a9 *electron-v25.8.4-linux-armv7l-symbols.zip 6301e6fde3e7c8149a5eca84c3817ba9ad3ffcb72e79318a355f025d7d3f8408 *electron-v25.8.4-linux-armv7l.zip 63580a081a4481eec2773606e9cd50c3468758741f11a14d6c47ab716c064896 *electron-v25.8.4-linux-x64-symbols.zip 0cbbcaf90f3dc79dedec97d073ffe954530316523479c31b11781a141f8a87f6 *electron-v25.8.4-linux-x64.zip 8860faaaabcc15a531733dd164c858a1cc1bffefdbba7ec54f7687db796f93f3 *electron-v25.8.4-win32-arm64-pdb.zip e909628b4c984b3472c58b3897214e59f55ce69bee99229cdf1451a281865176 *electron-v25.8.4-win32-arm64-symbols.zip 1355293a73da3e5d3f06a6c95c81a5124c4f26be2ec1035ccfcfeccd4c766f5d *electron-v25.8.4-win32-arm64.zip fef9e5ec4d146e6b310137140cee2a1172964e7584540088b1bc7fd1df15f1ff *electron-v25.8.4-win32-x64-pdb.zip 1227ec90ae2fb30e01d4c6814af1adae983b78ea832dea0520caaa8a05ac0390 *electron-v25.8.4-win32-x64-symbols.zip 0bbe72439cab1e72dee5fb850fdb1b17ea16fef61aa3dae93c562687737084f1 *electron-v25.8.4-win32-x64.zip 41e5b5392efcb1b47826f20e2f867dac6026dd435b92f50acb58bfae99b96e08 *ffmpeg-v25.8.4-darwin-arm64.zip bad5ed7f10eef768c95a134cbd6754e9c347eb8bfae871e65975afb96cc49b86 *ffmpeg-v25.8.4-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.8.4-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.8.4-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.8.4-linux-x64.zip 84ec373f124f628ce7d8964e000e79cd1448acec05b92417207baecf9b0f039a *ffmpeg-v25.8.4-win32-arm64.zip 7506346ff7a98377eca26464370a7c5a8c44d010d5c46a8357fa107980582fac *ffmpeg-v25.8.4-win32-x64.zip </del> <ins> 4a472f48b54e92855ad77606f11a620523f3abe4ee1bc2997a300ae72da4b2f5 *electron-v25.9.1-darwin-arm64-symbols.zip 247daa6c9faf711162dc623832fcb189d3c1ef6a15884084cb45c8da3a037b6b *electron-v25.9.1-darwin-arm64.zip 7d8ec9d3272dbe356deb09b47ccfda30c421b32f7e906f1186ea26f894b22dc1 *electron-v25.9.1-darwin-x64-symbols.zip 35fc99808ea026a21afeca537c218ace398d299fba7ab73d2630be513f1e1617 *electron-v25.9.1-darwin-x64.zip bfcd6ac66f067cfec08b6d18ed80b519e6d70a96d9b1d31dc2cfcf86f4a9af96 *electron-v25.9.1-linux-arm64-symbols.zip 1c8aa3f13ade23858664b687ad334634ccd698ec7d627554d16cbb596ffa7a0f *electron-v25.9.1-linux-arm64.zip dcfb4a1d6b2ceffa7a8d9a60b9de027d006753eae1278f07de907c474e71c270 *electron-v25.9.1-linux-armv7l-symbols.zip f4320f1888354e17595fb6901c03c383f45325bfba5e6e1b91b4200ff696049f *electron-v25.9.1-linux-armv7l.zip 772dd276d328549e0111b93b43d395de51ff46eba550be48c649c386997125a8 *electron-v25.9.1-linux-x64-symbols.zip 35529c411275791abf9aa46f0a2e216b0affa542757583afb438a76047f6b90c *electron-v25.9.1-linux-x64.zip 5b0b4595691da19258ce0b2c09f58ba969987d24ae8160661a715eaadf42c16b *electron-v25.9.1-win32-arm64-pdb.zip 1e67a35b41927962765a8d8cb01ce73e8c28db6453323f2661e63afd8fdf49e8 *electron-v25.9.1-win32-arm64-symbols.zip a378f5fc44e872f05d037c3ca7f03802ed3a9b2611f59741ce933f500557af7c *electron-v25.9.1-win32-arm64.zip b50f8675b12eda5d0717f83179e40b411ba3254f81bd7142821745c00b566560 *electron-v25.9.1-win32-x64-pdb.zip 8ddaa416e51bac1e93c63d1223bec37b6dd78b00c860e5b91912da09af7ff7b5 *electron-v25.9.1-win32-x64-symbols.zip f6762a98193baa9877f443c9414b1f825f99b7cf1094be579d5202b72442b5be *electron-v25.9.1-win32-x64.zip a0c2566efff0a796f751cfc63cddd52d6c4153b35b6ad582bbdd15a2c4317bc9 *ffmpeg-v25.9.1-darwin-arm64.zip b8cd9d93cdf8ebbd3caf68581b6504529b8bf2dea984b6e5f637343ea9d61946 *ffmpeg-v25.9.1-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.9.1-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.9.1-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.9.1-linux-x64.zip 2467f6567356340e8d9872753a3df486555334b7c868c0d12991f80f2353ce1f *ffmpeg-v25.9.1-win32-arm64.zip fe4676a13bf9d6f87353f3496e0fb37cd3db151fcea13dad7610a2835d238062 *ffmpeg-v25.9.1-win32-x64.zip </ins>

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: margin: 0px; } <del> .settings-editor > .settings-body .settings-tree-container .setting-item-contents .setting-item-trust-description a:focus </del> <ins> .settings-editor > .settings-body .settings-tree-container .setting-item-contents .setting-item-trust-description a:focus, </ins> .settings-editor > .settings-body .settings-tree-container .setting-item-contents .setting-item-markdown a:focus { outline: 1px solid -webkit-focus-ring-color; outline-offset: -1px; text-decoration: underline; } <del> .settings-editor > .settings-body .settings-tree-container .setting-item-contents .setting-item-trust-description a:hover </del> <ins> .settings-editor > .settings-body .settings-tree-container .setting-item-contents .setting-item-trust-description a:hover, </ins> .settings-editor > .settings-body .settings-tree-container .setting-item-contents .setting-item-markdown a:hover { <ins> cursor: pointer; </ins> text-decoration: underline; }

the Settings editor. Notice the "Editor: Tab Size" setting has a link. over the link. :bug: There's no underline text decoration, and the cursor doesn't become a pointer.


Question: command: 'git.commit', title: l10n.t('{0} Commit', '$(check)'), tooltip: this.state.isCommitInProgress ? l10n.t('Committing Changes...') : l10n.t('Commit Changes'), <del> arguments: [this.repository.sourceControl, ''] </del> <ins> arguments: [this.repository.sourceControl, null] </ins> }; }

Type: <bBug</bWhen I commit from the git extension, I frequently get an error message that "Git: Extention '' CANNOT use API proposal: telemetry". When I look at "Running Extensions", git reports 32 uncaught errors. I do not know if the two error counts are related. This only recently started happening (last couple of weeks). VS Code version: Code 1.85.1 (, 2023-12-13T09:49:37.021Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (13)</summaryExtensionVersion ------ remote-containers0.327.0 remote-wsl0.81.8 rewrap1.16.3 markdown-table-prettify3.6.0 vscode-markdownlint0.53.0 git-graph1.30.0 python2023.22.1 vscode-pylance2023.12.1 cmake-tools1.16.32 cpptools1.18.5 rewrap1.16.3 cmake0.0.17 markdown-all-in-one3.6.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
/gifPlease
Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, files are preferred as they are displayed inline on GitHub. You may find helpful as a browser-based gif recording tool. If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording ( in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue. Happy coding!
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Here's an example of the ruling.
This bug is still active. I can't get rid of the problem.


Question: command: 'git.commit', title: l10n.t('{0} Commit', '$(check)'), tooltip: this.state.isCommitInProgress ? l10n.t('Committing Changes...') : l10n.t('Commit Changes'), <del> arguments: [this.repository.sourceControl, ''] </del> <ins> arguments: [this.repository.sourceControl, null] </ins> }; }

My version of VSCode is: Versión: 1.85.2 (user setup) Confirmar: Fecha: 2024-01-18T06:40:10.514Z Electron: 25.9.7 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 SO: Windows_NT x64 10.0.
are you able to reproduce this issue every time you try to commit? When the error occurs, could you open the developer console using the "Developer: Toggle Developer Tools" command and share all the errors/warnings in there? Are you able to reproduce this issue with all the extensions disabled? Thanks!
Yes, every time I commit I have this problem. ! ! I only have 3 extensions, I disable them and the same problem occurs. ! Sorry for my English. I don't know if you mean this. But it's what I see when I open Toogle developer tools.
still getting it too. I have dozens of git repositories across multiple versions of git (development containers with different Linux versions, Windows, etc.) Happens frequently, but not always, but does seem to happen consistently on some repositories and not others.
thank you! After you reproduce the problem, could you also please send me the contents of ? Also, are you able to reproduce this issue with all extensions disabled? The easiest way to try this is to use the "Help: Troubleshoot Issue..." command from the command palette.
It seems that way. Thank you
Ok. First i delete output of git. ! After. I disable all extensions. ! After. I can one time more to make commit. ! New commit ! After commit ! Git output complet: 2024-02-01 10:24:20.195 [info] No remotes found in the git config file.


Question: command: 'git.commit', title: l10n.t('{0} Commit', '$(check)'), tooltip: this.state.isCommitInProgress ? l10n.t('Committing Changes...') : l10n.t('Commit Changes'), <del> arguments: [this.repository.sourceControl, ''] </del> <ins> arguments: [this.repository.sourceControl, null] </ins> }; }

2024-02-01 10:24:20.244 [info] git config --get commit.template [54ms] 2024-02-01 10:24:20.244 [info] git for-each-ref --format %(refname) %(objectname) %(objectname) refs/tags [49ms] 2024-02-01 10:24:20.286 [info] git status -z -uall [39ms] 2024-02-01 10:26:19.989 [info] git add -A -- . [56ms] 2024-02-01 10:26:20.264 [info] git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file - [269ms] 2024-02-01 10:26:20.308 [info] git config --get commit.template [39ms] 2024-02-01 10:26:20.317 [info] No remotes found in the git config file. 2024-02-01 10:26:20.364 [info] git config --get commit.template [49ms] 2024-02-01 10:26:20.372 [info] git for-each-ref --format %(refname) %(objectname) %(objectname) refs/tags [49ms] 2024-02-01 10:26:20.413 [info] git status -z -uall [38ms] 2024-02-01 10:26:20.480 [info] No remotes found in the git config file.


Question: command: 'git.commit', title: l10n.t('{0} Commit', '$(check)'), tooltip: this.state.isCommitInProgress ? l10n.t('Committing Changes...') : l10n.t('Commit Changes'), <del> arguments: [this.repository.sourceControl, ''] </del> <ins> arguments: [this.repository.sourceControl, null] </ins> }; }

2024-02-01 10:26:20.528 [info] git config --get commit.template [51ms] 2024-02-01 10:26:20.533 [info] git for-each-ref --format %(refname) %(objectname) %(*objectname) refs/tags [54ms] 2024-02-01 10:26:20.579 [info] git status -z -uall [40ms] 2024-02-01 10:26:41.809 [info] git ls-files --stage -- C:UserssriccOneDrive - ICCADocumentosAngularSergieCodecargaPaginasAppsrcappcontacto [49ms] 2024-02-01 10:26:41.859 [info] git cat-file -s [43ms] 2024-02-01 10:26:41.908 [info] git show --textconv [42ms] I hope it's everything you've asked for.
SOLVED For me, I found out it was because I was on a detached head on Git. For some reason, reattaching to master solved it.
Thank you! I have to admit that it's not clear to me what is happening here. Let me chat with my colleagues and see if I can come up with an action plan.
+1 for gilad905's suggestion. I was able to easily repro the problem: new repo from command line. first commit. out main and commit from git source-control panel in vscode, works. out the new head (the second commit), detached. another change and try to commit it in vs code Expected: It works correctly Actual: The commit is created in the repository, but the "telemetry" error message shown above appears.
Thanks Fix for this will be in Monday's VS Code Insiders release. Apologies for the inconvenience!
thanks
I am not, and have not been using repos. Sorry this is not the only problem occuring.
please share your repro steps in case you are able to reproduce with the latest VS Code Insiders release. Thanks!


Question: adjustWhitespace: !(item.completion.insertTextRules! & CompletionItemInsertTextRule.KeepWhitespace) }); <del> scrollState.restoreRelativeVerticalPositionOfCursor(this.editor); </del> if (!(flags & InsertFlags.NoAfterUndoStop)) { this.editor.pushUndoStop(); }

Issue Type: <bBug</bLike what the heading says, inserting a code snippet anywhere in the code file causes an autoscroll. This is a slight inconvenience, as while inserting snippets, viewing code above it is desirable, causing us to rescroll into view. So adding an option to revert to the functionality in the stable release would be preferred VS Code version: Code - Insiders 1.46.0-insider (, 2020-05-07T16:36:39.681Z) OS version: Linux x64 5.4.38-1-MANJARO <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ cpptools0.27.1 Go0.14.1 material-icon-theme4.1.0 material-theme3.5.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Yeah - that's a regression from a recent change to keep the position stable when additional edits are inserted...
is the item that caused this regression.
fixed via
Yep, it works fine now. Thanks a lot!
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


Question: adjustWhitespace: !(item.completion.insertTextRules! & CompletionItemInsertTextRule.KeepWhitespace) }); <del> scrollState.restoreRelativeVerticalPositionOfCursor(this.editor); </del> if (!(flags & InsertFlags.NoAfterUndoStop)) { this.editor.pushUndoStop(); }

This is somewhat the opposite of and the acknowledgement that computing additional text edits for all items upfront is too demanding. This issue is only about and the goal is a pragmatic solution, similar to the one that we have for . Idea accept an unresolved completion proceed with insertion as usual set up a content change listener resolve the items once resolved check if additional edits overlap with "concurrent" changes. when they overlap, do nothing otherwise proceed
The first version for this is now merged to master, it's a pragmatic approach that's better then not resolving but worst than (costly) upfront resolving. Items to followup on [ ] telemetry and follow up issues [ ] - TS issue for having incomplete items [ ] [ ] java for returning very few (resolved) completions, e.g doing the right thing
/cc - My understanding is that Java resolves all items upfront, e.g compute additional text edits during "provide", and that it is quite expensive and therefore Java only returns a small amount of items. Is that correct? Could Java return results faster when additional text edits are computed during resolve (and therefore only for selected items)?
Yes. I think so! is the dev who was working on Java completion. I believe he can provide more insights toward this topic. // cc
this is exactly the behavior that used to have, ie compute all the completion items first (fast), then the text edits were computed during resolveCompletion. We were asked to not do that as and changed to return a small subset of completion items (with incomplete=true), with full text edits computed upfront. The user experience is definitely not as good as with our initial implementation.
To be clear, computing any Java textedit upfront is costly when returning 100+ items (and we can return several thousands items). We'd prefer if the async insertion of textedits covered all textedits, not just the additional ones.
The requirements discussed in are still true and there are no plans to change that. There is (which might be derived from ) and . The former () is inserted at the cursor and must be inserted synchronous to accepting a completion (we cannot block typing while waiting for that). The latter () is meant for things like import-statements and we now want to relax that, e.g it can come late and we try to apply those edits despite the user having typed more.


Question: adjustWhitespace: !(item.completion.insertTextRules! & CompletionItemInsertTextRule.KeepWhitespace) }); <del> scrollState.restoreRelativeVerticalPositionOfCursor(this.editor); </del> if (!(flags & InsertFlags.NoAfterUndoStop)) { this.editor.pushUndoStop(); }

When exactly does run, is it only when an item gets highlighted in the menu? Can't tell from the docs. I only need to generate for the completion item the user ends up applying -- doing it for other items is unnecessary work that's bogging down the extension host, and I will have to implement yielding. I assume no one would need to generate before a completion item is applied? Is there any kind of completion applied event we can hook into to work around this for the time being?
That's exactly what is about . Today, there is no guarantee that is ever called because its original design is to provide data for the suggest details widget. However, we see that (amongst other things) are computed during resolve and leads to subtle bugs (because don't always call resolve or always await it) Well, is the problem if you do not generate them upfront. select suggestion synchronously inserts the string starts for additional text edits continues to type quickly and all over the place -call eventually returns but it is unclear if the edits are still valid because the state changed many types in-between Solutions: Won't work because in JS you cannot wait for another "thread" or "process", the world always keeps turning Implement a full -solution because this is two entities "typing" concurrently in the same document. However, it will feel awkward because the user doesn't expect to be such a scenario. approach that tries to apply additional edits if possible but inserts the "main edit" (insertText) always synchronously. () "if possible" is currently defined as "no edit has occurred before the first additional edit". That works well if you use additional edits for things like imports or prefixes (which is the indented use-case) but won't work if additional text edits change the main edit, like appending a call-operators with arguments etc
I mean JS can't block but ignoring typing while awaiting is possible -- I was imagining that VSCode would keep the completions menu open and ignore any typing until is resolved and all text edits applied for the accepted item. Obviously this would be bad if resolving takes a long time, but the API has cancelation tokens already, so the UI would just need to show a spinner/cancel icon, and also cancel if the user presses ESC or navigates to a different editor, for a decent UX.


Question: adjustWhitespace: !(item.completion.insertTextRules! & CompletionItemInsertTextRule.KeepWhitespace) }); <del> scrollState.restoreRelativeVerticalPositionOfCursor(this.editor); </del> if (!(flags & InsertFlags.NoAfterUndoStop)) { this.editor.pushUndoStop(); }

I think this would be less confusing for users too; it's the only way it would be clear when VSCode is completely done applying the completion. I think many users would be confused if imports usually get but not when they resume typing too soon. FWIW I can syncronously generate the additional text edits I need, so I'd be happy if there were an API to synchronously generate them when the completion item is accepted. I know not everyone would be able to generate them sync though.
Also I know my questions may have seemed redundant, but I hadn't seen anyone on this thread point out that it would be ideal to avoid ever computing additional text edits (or even the primary insert text) for unselected completions. Since can get called before any item is accepted (I assume, since it seems to be for showing additional details in the menu), I'd think any solution via could still result in unnecessarily generating additional edits that are ultimately discarded.
The golden rule is that "you can always type inside the editor". Ignoring typing is not a good solution and will bug users. Just think of quick suggest and auto accept characters - you don't want the editor to stop typing just because an extension is taking a little longer (+50ms). To be precise you should have written "typing at or before the offset at which additional edits are going to happen" I honestly think the majority can generate them synchronously but this happens in the extension host process or the language server process, and all of that might happen on a different machine and there is no way to synchronously transport that into the UI.
re with the current changes you should be able to have a "simple insert text", say , and compute an additional text edit, like , that goes in front of it so that you eventually have . Right? Or am I missing something?
that might actually be a good idea ;-) In practice though, we might need to revisit the way the principal TextEdit is computed (i.e rewrite a bunch of stuff from upstream JDT)
I get the desire to be able to always be able to type inside the editor and agree that's an important principle. The only reason I think this case is an exception is that: The user would probably want to wait for all edits to get applied anyway.


Question: adjustWhitespace: !(item.completion.insertTextRules! & CompletionItemInsertTextRule.KeepWhitespace) }); <del> scrollState.restoreRelativeVerticalPositionOfCursor(this.editor); </del> if (!(flags & InsertFlags.NoAfterUndoStop)) { this.editor.pushUndoStop(); }

Seems unlikely that people would want to get the main edit without the additional edits By making the operation cancelable, you can still go back to typing immediately if you so desire. I certainly wouldn't want to block the user from typing without recourse (as you know, I feel frustrated that happens currently when using Vim extensions) On the other hand, I guess it's unlikely that the additional text edits would overlap whatever the user continues typing...
I hadn't thought about auto accept characters though, that's a good point. That's something I don't have experience with. Also considering that VSCode could pop up a warning if it has to bail on inserting additional edits, it's not a big deal if it ever happens
I remember that we have some new data points regarding the time consumption in different stages of code completion in Can you share that data and see how we can tune it with this change?
For Java language server, below is a sample of call tree when triggering completion. (time value is larger than expected because of extra overhead from JProfiler) ! Total time of completion stage mainly consists of three parts: competion candidates in JDT to CompletionItems (calc textEdits, additionalTextEdits, etc.) --- calc an incomplete list of only 50 items by default (the full list can contain thousands) --- here calculating import statements costs a lot of time server-side code snippets (not much related to this topic) I did a simple experiment on java language server, with vscode-insider built on 2020-5-15. I was using spring-petclinic, which is not a big one, but with some dependencies. Type a initial letter, e.g. "O", and observe perf of completion and resolve. Do multiple times for statistics. Calculating additionalTextEdits async in resolve stage does decrease the time cost a lot. textEdits and additionalTextEdits are calculated during completion stage. completion: ~150 ms resolve(avg of top 10 items): ~10 ms Now I simply move a bunch of textedit calculation from "completion" stage into "resolve" stage. completion: ~100 ms resolve(avg of top 10 items): ~17 ms !
I just realized that can return a thenable, but I assume that would delay the appearance of the entire menu?
Closing as we haven't seen issues with the new pragmatic approach and the plan is to stick with it.


Question: adjustWhitespace: !(item.completion.insertTextRules! & CompletionItemInsertTextRule.KeepWhitespace) }); <del> scrollState.restoreRelativeVerticalPositionOfCursor(this.editor); </del> if (!(flags & InsertFlags.NoAfterUndoStop)) { this.editor.pushUndoStop(); }

so how do servers know that clients support lazy-loading of additional textedits? Surely this should be a client capability advertised by vscode (that needs to be specced in the LSP)
is the right person for that and you should probably create a follow up issue in the LSP land
corresponding LSP feature request created here please add more details if I miss anything.
Thanks
To verify: use TypeScript have a suggestion that will import a symbol make sure that suggestion isn't first or focused in the UI use the mouse(!) to select the suggestion make sure the import is there make sure undo, redo works as expected


Question: const systemShellUnix = await getSystemShell(OS, env); logService.trace('getUnixShellEnvironment#shell', systemShellUnix); <del> let command = `'${process.execPath}' -p '"${mark}" + JSON.stringify(process.env) + "${mark}"'`; let shellArgs = ['-ilc']; </del> // handle popular non-POSIX shells const name = path.basename(systemShellUnix); <ins> let command: string, shellArgs: Array<string>; </ins> if (/^pwsh(-preview)?$/.test(name)) { <del> command = `& ${command}`; </del> <ins> // Older versions of PowerShell removes double quotes sometimes so we use "double single quotes" which is how // you escape single quotes inside of a single quoted string. command = `& '${process.execPath}' -p '''${mark}'' + JSON.stringify(process.env) + ''${mark}'''`; </ins> shellArgs = ['-Login', '-Command']; <ins> } else { command = `'${process.execPath}' -p '"${mark}" + JSON.stringify(process.env) + "${mark}"'`; shellArgs = ['-ilc']; </ins> } logService.trace('getUnixShellEnvironment#spawn', JSON.stringify(shellArgs), command);

Steps that should work but don't (these will be verification steps): PowerShell for macOS if you don't have it what path was to () it as your default shell: VS Code from the dock/finder a workspace with the below task the task Actual Expected Something like: This is because we fail to get the UnixShellEnvironment. You can confirm this by looking in output, you should see:
another great verification step is replacing the command in the task and putting something like or . This will likely fail saying it couldn't find the command ... because the environment wasn't set up properly.
I'm still getting the actual output instead of the expected output when I repeated the verification steps on my Mac.


Question: const labelService = accessor.get(ILabelService); const uri = part instanceof ChatRequestDynamicVariablePart && part.data.map(d => d.value).find((d): d is URI => d instanceof URI) || undefined; <del> const title = uri ? labelService.getUriLabel(uri, { relative: true }) : ''; </del> <ins> const title = uri ? encodeURIComponent(labelService.getUriLabel(uri, { relative: true })) : ''; </ins> result += `[${part.text}](${variableRefUrl}${title})`; }

<img width="377" alt="image" src=""
Verification step- just use a variable in a multiroot workspace, and check that you have the right blue background when it's rendered in the request.
Works great. Slightly related - why do we just render the blue background while I am typing the request, but do not render it blue when the request is sent. This was always the behaviour and is unrelated to MR workspace. I am just curious !
If it was used correctly, it will have the blue background. Did you pick the file from the picker, or just type the text?
Picked from file picker.
Oh no!
Apparently I didn't test this as thoroughly as I should have. Some files now break the markdown link. Need to rework this in main for debt week but there is an easy fix for now.
For verification, we should test with Files in a multiroot workspace In single folder window Files at the top level of the workspace And under a folder
Since the PR has been merged yesterday, this issue will be closed, for verification.


Question: return this.viewDescriptorService.getViewContainersByLocation(this.location); } <del> private onDidPinnedViewContainersStorageValueChange(e: IProfileStorageValueChangeEvent): void { if (this.pinnedViewContainersValue !== this.getStoredPinnedViewContainersValue() /* This checks if current window changed the value or not */) { this._placeholderViewContainersValue = undefined; this._pinnedViewContainersValue = undefined; this._cachedViewContainers = undefined; </del> <ins> private updateCompositeBarItemsFromStorage(retainExisting: boolean): void { if (this.pinnedViewContainersValue === this.getStoredPinnedViewContainersValue()) { return; } </ins> <del> const newCompositeItems: ICompositeBarItem[] = []; const compositeItems = this.compositeBar.getCompositeBarItems(); </del> <ins> this._placeholderViewContainersValue = undefined; this._pinnedViewContainersValue = undefined; this._cachedViewContainers = undefined; </ins> <del> for (const cachedViewContainer of this.cachedViewContainers) { newCompositeItems.push({ id: cachedViewContainer.id, name: cachedViewContainer.name, order: cachedViewContainer.order, pinned: cachedViewContainer.pinned, visible: cachedViewContainer.visible && !!this.getViewContainer(cachedViewContainer.id), }); } </del> <ins> const newCompositeItems: ICompositeBarItem[] = []; const compositeItems = this.compositeBar.getCompositeBarItems(); </ins> <del> for (const viewContainer of this.getViewContainers()) { // Add missing view containers if (!newCompositeItems.some(({ id }) => id === viewContainer.id)) { const index = compositeItems.findIndex(({ id }) => id === viewContainer.id); if (index !== -1) { const compositeItem = compositeItems[index]; newCompositeItems.splice(index, 0, { id: viewContainer.id, name: typeof viewContainer.title === 'string' ? viewContainer.title : viewContainer.title.value, order: compositeItem.order, pinned: compositeItem.pinned, visible: compositeItem.visible, }); } else { newCompositeItems.push({ id: viewContainer.id, name: typeof viewContainer.title === 'string' ? viewContainer.title : viewContainer.title.value, order: viewContainer.order, pinned: true, visible: !this.shouldBeHidden(viewContainer), }); } </del> <ins> for (const cachedViewContainer of this.cachedViewContainers) { newCompositeItems.push({ id: cachedViewContainer.id, name: cachedViewContainer.name, order: cachedViewContainer.order, pinned: cachedViewContainer.pinned, visible: cachedViewContainer.visible && !!this.getViewContainer(cachedViewContainer.id), }); } for (const viewContainer of this.getViewContainers()) { // Add missing view containers if (!newCompositeItems.some(({ id }) => id === viewContainer.id)) { const index = compositeItems.findIndex(({ id }) => id === viewContainer.id); if (index !== -1) { const compositeItem = compositeItems[index]; newCompositeItems.splice(index, 0, { id: viewContainer.id, name: typeof viewContainer.title === 'string' ? viewContainer.title : viewContainer.title.value, order: compositeItem.order, pinned: compositeItem.pinned, visible: compositeItem.visible, }); } else { newCompositeItems.push({ id: viewContainer.id, name: typeof viewContainer.title === 'string' ? viewContainer.title : viewContainer.title.value, order: viewContainer.order, pinned: true, visible: !this.shouldBeHidden(viewContainer), }); </ins> } } <ins> } </ins> <del> this.compositeBar.setCompositeBarItems(newCompositeItems); </del> <ins> if (retainExisting) { for (const compositeItem of compositeItems) { const newCompositeItem = newCompositeItems.find(({ id }) => id === compositeItem.id); if (!newCompositeItem) { newCompositeItems.push(compositeItem); } } </ins> } <ins> this.compositeBar.setCompositeBarItems(newCompositeItems); </ins> } private saveCachedViewContainers(): void {

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: const result = { primary, secondary, menu }; createAndFillInContextMenuActions(menu, { shouldForwardArgs: true }, result, 'inline'); if (listen) { <del> this._register(menu.onDidChange(() => this._onDidChange.fire(element))); </del> <ins> listen.add(menu.onDidChange(() => this._onDidChange.fire(element))); listen.add(menu); </ins> } else { menu.dispose(); } return result; } <del> override dispose() { </del> <ins> dispose() { </ins> this.contextKeyService = undefined; <del> super.dispose(); </del> } }

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: V1.81.1 OS Version: Linux kkuser-virtual-machine 5.15.0-83-generic ~20.04.1-Ubuntu SMP Mon Aug 21 14:00:49 UTC 2023 x8664 x8664 x8664 GNU/Linux Steps to Reproduce: are constant changes in attribute states in the treeview calls to () functions result in memory leakage
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.82.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!


Question: import { localize } from 'vs/nls'; import { InstantiationType, registerSingleton } from 'vs/platform/instantiation/common/extensions'; import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; <del> import { AccessibilityVerbositySettingId, registerAccessibilityConfiguration } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; </del> <ins> import { AccessibilityVerbositySettingId, accessibleViewIsShown, registerAccessibilityConfiguration } from 'vs/workbench/contrib/accessibility/browser/accessibilityConfiguration'; </ins> import * as strings from 'vs/base/common/strings'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { IWorkbenchContributionsRegistry, Extensions as WorkbenchExtensions } from 'vs/workbench/common/contributions';

accessible view go to symbol picker are closed sometimes (when there's more than one item) cc


Question: // Write content if it differs if (content && this._currentContent !== content) { this._stickyScrollOverlay.resize(this._stickyScrollOverlay.cols, stickyScrollLineCount); <ins> // Clear attrs, reset cursor position, clear right </ins> this._stickyScrollOverlay.write('x1b[0mx1b[Hx1b[2J'); this._stickyScrollOverlay.write(content); this._currentContent = content;

Testing So I was testing the terminal sticky scroll and I noticed that the sticky code block disappears in an abrupt manner when the beginning (not the end) of the multiline terminal command, reaches the end of the scope. To give more context about what I mean, I the GIF below. I was sort of expecting the code block to start disappearing when the line reached the end of the output for that command. I noticed that the code block disappeared however when the line reached the end of the output for that run. I don't think this is a problem per say, it's a different manner of animating sticky scroll. I was just wondering if this is intended? I think the potential issue with this approach is that the sticky scroll block is hiding the next terminal command and its output while you are scrolling until it disappears. In the editor, sticky scroll starts disappearing progressively when the bottom of the last block/line touches the end of the scope. Perhaps we could explore something similar?
This is actually a bug, it's meant to scroll up as in the editor and was doing that at some point. Note that it's not as smooth as the editor since there's no "partial line scrolling" in the terminal
Repro that demonstrates more clearly what's happening: Run: Run: Run: when scrolling, sticky scroll from a command should never obscure the command below it like this: !
I see the prompt line sort of being obscured here


Question: disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"

<!-- 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: disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"

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: } // Auxiliary Panel to restore <del> if (this.isVisible(Parts.AUXILIARYBAR_PART)) { </del> <ins> const auxiliaryBarVisible = this.isVisible(Parts.AUXILIARYBAR_PART); if (auxiliaryBarVisible || (isNewWindow && activityBarNotDefault)) { </ins> const viewContainerToRestore = this.storageService.get(AuxiliaryBarPart.activePanelSettingsKey, StorageScope.WORKSPACE, this.viewDescriptorService.getDefaultViewContainer(ViewContainerLocation.AuxiliaryBar)?.id); if (viewContainerToRestore) { this.state.initialization.views.containerToRestore.auxiliaryBar = viewContainerToRestore; <del> } else { this.stateModel.setRuntimeValue(LayoutStateKeys.AUXILIARYBAR_HIDDEN, true); </del> <ins> } if (auxiliaryBarVisible !== !!viewContainerToRestore) { this.stateModel.setRuntimeValue(LayoutStateKeys.AUXILIARYBAR_HIDDEN, !auxiliaryBarVisible); </ins> } }

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --I found that once the [Activity Bar Position] is set to [Top], i can't find the activity bar at the top anymore, when i click [File-New Window] to open a new window. Therefore, i suggest display the activity bar by default when opening a new window.
<img width="1068" alt="" src=""As shown in the picture, the new window does not display the activity bar.
I like this idea, I will look into it.


Question: class FileUserDataProfileContentHandler implements IUserDataProfileContentHandler { readonly name = localize('local', "Local"); <ins> readonly description = localize('file', "file"); </ins> constructor( @IFileDialogService private readonly fileDialogService: IFileDialogService,

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.