Question:
Issue Type: <bBug</bWhile doing some experimentation with Bootstrap and the corresponding scss files, I encountered an issue while changing hexcolor codes. I was able to reproduce it on a different Windows machine (Windows 11 in that case) as well as on macOS (Monterey). Steps to reproduce: Open a large scss file. In my case, I used from the Bootstrap framework. Start changing a color by typing a different hex value. The issue only happened when changing at least two of the six digits and sometimes only after making a couple of changes. It did not happen when using the color picker. will become unresponsive eventually. For example the color pickers do not show up anymore, saving a file takes multiple seconds and the git integration stops working entirely. When the builtin SCSS extension is disabled, everything works fine. Therefore I would assume that this extension is causing the issue. VS Code version: Code 1.63.2 (, 2021-12-15T09:40:02.816Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I can reproduce open a scss file with on the end of line 15, add a character . Note that diagnostics appear, Remove the character, diagnostics disappear (all good) on the end of line 15, add a character . Nothing happens. Hover over a symbol, hover computes forever: Extension host is blocked remove the letter, reload the window disable the emmet extension repeat the steps, now all is working When profiling, the emmet extension is busy in The bug got introduced in 1.53
There are 3 conditions that must be met to trigger this issue: must return one of , , , , or (so that in returns true). File must be longer than 1000 lines (so that is called as noted above). The first must begin with The culprit is from When trying to skip over blocks, this function attempts to peak back 1 character when it encounters to check for a (1)()` is then called to move the position back to where it was at the start of the function, but in this case moves it back to position 1:2. This causes the loop that calls to loop infinitely, as the exit condition (position being to , in this case the start of the file) never occurs. Pull Request Resolves this by checking if the character being "peaked" at is a and breaking out of before is called. An alternative solution would be to not call if is within 3 characters of (as there is not enough space remaining to contain .
Thanks for the explanation I'll comment on the PR.

} function consumeBlockCommentBackwards() { <del> if (stream.peek() === slash) { </del> <ins> if (!stream.sof() && stream.peek() === slash) { </ins> if (stream.backUp(1) === star) { stream.pos = findOpeningCommentBeforePosition(stream.pos) ?? startOffset; } else {


Question:
Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.

if (!this.galleryService.isEnabled()) { throw new ExtensionManagementError(nls.localize('MarketPlaceDisabled', "Marketplace is not enabled"), ExtensionManagementErrorCode.Internal); } <del> const compatible = await this.checkAndGetCompatibleVersion(extension, !options.installGivenVersion, !!options.installPreReleaseVersion); </del> <ins> const compatible = await this.checkAndGetCompatibleVersion(extension, !!options.installGivenVersion, !!options.installPreReleaseVersion); </ins> return await this.installExtension(compatible.manifest, compatible.extension, options); } catch (error) { reportTelemetry(this.telemetryService, 'extensionGallery:install', { extensionData: getGalleryExtensionTelemetryData(extension), error });


Question:
Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.

const isDependency = dependecies.some(id => areSameExtensions({ id }, galleryExtension.identifier)); let compatible; try { <del> compatible = await this.checkAndGetCompatibleVersion(galleryExtension, true, installPreRelease); </del> <ins> compatible = await this.checkAndGetCompatibleVersion(galleryExtension, false, installPreRelease); </ins> } catch (error) { if (error instanceof ExtensionManagementError && error.code === ExtensionManagementErrorCode.IncompatibleTargetPlatform && !isDependency) { this.logService.info('Skipping the packed extension as it cannot be installed', galleryExtension.identifier.id);


Question:
Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.

return allDependenciesAndPacks.filter(e => !installed.some(i => areSameExtensions(i.identifier, e.gallery.identifier))); } <del> private async checkAndGetCompatibleVersion(extension: IGalleryExtension, fetchCompatibleVersion: boolean, installPreRelease: boolean): Promise<{ extension: IGalleryExtension; manifest: IExtensionManifest }> { </del> <ins> private async checkAndGetCompatibleVersion(extension: IGalleryExtension, sameVersion: boolean, installPreRelease: boolean): Promise<{ extension: IGalleryExtension; manifest: IExtensionManifest }> { </ins> const report = await this.getExtensionsControlManifest(); if (getMaliciousExtensionsSet(report).has(extension.identifier.id)) { throw new ExtensionManagementError(nls.localize('malicious extension', "Can't install '{0}' extension since it was reported to be problematic.", extension.identifier.id), ExtensionManagementErrorCode.Malicious);


Question:
Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.

throw new ExtensionManagementError(nls.localize('incompatible platform', "The '{0}' extension is not available in {1} for {2}.", extension.identifier.id, this.productService.nameLong, TargetPlatformToString(targetPlatform)), ExtensionManagementErrorCode.IncompatibleTargetPlatform); } <del> const compatibleExtension = await this.getCompatibleVersion(extension, fetchCompatibleVersion, installPreRelease); </del> <ins> const compatibleExtension = await this.getCompatibleVersion(extension, sameVersion, installPreRelease); </ins> if (compatibleExtension) { <del> if (installPreRelease && fetchCompatibleVersion && extension.hasPreReleaseVersion && !compatibleExtension.properties.isPreReleaseVersion) { </del> <ins> if (installPreRelease && !sameVersion && extension.hasPreReleaseVersion && !compatibleExtension.properties.isPreReleaseVersion) { </ins> throw new ExtensionManagementError(nls.localize('notFoundCompatiblePrereleaseDependency', "Can't install pre-release version of '{0}' extension because it is not compatible with the current version of {1} (version {2}).", extension.identifier.id, this.productService.nameLong, this.productService.version), ExtensionManagementErrorCode.IncompatiblePreRelease); } } else {


Question:
Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.

return { extension: compatibleExtension, manifest }; } <del> protected async getCompatibleVersion(extension: IGalleryExtension, fetchCompatibleVersion: boolean, includePreRelease: boolean): Promise<IGalleryExtension | null> { </del> <ins> protected async getCompatibleVersion(extension: IGalleryExtension, sameVersion: boolean, includePreRelease: boolean): Promise<IGalleryExtension | null> { </ins> const targetPlatform = await this.getTargetPlatform(); let compatibleExtension: IGalleryExtension | null = null; <del> if (fetchCompatibleVersion && extension.hasPreReleaseVersion && extension.properties.isPreReleaseVersion !== includePreRelease) { </del> <ins> if (!sameVersion && extension.hasPreReleaseVersion && extension.properties.isPreReleaseVersion !== includePreRelease) { </ins> compatibleExtension = (await this.galleryService.getExtensions([{ ...extension.identifier, preRelease: includePreRelease }], { targetPlatform, compatible: true }, CancellationToken.None))[0] || null; }


Question:
Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.

compatibleExtension = extension; } <del> if (!compatibleExtension && fetchCompatibleVersion) { compatibleExtension = await this.galleryService.getCompatibleExtension(extension, includePreRelease, targetPlatform); </del> <ins> if (!compatibleExtension) { if (sameVersion) { compatibleExtension = (await this.galleryService.getExtensions([{ ...extension.identifier, version: extension.version }], { targetPlatform, compatible: true }, CancellationToken.None))[0] || null; } else { compatibleExtension = await this.galleryService.getCompatibleExtension(extension, includePreRelease, targetPlatform); } </ins> } return compatibleExtension;


Question:
Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.

throw new Error('Missing gallery'); } <del> const [gallery] = await this.galleryService.getExtensions([{ id: extension.gallery.identifier.id, version }], CancellationToken.None); </del> <ins> const targetPlatform = extension.server ? await extension.server.extensionManagementService.getTargetPlatform() : undefined; const [gallery] = await this.galleryService.getExtensions([{ id: extension.gallery.identifier.id, version }], { targetPlatform }, CancellationToken.None); </ins> if (!gallery) { throw new Error(nls.localize('not found', "Unable to install extension '{0}' because the requested version '{1}' is not found.", extension.gallery!.identifier.id, version)); }


Question:
Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.

return this.installExtension(manifest, location, options); } <del> protected override async getCompatibleVersion(extension: IGalleryExtension, fetchCompatibleVersion: boolean, includePreRelease: boolean): Promise<IGalleryExtension | null> { const compatibleExtension = await super.getCompatibleVersion(extension, fetchCompatibleVersion, includePreRelease); </del> <ins> protected override async getCompatibleVersion(extension: IGalleryExtension, sameVersion: boolean, includePreRelease: boolean): Promise<IGalleryExtension | null> { const compatibleExtension = await super.getCompatibleVersion(extension, sameVersion, includePreRelease); </ins> if (compatibleExtension) { return compatibleExtension; }


Question:
Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.

constructor() { super({ <del> id: 'workbench.action.clearCommandHistory', title: { value: localize('clearCommandHistory', "Clear Command History"), original: 'Clear Command History' }, </del> <ins> id: 'workbench.action.clearPreviousSessionCommandHistory', title: { value: localize('clearPreviousSessionCommandHistory', "Clear Previous Session Command History"), original: 'Clear Previous Session Command History' }, </ins> f1: true }); }


Question:
Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.

// Ask for confirmation const { confirmed } = await dialogService.confirm({ <del> message: localize('confirmClearMessage', "Do you want to clear the history of recently used commands?"), </del> <ins> message: localize('confirmClearMessage', "Do you want to clear the previous session command history?"), </ins> detail: localize('confirmClearDetail', "This action is irreversible!"), primaryButton: localize({ key: 'clearButtonLabel', comment: ['&& denotes a mnemonic'] }, "&&Clear"), type: 'warning'


Question:
Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.

registerAction2(class extends Action2 { constructor() { super({ <del> id: TerminalCommandId.ClearCommandHistory, title: { value: localize('workbench.action.terminal.clearCommandHistory', "Clear Command History"), original: 'Clear Command History' }, </del> <ins> id: TerminalCommandId.ClearPreviousSessionHistory, title: { value: localize('workbench.action.terminal.clearPreviousSessionHistory', "Clear Previous Session History"), original: 'Clear Previous Session History' }, </ins> f1: true, category, precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated)


Question:
Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.

MoveToEditorInstance = 'workbench.action.terminal.moveToEditorInstance', MoveToTerminalPanel = 'workbench.action.terminal.moveToTerminalPanel', SetDimensions = 'workbench.action.terminal.setDimensions', <del> ClearCommandHistory = 'workbench.action.terminal.clearCommandHistory', </del> <ins> ClearPreviousSessionHistory = 'workbench.action.terminal.clearPreviousSessionHistory', </ins> WriteDataToTerminal = 'workbench.action.terminal.writeDataToTerminal', ShowTextureAtlas = 'workbench.action.terminal.showTextureAtlas', ShowTerminalAccessibilityHelp = 'workbench.action.terminal.showAccessibilityHelp',


Question:
Can we add some additional padding to the top of the TOC, to match the container on the right? !
Good idea. Assigning to March, though, because when I padding earlier, the end of the list got cut off, and I couldn't find a quick workaround.
This one's tough. A few attempts: Increasing the padding and doing nothing else results in the last entry being cut off. Increasing the padding and manually making the lists render at different heights results in the last entry showing, but the scrollbar not touching the bottom when the user scrolls to the bottom of the list. Creating a new element to stick above the scrollable list results in the shadow being pushed down. We want to keep the shadow at the top edge of the container. Adding a fake settings group with no settings to try and get the list to add a spacer element does nothing, because a settings group needs settings to show up in the ToC.
how did we get the padding to work before? Maybe we can ask the list widget to provide a padding param to adjust the height?
Before, we weren't using a splitview. The shadow was lower, and there was no sash. If we add padding elements above the splitview views right now, we will have the sash and the shadow intersect again in a + shape rather than a T shape.
Do you want the padding inside the list view, or outside of it? If you want it inside the listview, you can add it to an element and include this in the size returned from . If you just put css padding inside the list by itself, that will mess the list up
I would like the padding to be inside the listview. Adding the padding to the element results in a different focus border shape for that element.
What if you use a margin-top on the first element instead of padding?
I believe in this case, either the whole list gets pushed down and truncated at the end, or if I adjust the list height manually, the scrollbar fails to scroll all the way to the end when the list is also at the end. I also reopened an older version of Code and noticed that the list itself didn't actually have padding. There was padding above it, and the shadow was lower, as a result. !
I wouldn't mind it if the list had that top margin, I still think the line connecting to the user/workspace heading gives the impression that the top is also resizable (like editor grids) so staying away from that as much as possible would be preferred: <img width="855" alt="CleanShot 2022-03-14 at 14 03 38 src="https://user-"<img width="851" alt="CleanShot 2022-03-14 at 14 02 34 src="https://user-"
Verification steps: Settings editor should look closer to In other words, there should be a gap between the vertical splitview sash and the horizontal tabs/scope widget underline. one scrolls down on either side, horizontal shadows should appear below the horizontal underline.
Verified at described, not sure it looks better now than before though because the shadow no longer aligns with the horizontal bar above.

box-sizing: border-box; } <ins> .settings-editor > .settings-body > .monaco-split-view2 { margin-top: 14px; } </ins> .settings-editor.no-results > .settings-body .settings-toc-container, .settings-editor.no-results > .settings-body .settings-tree-container { display: none;


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

} .monaco-workbench .editor-instance .terminal-group .monaco-split-view2.horizontal .split-view-view:first-child .xterm, <del> .monaco-workbench .pane-body.integrated-terminal .terminal-group .monaco-split-view2.horizontal .split-view-view:first-child .xterm { </del> <ins> .monaco-workbench .pane-body.integrated-terminal .terminal-group .monaco-split-view2.horizontal .split-view-view:first-child .xterm, .monaco-workbench .editor-instance .terminal-group .monaco-split-view2.horizontal .split-view-view .xterm.shell-integration, .monaco-workbench .pane-body.integrated-terminal .terminal-group .monaco-split-view2.horizontal .split-view-view .xterm.shell-integration, .monaco-split-view2.vertical .split-view-view .xterm.shell-integration { </ins> padding-left: 20px; } .monaco-workbench .editor-instance .terminal-group .monaco-split-view2.horizontal .split-view-view:last-child .xterm, .monaco-workbench .pane-body.integrated-terminal .terminal-group .monaco-split-view2.horizontal .split-view-view:last-child .xterm { padding-right: 20px;


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

* viewport. */ clearBuffer(): void; <ins> /** * Clears decorations - for example, when shell integration is disabled. */ clearDecorations(): void; </ins> } export interface IRequestAddInstanceToGroupEvent {


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

e.affectsConfiguration(TerminalSettingId.TerminalDescription)) { this._labelComputer?.refreshLabel(); } <ins> if ((e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationsEnabled) && !this._configurationService.getValue(TerminalSettingId.ShellIntegrationDecorationsEnabled)) || (e.affectsConfiguration(TerminalSettingId.ShellIntegrationEnabled) && !this._configurationService.getValue(TerminalSettingId.ShellIntegrationEnabled))) { this.xterm?.clearDecorations(); } </ins> })); this._workspaceContextService.onDidChangeWorkspaceFolders(() => this._labelComputer?.refreshLabel());


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

DefaultColor = 'default', Codicon = 'codicon', XtermDecoration = 'xterm-decoration', <del> FirstSplitContainer = '.pane-body.integrated-terminal .terminal-group .monaco-split-view2.horizontal .split-view-view:first-child .xterm' </del> <ins> ShellIntegration = 'shell-integration' </ins> } const enum DecorationStyles { DefaultDimension = 16, <del> MarginLeftFirstSplit = -17, MarginLeft = -12 </del> <ins> MarginLeft = -17, </ins> } interface IDisposableDecoration { decoration: IDecoration; disposables: IDisposable[]; exitCode?: number }


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

this._refreshClasses(); } else if (e.affectsConfiguration(TerminalSettingId.FontSize) || e.affectsConfiguration(TerminalSettingId.LineHeight)) { this.refreshLayouts(); <del> } else if (e.affectsConfiguration(TerminalSettingId.ShellIntegrationDecorationsEnabled) && !this._configurationService.getValue(TerminalSettingId.ShellIntegrationDecorationsEnabled)) { this._commandStartedListener?.dispose(); this._commandFinishedListener?.dispose(); this._clearDecorations(); </del> } }); }


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

} } <del> private _clearDecorations(): void { </del> <ins> public clearDecorations(disposeOfListeners?: boolean): void { if (disposeOfListeners) { this._commandStartedListener?.dispose(); this._commandFinishedListener?.dispose(); } </ins> this._placeholderDecoration?.dispose(); this._placeholderDecoration?.marker.dispose(); for (const value of this._decorations.values()) { <ins> value.decoration.element?.parentElement?.parentElement?.parentElement?.classList.remove(DecorationSelector.ShellIntegration); </ins> value.decoration.dispose(); value.decoration.marker.dispose(); dispose(value.disposables);


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

if (this._placeholderDecoration?.marker.id) { this._decorations.delete(this._placeholderDecoration?.marker.id); } <ins> if (command.command.trim().toLowerCase() === 'clear' || command.command.trim().toLowerCase() === 'cls') { this.clearDecorations(); return; } </ins> this._placeholderDecoration?.dispose(); this.registerCommandDecoration(command); });


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

const lineHeight = this._configurationService.inspect(TerminalSettingId.LineHeight).value; if (typeof fontSize === 'number' && typeof defaultFontSize === 'number' && typeof lineHeight === 'number') { const scalar = (fontSize / defaultFontSize) <= 1 ? (fontSize / defaultFontSize) : 1; // must be inlined to override the inlined styles from xterm element.style.width = `${scalar * DecorationStyles.DefaultDimension}px`; element.style.height = `${scalar * DecorationStyles.DefaultDimension * lineHeight}px`; element.style.fontSize = `${scalar * DecorationStyles.DefaultDimension}px`; <del> // the first split terminal in the panel has more room if (element.closest(DecorationSelector.FirstSplitContainer)) { element.style.marginLeft = `${scalar * DecorationStyles.MarginLeftFirstSplit}px`; } else { element.style.marginLeft = `${scalar * DecorationStyles.MarginLeft}px`; } </del> <ins> element.style.marginLeft = `${scalar * DecorationStyles.MarginLeft}px`; </ins> } }


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

element.classList.remove(classes); } element.classList.add(DecorationSelector.CommandDecoration, DecorationSelector.Codicon, DecorationSelector.XtermDecoration); <ins> element.parentElement?.parentElement?.parentElement?.classList.add(DecorationSelector.ShellIntegration); </ins> if (exitCode === undefined) { element.classList.add(DecorationSelector.DefaultColor); element.classList.add(`codicon-${this._configurationService.getValue(TerminalSettingId.ShellIntegrationDecorationIcon)}`);


Question:
Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially

this.raw.clearTextureAtlas(); } <ins> clearDecorations(): void { this._decorationAddon?.clearDecorations(true); } </ins> forceRefresh() { this._core.viewport?._innerRefresh();


Question:
Testing We should consider increasing the line height for headers in order to provide spacing between lines. !
Possibly related: and
cc
It is also perhaps reasonable to suggest that the top margin is too large on the first header so you end up with more space at the top of the markdown block than at the bottom and it is not possible to balance if you want a header at the top. It might be worth considering some styles that remove the margin-top from headers when inside a ?

.monaco-hover p, .monaco-hover .code, <del> .monaco-hover ul { </del> <ins> .monaco-hover ul, .monaco-hover h1, .monaco-hover h2, .monaco-hover h3, .monaco-hover h4, .monaco-hover h5, .monaco-hover h6 { </ins> margin: 8px 0; } <ins> .monaco-hover h1, .monaco-hover h2, .monaco-hover h3, .monaco-hover h4, .monaco-hover h5, .monaco-hover h6 { line-height: 1.1; } </ins> .monaco-hover code { font-family: var(--monaco-monospace-font); }


Question:
Issue Type: <bBug</bRunning tasks with dependencies in a multi-root workspace executes the wrong dependency tasks, if there are multiple tasks defined under the same label but in different root folders. VSCode will just pick the first occurance in the order of the root folders defined in the workspace settings. To reproduce the issue: a simple multi-root workspace, e.g. each root folder, add a with two tasks. One task depends on the other. Example tasks of : and have the same tasks configured except that they echo their respective folder name instead. task of either or . VS Code version: Code 1.65.1 (, 2022-03-08T02:06:27.846Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Experiencing same issue on: VS Code version: 1.65.1 OS version: macOS 12.2.1 BuildVersion:21D62
To verify: or create a multi root workspace with 2 roots, FolderOne and FolderTwo (or names of your choice). each of your roots add a .vscode folder. each of your .vscode folders add a file with the following contents: "PrimaryTask" in FolderOne (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderOne" next to it). Verify that both PrimaryTask and DependsTask echo FolderOne's path. "PrimaryTask" in Folder Two (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderTwo" next to it). Verify that both PrimaryTask and DependsTask echo FolderTwo's path.

let resolverData: Map<string, ResolverData> | undefined; <del> async function quickResolve(that: AbstractTaskService, identifier: string | TaskIdentifier) { </del> <ins> async function quickResolve(that: AbstractTaskService, uri: URI | string, identifier: string | TaskIdentifier) { </ins> const foundTasks = await that._findWorkspaceTasks((task: Task | ConfiguringTask): boolean => { <ins> const taskUri = ((ConfiguringTask.is(task) || CustomTask.is(task)) ? task._source.config.workspaceFolder?.uri : undefined); const originalUri = (typeof uri === 'string' ? uri : uri.toString()); if (taskUri?.toString() !== originalUri) { return false; } </ins> if (Types.isString(identifier)) { return ((task._label === identifier) || (task.configurationProperties.identifier === identifier)); } else {


Question:
Issue Type: <bBug</bRunning tasks with dependencies in a multi-root workspace executes the wrong dependency tasks, if there are multiple tasks defined under the same label but in different root folders. VSCode will just pick the first occurance in the order of the root folders defined in the workspace settings. To reproduce the issue: a simple multi-root workspace, e.g. each root folder, add a with two tasks. One task depends on the other. Example tasks of : and have the same tasks configured except that they echo their respective folder name instead. task of either or . VS Code version: Code 1.65.1 (, 2022-03-08T02:06:27.846Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Experiencing same issue on: VS Code version: 1.65.1 OS version: macOS 12.2.1 BuildVersion:21D62
To verify: or create a multi root workspace with 2 roots, FolderOne and FolderTwo (or names of your choice). each of your roots add a .vscode folder. each of your .vscode folders add a file with the following contents: "PrimaryTask" in FolderOne (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderOne" next to it). Verify that both PrimaryTask and DependsTask echo FolderOne's path. "PrimaryTask" in Folder Two (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderTwo" next to it). Verify that both PrimaryTask and DependsTask echo FolderTwo's path.

return undefined; } if ((resolverData === undefined) && (grouped === undefined)) { <del> return (await quickResolve(this, identifier)) ?? fullResolve(this, uri, identifier); </del> <ins> return (await quickResolve(this, uri, identifier)) ?? fullResolve(this, uri, identifier); </ins> } else { return fullResolve(this, uri, identifier); }


Question:
<!-- 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.65.0 OS Version: Windows 11 Enterprise Steps to Reproduce: a remote window, create an untitled file and paste these contents. ! this untitled file, a save prompt (modal) will appear. Click Save button. You will see something like this: ! suggested file name is $schema: and only azuremlschemas.azureedg is highlighted and not the whole file name which was suggested This works fine on a local window as the suggested file name is azuremlschemas.azureedg: as shown below: !
For untitled files, the first line is used as file name. I am not sure why there would be any difference between the simple and native dialog but I actually think the simple one behaves correctly here, though there seems to be mentioned highlighting issue.
I think our main concern is the highlight, for the name we would ideally like to have custom inputs from the extension but that is a completely different discussion.
All the simple file dialog knows is that there is a default save URI given to it. The highlight is done by using the basename of that default URI. I took a look at where the default save URI comes from, and it looks like suffers from the same issue of using the basename that simple file dialog does: The best fix seems to be to fix the default save URI. PR incoming.

// of untitled model if it is a valid path name, // otherwise fallback to `basename`. let untitledName = model.name; <del> if (!(await this.pathService.hasValidBasename(joinPath(defaultFilePath, untitledName)))) { </del> <ins> if (!(await this.pathService.hasValidBasename(joinPath(defaultFilePath, untitledName), untitledName))) { </ins> untitledName = basename(resource); }


Question:
This tracks the issue discovered in See for this discussion as well. We originally thought that issue had the same root causes as this one, but investigation revealed that was not the case
I've debugged this in an OSS build. It's a difficult consistently hitting the original issue from but I do some really odd behavior around view state being saved and restored Here's what I was doing: active PR view the views window back to active PR view once it is loaded After step 2, I see the following data being written for the views in : ! However when the state is then restored by , I see the following data being loaded (look at the sizes specifically): ! Will try to track down if some other code is writing this incorrect size data or if the reload is somehow restoring it incorrectly on reload
Adding and to see if you have any ideas about what's going on here. I've been debugging through the storage calls (at least on the renderer side) and we seem be writing the values as expected but on reload we still get back the incorrect values
Reopening this as I'm still seeing this issue on
After debugging further, here's what is happening: Basics: The GitHub PR view contains 3 views (from top to bottom): , , On reload with a PR, all 3 of these views start as visible. The PR extension then hides the view by updating a context key Bug: window view is created first After finishes, we have the sizes: we add After finishes, we have the sizes: we add The sizes are now now call for the various views (in a loop) Here however, we have very large saved view size for (1012) This means that when we do for the welcome view, the other two views to become quite small. In my testing after finishes here, the sizes of the three views are: then remove the view (I believe this is triggered by the PR extension changing the view's context key) causes the last view () to fill in the now empty space below it complete this time, the sizes of the two remaining views are: So in summary: the view has a very large saved view size (presumably from initial load) and this large size effects the sizes of the other two views even though the welcome view is immediately hidden However I don't know what the proper fix for this. Should we try saving off the fact that the welcome view has been conditionally hidden for example? Should we try saving a more accurate size for the welcome view? I think I've made about as much progress as I reasonable can in this space without any real understand of the view code. Can you please take this issue from here?
Thank you for looking into this and tracking it down .
Sure - thanks for update
To be clear, is this the bug we are planning to fix? (After refresh the bottom view is taking more space) https://user-
Yes, that's the one.
I can reproduce this behaviour with following sample extension <details<summaryExtension</summary</detailshttps://user- analysis is correct In the beginning first 2 views are visible and are sized equal. After 5 seconds, third view comes in and sizes are still distributed. After 2 seconds, third view is made hidden by setting the context. At this point, last view is removed and its space is allocated to the view (second view) before last view. First view takes 33% and Second view takes 67% of the total size. Instead the removed size shall be equally distributed to all visible views. Used DistributeSizing option while removing the pane and this seems to fix it. https://user- CC - I do not have much experience in using split views and do not know what are the side affects of using option. So please take a look and update/enhance the fix if needed.
Great analysis! the docs say: ! Which means: When using in , all other views will be resized to distribute the total splitview size. Without that option, the regular layout algorithm will happen... usually that means that only the adjacent view will stretch.
I am not sure if the following doc says the same or I am wrong: As per the doc, I was expecting that the removed view space is distributed equally across other views. But it is not and it is doing as you mentioned. This also explains why the views sizes are getting reset to equal sizes after a view is removed (when DistributeSizing option was used).
Thanks for calling that out! I'm improved the docs there.
Given that it is not doing what I am expecting - removed view space is distributed equally across other views. Is there an other option to achieve this?
Not today, no.
It means the above fix has the side affect that views sizes get reset when a view is removed - which I think is ok. CC
First off, thank you all for your investigations. however, I'm not sure this is a viable solution. Any time a view is removed this will resize all views which can feel quite wrong. See the gif below where we hide the outline view. The only other expanded view is quite small and becomes now half of my screen. The same can happen with drag and drop of views as well. !
I agree the new behaviour is not ideal but it is acceptable when compared to existing. Probably we can improvise it by not to distribute space when the view is collapsed? BTW I also observe the same in editor groups. https://user-
I've approved the PR. I think the change we have made is a band-aid that helps, but doesn't cut to the root of the problem. I thought through various view/hide scenarios and in each case, I had a different feeling about what I expected to happen with the sizing of the views. IMO, our previous behavior was more correct from the pane view side as an intentional "hide" operation on a view should not redistribute every view in the container. However, the problem here is that there is a problematic extra view that is not controlled by the user. In this case, we are just trying to get sane sizing. If we invest more time in this, I think the fix lives at a higher layer.

import { ScrollEvent } from 'vs/base/common/scrollable'; import 'vs/css!./paneview'; import { localize } from 'vs/nls'; <del> import { IView, SplitView } from './splitview'; </del> <ins> import { IView, Sizing, SplitView } from './splitview'; </ins> export interface IPaneOptions { minimumBodySize?: number;


Question:
This tracks the issue discovered in See for this discussion as well. We originally thought that issue had the same root causes as this one, but investigation revealed that was not the case
I've debugged this in an OSS build. It's a difficult consistently hitting the original issue from but I do some really odd behavior around view state being saved and restored Here's what I was doing: active PR view the views window back to active PR view once it is loaded After step 2, I see the following data being written for the views in : ! However when the state is then restored by , I see the following data being loaded (look at the sizes specifically): ! Will try to track down if some other code is writing this incorrect size data or if the reload is somehow restoring it incorrectly on reload
Adding and to see if you have any ideas about what's going on here. I've been debugging through the storage calls (at least on the renderer side) and we seem be writing the values as expected but on reload we still get back the incorrect values
Reopening this as I'm still seeing this issue on
After debugging further, here's what is happening: Basics: The GitHub PR view contains 3 views (from top to bottom): , , On reload with a PR, all 3 of these views start as visible. The PR extension then hides the view by updating a context key Bug: window view is created first After finishes, we have the sizes: we add After finishes, we have the sizes: we add The sizes are now now call for the various views (in a loop) Here however, we have very large saved view size for (1012) This means that when we do for the welcome view, the other two views to become quite small. In my testing after finishes here, the sizes of the three views are: then remove the view (I believe this is triggered by the PR extension changing the view's context key) causes the last view () to fill in the now empty space below it complete this time, the sizes of the two remaining views are: So in summary: the view has a very large saved view size (presumably from initial load) and this large size effects the sizes of the other two views even though the welcome view is immediately hidden However I don't know what the proper fix for this. Should we try saving off the fact that the welcome view has been conditionally hidden for example? Should we try saving a more accurate size for the welcome view? I think I've made about as much progress as I reasonable can in this space without any real understand of the view code. Can you please take this issue from here?
Thank you for looking into this and tracking it down .
Sure - thanks for update
To be clear, is this the bug we are planning to fix? (After refresh the bottom view is taking more space) https://user-
Yes, that's the one.
I can reproduce this behaviour with following sample extension <details<summaryExtension</summary</detailshttps://user- analysis is correct In the beginning first 2 views are visible and are sized equal. After 5 seconds, third view comes in and sizes are still distributed. After 2 seconds, third view is made hidden by setting the context. At this point, last view is removed and its space is allocated to the view (second view) before last view. First view takes 33% and Second view takes 67% of the total size. Instead the removed size shall be equally distributed to all visible views. Used DistributeSizing option while removing the pane and this seems to fix it. https://user- CC - I do not have much experience in using split views and do not know what are the side affects of using option. So please take a look and update/enhance the fix if needed.
Great analysis! the docs say: ! Which means: When using in , all other views will be resized to distribute the total splitview size. Without that option, the regular layout algorithm will happen... usually that means that only the adjacent view will stretch.
I am not sure if the following doc says the same or I am wrong: As per the doc, I was expecting that the removed view space is distributed equally across other views. But it is not and it is doing as you mentioned. This also explains why the views sizes are getting reset to equal sizes after a view is removed (when DistributeSizing option was used).
Thanks for calling that out! I'm improved the docs there.
Given that it is not doing what I am expecting - removed view space is distributed equally across other views. Is there an other option to achieve this?
Not today, no.
It means the above fix has the side affect that views sizes get reset when a view is removed - which I think is ok. CC
First off, thank you all for your investigations. however, I'm not sure this is a viable solution. Any time a view is removed this will resize all views which can feel quite wrong. See the gif below where we hide the outline view. The only other expanded view is quite small and becomes now half of my screen. The same can happen with drag and drop of views as well. !
I agree the new behaviour is not ideal but it is acceptable when compared to existing. Probably we can improvise it by not to distribute space when the view is collapsed? BTW I also observe the same in editor groups. https://user-
I've approved the PR. I think the change we have made is a band-aid that helps, but doesn't cut to the root of the problem. I thought through various view/hide scenarios and in each case, I had a different feeling about what I expected to happen with the sizing of the views. IMO, our previous behavior was more correct from the pane view side as an intentional "hide" operation on a view should not redistribute every view in the container. However, the problem here is that there is a problematic extra view that is not controlled by the user. In this case, we are just trying to get sane sizing. If we invest more time in this, I think the fix lives at a higher layer.

return; } <del> this.splitview.removeView(index); </del> <ins> this.splitview.removeView(index, pane.isExpanded() ? Sizing.Distribute : undefined); </ins> const paneItem = this.paneItems.splice(index, 1)[0]; paneItem.disposable.dispose(); }


. $USER_ZDOTDIR/.zshrc ZDOTDIR=$VSCODE_ZDOTDIR fi <ins> if [[ -f $USER_ZDOTDIR/.zsh_history ]]; then HISTFILE=$USER_ZDOTDIR/.zsh_history fi </ins> fi # Shell integration was disabled by the shell, exit without warning assuming either the shell has


Question: Currently says that the coverage folder is generated at the root of the directory. But this isn't currently the case, the coverage folder is generated under the directory instead.

## Coverage <del> The following command will create a `coverage` folder at the root of the workspace: </del> <ins> The following command will create a `coverage` folder in the `.build` folder at the root of the workspace: </ins> **OS X and Linux**


Question:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

import * as vscode from 'vscode'; import { CommandManager } from './commandManager'; import * as commands from './commands/index'; <ins> import { MdDefinitionProvider } from './languageFeatures/definitionProvider'; </ins> import { MdLinkProvider } from './languageFeatures/documentLinkProvider'; import { MdDocumentSymbolProvider } from './languageFeatures/documentSymbolProvider'; import { registerDropIntoEditor } from './languageFeatures/dropIntoEditor';


Question:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

vscode.languages.registerWorkspaceSymbolProvider(new MdWorkspaceSymbolProvider(symbolProvider, workspaceContents)), vscode.languages.registerReferenceProvider(selector, referencesProvider), vscode.languages.registerRenameProvider(selector, new MdRenameProvider(referencesProvider, workspaceContents, githubSlugifier)), <ins> vscode.languages.registerDefinitionProvider(selector, new MdDefinitionProvider(referencesProvider)), </ins> MdPathCompletionProvider.register(selector, engine, linkProvider), registerDropIntoEditor(selector), registerFindFileReferences(commandManager, referencesProvider),


Question:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

commandManager.register(new commands.ReloadPlugins(previewManager, engine)); return commandManager; }


Question:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as vscode from 'vscode'; import { Disposable } from '../util/dispose'; import { SkinnyTextDocument } from '../workspaceContents'; import { MdReferencesProvider } from './references'; export class MdDefinitionProvider extends Disposable implements vscode.DefinitionProvider { constructor(private readonly referencesProvider: MdReferencesProvider) { super(); } async provideDefinition(document: SkinnyTextDocument, position: vscode.Position, token: vscode.CancellationToken): Promise<vscode.Definition | undefined> { const allRefs = await this.referencesProvider.getAllReferencesAtPosition(document, position, token); return allRefs.find(ref => ref.kind === 'link' && ref.isDefinition)?.location; } } </ins>


Question:
Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !

<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import 'mocha'; import * as vscode from 'vscode'; import { MdDefinitionProvider } from '../languageFeatures/definitionProvider'; import { MdLinkProvider } from '../languageFeatures/documentLinkProvider'; import { MdReferencesProvider } from '../languageFeatures/references'; import { githubSlugifier } from '../slugify'; import { InMemoryDocument } from '../util/inMemoryDocument'; import { MdWorkspaceContents } from '../workspaceContents'; import { createNewMarkdownEngine } from './engine'; import { InMemoryWorkspaceMarkdownDocuments } from './inMemoryWorkspace'; import { joinLines, noopToken, workspacePath } from './util'; function getDefinition(doc: InMemoryDocument, pos: vscode.Position, workspaceContents: MdWorkspaceContents) { const engine = createNewMarkdownEngine(); const linkProvider = new MdLinkProvider(engine); const referencesProvider = new MdReferencesProvider(linkProvider, workspaceContents, engine, githubSlugifier); const provider = new MdDefinitionProvider(referencesProvider); return provider.provideDefinition(doc, pos, noopToken); } function assertDefinitionsEqual(actualDef: vscode.Definition, ...expectedDefs: { uri: vscode.Uri; line: number; startCharacter?: number; endCharacter?: number }[]) { const actualDefsArr = Array.isArray(actualDef) ? actualDef : [actualDef]; assert.strictEqual(actualDefsArr.length, expectedDefs.length, `Definition counts should match`); for (let i = 0; i < actualDefsArr.length; ++i) { const actual = actualDefsArr[i]; const expected = expectedDefs[i]; assert.strictEqual(actual.uri.toString(), expected.uri.toString(), `Definition '${i}' has expected document`); assert.strictEqual(actual.range.start.line, expected.line, `Definition '${i}' has expected start line`); assert.strictEqual(actual.range.end.line, expected.line, `Definition '${i}' has expected end line`); if (typeof expected.startCharacter !== 'undefined') { assert.strictEqual(actual.range.start.character, expected.startCharacter, `Definition '${i}' has expected start character`); } if (typeof expected.endCharacter !== 'undefined') { assert.strictEqual(actual.range.end.character, expected.endCharacter, `Definition '${i}' has expected end character`); } } } suite('markdown: Go to definition', () => { test('Should not return definition when on link text', async () => { const doc = new InMemoryDocument(workspacePath('doc.md'), joinLines( `[ref](#abc)`, `[ref]: http://example.com`, )); const defs = await getDefinition(doc, new vscode.Position(0, 1), new InMemoryWorkspaceMarkdownDocuments([doc])); assert.deepStrictEqual(defs, undefined); }); test('Should find definition links within file from link', async () => { const docUri = workspacePath('doc.md'); const doc = new InMemoryDocument(docUri, joinLines( `[link 1][abc]`, // trigger here ``, `[abc]: https://example.com`, )); const defs = await getDefinition(doc, new vscode.Position(0, 12), new InMemoryWorkspaceMarkdownDocuments([doc])); assertDefinitionsEqual(defs!, { uri: docUri, line: 2 }, ); }); test('Should find definition links using shorthand', async () => { const docUri = workspacePath('doc.md'); const doc = new InMemoryDocument(docUri, joinLines( `[ref]`, // trigger 1 ``, `[yes][ref]`, // trigger 2 ``, `[ref]: /Hello.md` // trigger 3 )); { const defs = await getDefinition(doc, new vscode.Position(0, 2), new InMemoryWorkspaceMarkdownDocuments([doc])); assertDefinitionsEqual(defs!, { uri: docUri, line: 4 }, ); } { const defs = await getDefinition(doc, new vscode.Position(2, 7), new InMemoryWorkspaceMarkdownDocuments([doc])); assertDefinitionsEqual(defs!, { uri: docUri, line: 4 }, ); } { const defs = await getDefinition(doc, new vscode.Position(4, 2), new InMemoryWorkspaceMarkdownDocuments([doc])); assertDefinitionsEqual(defs!, { uri: docUri, line: 4 }, ); } }); test('Should find definition links within file from definition', async () => { const docUri = workspacePath('doc.md'); const doc = new InMemoryDocument(docUri, joinLines( `[link 1][abc]`, ``, `[abc]: https://example.com`, // trigger here )); const defs = await getDefinition(doc, new vscode.Position(2, 3), new InMemoryWorkspaceMarkdownDocuments([doc])); assertDefinitionsEqual(defs!, { uri: docUri, line: 2 }, ); }); test('Should not find definition links across files', async () => { const docUri = workspacePath('doc.md'); const doc = new InMemoryDocument(docUri, joinLines( `[link 1][abc]`, ``, `[abc]: https://example.com`, )); const defs = await getDefinition(doc, new vscode.Position(0, 12), new InMemoryWorkspaceMarkdownDocuments([ doc, new InMemoryDocument(workspacePath('other.md'), joinLines( `[link 1][abc]`, ``, `[abc]: https://example.com?bad`, )) ])); assertDefinitionsEqual(defs!, { uri: docUri, line: 2 }, ); }); }); </ins>


Question:
<!-- Do Not Delete This! bugreporttemplate --Version: 1.66.0 (system setup) Commit: Date: 2022-03-30T05:50:14.623Z Electron: 17.2.0 Chromium: 98.0.4758.109 16.13.0 V8: 9.8.177.11-electron.0 OS: Windows_NT x64 10.0. New "striped" gutter decorations were in . These decorations do not respect the existing SCM: Diff Decorations Gutter Width setting: Changing the above setting has no effect on the new decorations.
I think this was an oversight and have a PR that can help address this. Thanks!

private setViewState(state: IViewState): void { this.viewState = state; this.stylesheet.textContent = ` <del> .monaco-editor .dirty-diff-modified,.monaco-editor .dirty-diff-added{border-left-width:${state.width}px;} </del> <ins> .monaco-editor .dirty-diff-modified { background-size: ${state.width}px 4.5px; } .monaco-editor .dirty-diff-modified, .monaco-editor .dirty-diff-added{border-left-width:${state.width}px;} </ins> .monaco-editor .dirty-diff-modified, .monaco-editor .dirty-diff-added, .monaco-editor .dirty-diff-deleted { opacity: ${state.visibility === 'always' ? 1 : 0}; }


Question:
<!-- Do Not Delete This! bugreporttemplate --Version: 1.66.0 (system setup) Commit: Date: 2022-03-30T05:50:14.623Z Electron: 17.2.0 Chromium: 98.0.4758.109 16.13.0 V8: 9.8.177.11-electron.0 OS: Windows_NT x64 10.0. New "striped" gutter decorations were in . These decorations do not respect the existing SCM: Diff Decorations Gutter Width setting: Changing the above setting has no effect on the new decorations.
I think this was an oversight and have a PR that can help address this. Thanks!

if (editorGutterModifiedBackgroundColor) { collector.addRule(` .monaco-editor .dirty-diff-modified { <del> background-size: 3px 4.5px; </del> background-repeat-x: no-repeat; background-image: linear-gradient(${linearGradient}); transition: opacity 0.5s;


Question:
<!-- 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 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:

handleContinuationEnd(): void; handleRightPromptStart(): void; handleRightPromptEnd(): void; <del> handleCommandStart(): void; </del> <ins> handleCommandStart(options?: IHandleCommandStartOptions): void; </ins> handleCommandExecuted(): void; handleCommandFinished(exitCode: number | undefined): void; /**