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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce:
Our C/C++ team has verified that our extension is correctly published to the marketplace with the correct binary -- our guess is that there is some VS Code or marketplace bug that is causing the wrong vsix to sometimes be installed.
Users are able to download/install our vsix manually from or so the bug appears to be with VS Code and/or the Remote WSL extension.
can you reproduce this problem? If yes can you file a new issue with reproducable steps? The issue is not 100% clear to us from this description. Thank you
Our C/C++ team has not been able to reproduce the problem yet. I'm guessing there's some random or unusual requirement, maybe involving a previously cached installation when an upgrade from version 1.9.8 to 1.10.5 of our extension occurs. I'm not familiar with what sort of install logging would be important for users who repro it to get, which is why I was thinking the issue should be tracked by VS Code (or the Remote extension or marketplace) and not our team. I'm aware of 4 user reports -- there could be more reported against VS Code that I'm not aware of. We don't believe our extension's warning about the incorrect binary is the root issue, and just a symptom of some other system downloading the incorrect vsix for the user's OS (we ship 10 different vsix's).
If you can let us know what the remote OS is and what the TargetPlatform property is set to in the file that could help us identify the problem.
yes getting more details here would be helpful. If you get a chance to repro the problem do let us know. Appreciate it!
A user reports that our .vsixmanifest file shows TargetPlatform="win32-x64" on a Linux-x64 remote machine (with Win-x64 host), which indicates that VS Code or the Remote extension or marketplace is somehow causing a download/install of the host platform's vsix instead of the remote one. I'm not familiar with what the next steps are in terms of diagnostics, but it seems like at least there should be an open VS Code (or Remote extension) bug to track this, since currently there are just 4 or so closed issues. See
I'm the reporter of This is not the case for me as I have installed the C/C++ extension for the first time. I don't usually use VS Code but just tried it to reproduce another problem reported by a user. Also, as far as I remember, this is the first time for me to connect to a remote workspace using VS Code. Something that might be related is the version of VS Code. I think I have originally installed VS Code back in October 2021. After that, I hadn't updated the VS Code for a long time because I'm not using it. This time, I think I first tried to install the C/C++ extension with the old version of VS Code and failed. After that, I updated VS Code to the latest version from the main menu of the VS Code, which didn't solve the problem. I'm not sure if this is really related, but is it unsupported to update VS Code from an old version (8-month old) in a single update (i.e., without any intermediate versions)? For example, some migration steps to update the cache or database format would be skipped? We might be able to ask other reporters about their situations? (), (), (this issue): How's the situation? Did you experience the problem in the remote workspace such as in WSL? Have you recently updated VS Code? When have you updated VS Code previously?
I am using the VS code(version 1.67) in Ubuntu 16.04 LTS (64 bit OS) which is hosted VM in Oracle VM virtual box. While trying to install C/C++ extension in the VS code, it was not proceeding and VS code suggested to download it from the website and install it via vsix. So, I have done the same. The installation of extension was successful but later during debugging, it has mentioned that wrong/incompatible binaries. please let me know if anymore information is required.
I was not using remote workspace WSL. I am just trying to use VS code for client side code at my local VM.
cc
Your issue might be different? You installed the Linux x64 vsix, right? What is the TargetPlatform property set to in the .vscode[-insiders]/extensions/ms-vscode.cpptools-[version][os-description]/.vsixmanifest file? It should say "linux-x64". What version of the C/C++ extension are you installing? Our team is able to debug with the Linux x64 vsix so we don't know what could be going wrong yet.
Sorry that I am late to the party. It would be great if I can get summary of the issue? Does it happen to be reproducible?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
I have been thinking that you have checked the linked issues, but let me comment in case you haven't noticed them. I have already described the details about my situation in my initial report If needed, I can just copy and paste the comment to here. Nevertheless, I can answer additional questions about my situation if any. We may also find some information by the OP of this issue in
May I know if you have downloaded the VSIX that is compatible to the platform you are using? !
It's not me. The above comment is from In my case, I initially tried to install the extension from a VS Code client in Win 10 opened for the remote workspace (Ubuntu 20.04 / WSL2), which fails with the message of incompatible binaries. After the suggestion in , I have downloaded the VSIX from and installed it in the remote, which was successful unlike the case of I'm not sure which version has downloaded. !
The problem is, as I have reported in , VS Code seems to wrongly download the VSIX of in Ubuntu 20.04/WSL2 instead of the VSIX of . I have tried several times VS Code's install button with different configurations for both VS Code and VS Code Insiders, but all failed in the same way.
Got it. Thanks for update. Can you please share us with a gif/video of what you are doing so that we can understand more about the issue? Can you please share us with the following logs after reproducing the issue? F1 Open View... Log (Window) F1 Open View... Log (Remote)
I tried to upload it to here but couldn't do it due to the size limit. I have instead uploaded it to YouTube: Log (Window) I cannot find such a view. Instead, I see and : Log (Remote Server) Log (Remote Extension Host)
Which version of VS Code are you using? Instead of downloading from the installed section, can you please try searching for the extension, say by typing c++ in the search input and install? Does it work if you uninstall the extension and install again?
As I have reported in , I have confirmed the behavior in and . Further details are found in As it does not seem to reproduce in every environment, I guess some other factors in my environment causes the problem.
I now noticed these additional comments. I'll try them when I get back home.
This installs the correct version of the extension. What is the correct way to uninstall the extension from the remote? (a) As explained in , I have already tried many times removing the remote extension---by deleting the directory as suggested in ---and installing it again. But they didn't change anything.(b) When I select the C/C++ extension from the installed section and press the [Unintall] button (see below), the remote extension is still located under , but the local extension instead seems to be uninstalled. ! (c) Also, when I type in the search input, select the C/C++ extension, and press the [Uninstall] button (see below), the remote extension is still there, and the local extension is instead uninstalled. !
So it means you are getting incompatible C++ extension when you use the button ? In both above screenshots, pressing Uninstall will uninstall locally as the extension seems to be installed locally. So, please try pressing uninstall button and install the extension again?
Yes. I had already tried that many times. The result doesn't change; It again installs an incompatible version as far as I use the button .
Can you please provide following logs while trying this? Enable log level to trace - F1 Set Log Level Share F1 Open View... Log (Remote) Share F1 Open View... Log (Window)
Here, I attach the logs: This time, (1) I first attempted to install the extension by pressing . (2) Then reopen the extension page, press and reloaded the VS Code. (3) Then, I again attempted to install the extension from the button. In the zip archive, the following files are included: --- This includes the log of in step (1) described above. --- This includes the log of in step (1). --- This includes the log of in step (3). --- This includes the log of in step (3). --- This includes the log of in step (3).
Thanks for the logs and I think I know the root cause of this issue. It seems in your case the extension is being copied from local client (Windows) to remote (WSL) and hence the bits are being incompatible. This happens if VS Code cannot find a matching installed extension in the Marketplace. In this case, VS Code falls back to copy the extension. Fixed it as follows: Before using the fallback to copy Try again to get the matching extension from the Marketplace In the fallback check if the local extension is compatible with the remote platform. This fix does not covers if you have manually installed an extension that does not exist in the Marketplace and is platform specific.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!

@IExtensionsWorkbenchService extensionsWorkbenchService: IExtensionsWorkbenchService, @IExtensionManagementServerService extensionManagementServerService: IExtensionManagementServerService, @IExtensionManifestPropertiesService extensionManifestPropertiesService: IExtensionManifestPropertiesService, <ins> @IExtensionGalleryService extensionGalleryService: IExtensionGalleryService, </ins> ) { <del> super(`extensions.localinstall`, extensionManagementServerService.localExtensionManagementServer, false, extensionsWorkbenchService, extensionManagementServerService, extensionManifestPropertiesService); </del> <ins> super(`extensions.localinstall`, extensionManagementServerService.localExtensionManagementServer, false, extensionsWorkbenchService, extensionManagementServerService, extensionManifestPropertiesService, extensionGalleryService); </ins> } protected getInstallLabel(): string {


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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce:
Our C/C++ team has verified that our extension is correctly published to the marketplace with the correct binary -- our guess is that there is some VS Code or marketplace bug that is causing the wrong vsix to sometimes be installed.
Users are able to download/install our vsix manually from or so the bug appears to be with VS Code and/or the Remote WSL extension.
can you reproduce this problem? If yes can you file a new issue with reproducable steps? The issue is not 100% clear to us from this description. Thank you
Our C/C++ team has not been able to reproduce the problem yet. I'm guessing there's some random or unusual requirement, maybe involving a previously cached installation when an upgrade from version 1.9.8 to 1.10.5 of our extension occurs. I'm not familiar with what sort of install logging would be important for users who repro it to get, which is why I was thinking the issue should be tracked by VS Code (or the Remote extension or marketplace) and not our team. I'm aware of 4 user reports -- there could be more reported against VS Code that I'm not aware of. We don't believe our extension's warning about the incorrect binary is the root issue, and just a symptom of some other system downloading the incorrect vsix for the user's OS (we ship 10 different vsix's).
If you can let us know what the remote OS is and what the TargetPlatform property is set to in the file that could help us identify the problem.
yes getting more details here would be helpful. If you get a chance to repro the problem do let us know. Appreciate it!
A user reports that our .vsixmanifest file shows TargetPlatform="win32-x64" on a Linux-x64 remote machine (with Win-x64 host), which indicates that VS Code or the Remote extension or marketplace is somehow causing a download/install of the host platform's vsix instead of the remote one. I'm not familiar with what the next steps are in terms of diagnostics, but it seems like at least there should be an open VS Code (or Remote extension) bug to track this, since currently there are just 4 or so closed issues. See
I'm the reporter of This is not the case for me as I have installed the C/C++ extension for the first time. I don't usually use VS Code but just tried it to reproduce another problem reported by a user. Also, as far as I remember, this is the first time for me to connect to a remote workspace using VS Code. Something that might be related is the version of VS Code. I think I have originally installed VS Code back in October 2021. After that, I hadn't updated the VS Code for a long time because I'm not using it. This time, I think I first tried to install the C/C++ extension with the old version of VS Code and failed. After that, I updated VS Code to the latest version from the main menu of the VS Code, which didn't solve the problem. I'm not sure if this is really related, but is it unsupported to update VS Code from an old version (8-month old) in a single update (i.e., without any intermediate versions)? For example, some migration steps to update the cache or database format would be skipped? We might be able to ask other reporters about their situations? (), (), (this issue): How's the situation? Did you experience the problem in the remote workspace such as in WSL? Have you recently updated VS Code? When have you updated VS Code previously?
I am using the VS code(version 1.67) in Ubuntu 16.04 LTS (64 bit OS) which is hosted VM in Oracle VM virtual box. While trying to install C/C++ extension in the VS code, it was not proceeding and VS code suggested to download it from the website and install it via vsix. So, I have done the same. The installation of extension was successful but later during debugging, it has mentioned that wrong/incompatible binaries. please let me know if anymore information is required.
I was not using remote workspace WSL. I am just trying to use VS code for client side code at my local VM.
cc
Your issue might be different? You installed the Linux x64 vsix, right? What is the TargetPlatform property set to in the .vscode[-insiders]/extensions/ms-vscode.cpptools-[version][os-description]/.vsixmanifest file? It should say "linux-x64". What version of the C/C++ extension are you installing? Our team is able to debug with the Linux x64 vsix so we don't know what could be going wrong yet.
Sorry that I am late to the party. It would be great if I can get summary of the issue? Does it happen to be reproducible?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
I have been thinking that you have checked the linked issues, but let me comment in case you haven't noticed them. I have already described the details about my situation in my initial report If needed, I can just copy and paste the comment to here. Nevertheless, I can answer additional questions about my situation if any. We may also find some information by the OP of this issue in
May I know if you have downloaded the VSIX that is compatible to the platform you are using? !
It's not me. The above comment is from In my case, I initially tried to install the extension from a VS Code client in Win 10 opened for the remote workspace (Ubuntu 20.04 / WSL2), which fails with the message of incompatible binaries. After the suggestion in , I have downloaded the VSIX from and installed it in the remote, which was successful unlike the case of I'm not sure which version has downloaded. !
The problem is, as I have reported in , VS Code seems to wrongly download the VSIX of in Ubuntu 20.04/WSL2 instead of the VSIX of . I have tried several times VS Code's install button with different configurations for both VS Code and VS Code Insiders, but all failed in the same way.
Got it. Thanks for update. Can you please share us with a gif/video of what you are doing so that we can understand more about the issue? Can you please share us with the following logs after reproducing the issue? F1 Open View... Log (Window) F1 Open View... Log (Remote)
I tried to upload it to here but couldn't do it due to the size limit. I have instead uploaded it to YouTube: Log (Window) I cannot find such a view. Instead, I see and : Log (Remote Server) Log (Remote Extension Host)
Which version of VS Code are you using? Instead of downloading from the installed section, can you please try searching for the extension, say by typing c++ in the search input and install? Does it work if you uninstall the extension and install again?
As I have reported in , I have confirmed the behavior in and . Further details are found in As it does not seem to reproduce in every environment, I guess some other factors in my environment causes the problem.
I now noticed these additional comments. I'll try them when I get back home.
This installs the correct version of the extension. What is the correct way to uninstall the extension from the remote? (a) As explained in , I have already tried many times removing the remote extension---by deleting the directory as suggested in ---and installing it again. But they didn't change anything.(b) When I select the C/C++ extension from the installed section and press the [Unintall] button (see below), the remote extension is still located under , but the local extension instead seems to be uninstalled. ! (c) Also, when I type in the search input, select the C/C++ extension, and press the [Uninstall] button (see below), the remote extension is still there, and the local extension is instead uninstalled. !
So it means you are getting incompatible C++ extension when you use the button ? In both above screenshots, pressing Uninstall will uninstall locally as the extension seems to be installed locally. So, please try pressing uninstall button and install the extension again?
Yes. I had already tried that many times. The result doesn't change; It again installs an incompatible version as far as I use the button .
Can you please provide following logs while trying this? Enable log level to trace - F1 Set Log Level Share F1 Open View... Log (Remote) Share F1 Open View... Log (Window)
Here, I attach the logs: This time, (1) I first attempted to install the extension by pressing . (2) Then reopen the extension page, press and reloaded the VS Code. (3) Then, I again attempted to install the extension from the button. In the zip archive, the following files are included: --- This includes the log of in step (1) described above. --- This includes the log of in step (1). --- This includes the log of in step (3). --- This includes the log of in step (3). --- This includes the log of in step (3).
Thanks for the logs and I think I know the root cause of this issue. It seems in your case the extension is being copied from local client (Windows) to remote (WSL) and hence the bits are being incompatible. This happens if VS Code cannot find a matching installed extension in the Marketplace. In this case, VS Code falls back to copy the extension. Fixed it as follows: Before using the fallback to copy Try again to get the matching extension from the Marketplace In the fallback check if the local extension is compatible with the remote platform. This fix does not covers if you have manually installed an extension that does not exist in the Marketplace and is platform specific.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!

@IExtensionsWorkbenchService extensionsWorkbenchService: IExtensionsWorkbenchService, @IExtensionManagementServerService extensionManagementServerService: IExtensionManagementServerService, @IExtensionManifestPropertiesService extensionManifestPropertiesService: IExtensionManifestPropertiesService, <ins> @IExtensionGalleryService extensionGalleryService: IExtensionGalleryService, </ins> ) { <del> super(`extensions.webInstall`, extensionManagementServerService.webExtensionManagementServer, false, extensionsWorkbenchService, extensionManagementServerService, extensionManifestPropertiesService); </del> <ins> super(`extensions.webInstall`, extensionManagementServerService.webExtensionManagementServer, false, extensionsWorkbenchService, extensionManagementServerService, extensionManifestPropertiesService, extensionGalleryService); </ins> } protected getInstallLabel(): string {


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.68.0 OS Version: Win10 21H1 .1706 Steps to Reproduce: ! This is caused by When L122 , the element may have been created in the tree before. Thus, may be more than once and causes icon style conflict. ! A PR will be linked. Idea from After fix: !

renderElement(node: ITreeNode<Call, FuzzyScore>, _index: number, template: CallRenderingTemplate): void { const { element, filterData } = node; const deprecated = element.item.tags?.includes(SymbolTag.Deprecated); <ins> template.icon.className = ''; </ins> template.icon.classList.add('inline', ...CSSIcon.asClassNameArray(SymbolKinds.toIcon(element.item.kind))); template.label.setLabel( element.item.name,


Question:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !

comment: ['The task command line or label'] }, 'Executing task: {0}', commandLine), { excludeLeadingNewLine: true }) + taskShellIntegrationOutputSequence; } <ins> } else { shellLaunchConfig.initialText = taskShellIntegrationStartSequence + taskShellIntegrationOutputSequence; </ins> } } else { const commandExecutable = (task.command.runtime !== RuntimeType.CustomExecution) ? CommandString.value(command) : undefined;


Question:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !

comment: ['The task command line or label'] }, 'Executing task: {0}', `${shellLaunchConfig.executable} ${getArgsToEcho(shellLaunchConfig.args)}`), { excludeLeadingNewLine: true }) + taskShellIntegrationOutputSequence; } <ins> } else { shellLaunchConfig.initialText = taskShellIntegrationStartSequence + taskShellIntegrationOutputSequence; </ins> } }


Question:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !

/** * A string including ANSI escape sequences that will be written to the terminal emulator <del> * _before_ the terminal process has launched, a trailing n is added at the end of the string. * This allows for example the terminal instance to display a styled message as the first line * of the terminal. Use x1b over 033 or e for the escape control character. </del> <ins> * _before_ the terminal process has launched, when a string is specified, a trailing n is * added at the end. This allows for example the terminal instance to display a styled message * as the first line of the terminal. Use x1b over 033 or e for the escape control character. </ins> */ <del> initialText?: string; </del> <ins> initialText?: string | { text: string; trailingNewLine: boolean }; </ins> /** * Custom PTY/pseudoterminal process to use.


Question:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !

executableEnv, options }; <del> const persistentProcess = new PersistentTerminalProcess(id, process, workspaceId, workspaceName, shouldPersist, cols, rows, processLaunchOptions, unicodeVersion, this._reconnectConstants, this._logService, isReviving ? shellLaunchConfig.initialText : undefined, rawReviveBuffer, shellLaunchConfig.icon, shellLaunchConfig.color, shellLaunchConfig.name, shellLaunchConfig.fixedDimensions); </del> <ins> const persistentProcess = new PersistentTerminalProcess(id, process, workspaceId, workspaceName, shouldPersist, cols, rows, processLaunchOptions, unicodeVersion, this._reconnectConstants, this._logService, isReviving && typeof shellLaunchConfig.initialText === 'string' ? shellLaunchConfig.initialText : undefined, rawReviveBuffer, shellLaunchConfig.icon, shellLaunchConfig.color, shellLaunchConfig.name, shellLaunchConfig.fixedDimensions); </ins> process.onDidChangeProperty(property => this._onDidChangeProperty.fire({ id, property })); process.onProcessExit(event => { persistentProcess.dispose();


Question:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !

}, 'Executing task: {0}', commandLine), { excludeLeadingNewLine: true }) + this.taskShellIntegrationOutputSequence; } } else { <del> shellLaunchConfig.initialText = this.taskShellIntegrationStartSequence + this.taskShellIntegrationOutputSequence; </del> <ins> shellLaunchConfig.initialText = { text: this.taskShellIntegrationStartSequence + this.taskShellIntegrationOutputSequence, trailingNewLine: false }; </ins> } } else { const commandExecutable = (task.command.runtime !== RuntimeType.CustomExecution) ? CommandString.value(command) : undefined;


Question:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !

}, 'Executing task: {0}', `${shellLaunchConfig.executable} ${getArgsToEcho(shellLaunchConfig.args)}`), { excludeLeadingNewLine: true }) + this.taskShellIntegrationOutputSequence; } } else { <del> shellLaunchConfig.initialText = this.taskShellIntegrationStartSequence + this.taskShellIntegrationOutputSequence; </del> <ins> shellLaunchConfig.initialText = { text: this.taskShellIntegrationStartSequence + this.taskShellIntegrationOutputSequence, trailingNewLine: false }; </ins> } }


Question:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !

// Write initial text, deferring onLineFeed listener when applicable to avoid firing // onLineData events containing initialText if (this._shellLaunchConfig.initialText) { <del> this.xterm.raw.writeln(this._shellLaunchConfig.initialText, () => { </del> <ins> this._writeInitialText(this.xterm, () => { </ins> lineDataEventAddon.onLineData(e => this._onLineData.fire(e)); }); } else {


Question:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !

} } <ins> private _writeInitialText(xterm: XtermTerminal, callback?: () => void): void { if (!this._shellLaunchConfig.initialText) { callback?.(); return; } const text = typeof this._shellLaunchConfig.initialText === 'string' ? this._shellLaunchConfig.initialText : this._shellLaunchConfig.initialText?.text; if (typeof this._shellLaunchConfig.initialText === 'string') { xterm.raw.writeln(text, callback); } else { if (this._shellLaunchConfig.initialText.trailingNewLine) { xterm.raw.writeln(text, callback); } else { xterm.raw.write(text, callback); } } } </ins> async reuseTerminal(shell: IShellLaunchConfig, reset: boolean = false): Promise<void> { // Unsubscribe any key listener we may have. this._pressAnyKeyToCloseListener?.dispose(); this._pressAnyKeyToCloseListener = undefined; <del> if (this.xterm) { </del> <ins> const xterm = this.xterm; if (xterm) { </ins> if (!reset) { // Ensure new processes' output starts at start of new line <del> await new Promise<void>(r => this.xterm!.raw.write('nx1b[G', r)); </del> <ins> await new Promise<void>(r => xterm.raw.write('nx1b[G', r)); </ins> } // Print initialText if specified if (shell.initialText) { <del> await new Promise<void>(r => this.xterm!.raw.writeln(shell.initialText!, r)); </del> <ins> await new Promise<void>(r => this._writeInitialText(xterm, r)); </ins> } // Clean up waitOnExit state if (this._isExiting && this._shellLaunchConfig.waitOnExit) { <del> this.xterm.raw.options.disableStdin = false; </del> <ins> xterm.raw.options.disableStdin = false; </ins> this._isExiting = false; } if (reset) { <del> this.xterm.clearDecorations(); </del> <ins> xterm.clearDecorations(); </ins> } }


Question:
Issue Type: <bBug</bWhen I drill down into the git menu and choose the option to , I really don't need the same confirmation dialog as when I just hit the top-level check mark in the source control pane. The dialog tells me ; this is an incorrect warning at this stage, since I clearly invoked it by choosing . I certainly don't want to choose the option in response to this warning, since it's a good warning to have when I accidentally hit the checkmark without staging any changes. VS Code version: Code 1.67.0 (, 2022-05-04T12:14:47.100Z) OS version: Darwin x64 19.6.0 Restricted Mode: No <!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

private async smartCommit( repository: Repository, getCommitMessage: () => Promise<string | undefined>, <del> opts?: CommitOptions </del> <ins> opts: CommitOptions </ins> ): Promise<boolean> { const config = workspace.getConfiguration('git', Uri.file(repository.root)); let promptToSaveFilesBeforeCommit = config.get<'always' | 'staged' | 'never'>('promptToSaveFilesBeforeCommit');


Question:
Issue Type: <bBug</bWhen I drill down into the git menu and choose the option to , I really don't need the same confirmation dialog as when I just hit the top-level check mark in the source control pane. The dialog tells me ; this is an incorrect warning at this stage, since I clearly invoked it by choosing . I certainly don't want to choose the option in response to this warning, since it's a good warning to have when I accidentally hit the checkmark without staging any changes. VS Code version: Code 1.67.0 (, 2022-05-04T12:14:47.100Z) OS version: Darwin x64 19.6.0 Restricted Mode: No <!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

} } <del> if (!opts) { opts = { all: noStagedChanges }; } else if (!opts.all && noStagedChanges && !opts.empty) { opts = { ...opts, all: true }; } </del> // no changes, and the user has not configured to commit all in this case <del> if (!noUnstagedChanges && noStagedChanges && !enableSmartCommit && !opts.empty) { </del> <ins> if (!noUnstagedChanges && noStagedChanges && !enableSmartCommit && !opts.empty && !opts.all) { </ins> const suggestSmartCommit = config.get<boolean>('suggestSmartCommit') === true; if (!suggestSmartCommit) {


Question:
Issue Type: <bBug</bWhen I drill down into the git menu and choose the option to , I really don't need the same confirmation dialog as when I just hit the top-level check mark in the source control pane. The dialog tells me ; this is an incorrect warning at this stage, since I clearly invoked it by choosing . I certainly don't want to choose the option in response to this warning, since it's a good warning to have when I accidentally hit the checkmark without staging any changes. VS Code version: Code 1.67.0 (, 2022-05-04T12:14:47.100Z) OS version: Darwin x64 19.6.0 Restricted Mode: No <!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

} } <ins> if (opts.all === undefined) { opts = { all: noStagedChanges }; } else if (!opts.all && noStagedChanges && !opts.empty) { opts = { ...opts, all: true }; } </ins> // enable signing of commits if configured opts.signCommit = enableCommitSigning;


Question:
Issue Type: <bBug</bWhen I drill down into the git menu and choose the option to , I really don't need the same confirmation dialog as when I just hit the top-level check mark in the source control pane. The dialog tells me ; this is an incorrect warning at this stage, since I clearly invoked it by choosing . I certainly don't want to choose the option in response to this warning, since it's a good warning to have when I accidentally hit the checkmark without staging any changes. VS Code version: Code 1.67.0 (, 2022-05-04T12:14:47.100Z) OS version: Darwin x64 19.6.0 Restricted Mode: No <!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

return true; } <del> private async commitWithAnyInput(repository: Repository, opts?: CommitOptions): Promise<void> { </del> <ins> private async commitWithAnyInput(repository: Repository, opts: CommitOptions): Promise<void> { </ins> const message = repository.inputBox.value; const root = Uri.file(repository.root); const config = workspace.getConfiguration('git', root);


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.68.1 OS Version: Windows 10 Steps to Reproduce: When I open a terminal in VSCode the following warning is logged within a few seconds: . I take note of that this issue is not a duplicate of.
A warning as in on the window output channel or devtools console? Do you use powerlevel10k or another complex prompt by chance?
It's in the devtools console. Not using any complex prompt. Just plain CMD.
Oh OK, that's unexpected if it's cmd, thanks for the info
we should probably do something like here

import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; import { ITerminalCommand, TerminalCapability } from 'vs/platform/terminal/common/capabilities/capabilities'; import { TerminalCapabilityStoreMultiplexer } from 'vs/platform/terminal/common/capabilities/terminalCapabilityStore'; <del> import { IProcessDataEvent, IProcessPropertyMap, IShellLaunchConfig, ITerminalDimensionsOverride, ITerminalLaunchError, ProcessPropertyType, TerminalIcon, TerminalLocation, TerminalSettingId, TerminalShellType, TitleEventSource, WindowsShellType } from 'vs/platform/terminal/common/terminal'; </del> <ins> import { IProcessDataEvent, IProcessPropertyMap, IShellLaunchConfig, ITerminalDimensionsOverride, ITerminalLaunchError, PosixShellType, ProcessPropertyType, TerminalIcon, TerminalLocation, TerminalSettingId, TerminalShellType, TitleEventSource, WindowsShellType } from 'vs/platform/terminal/common/terminal'; </ins> import { escapeNonWindowsPath } from 'vs/platform/terminal/common/terminalEnvironment'; import { activeContrastBorder, scrollbarSliderActiveBackground, scrollbarSliderBackground, scrollbarSliderHoverBackground } from 'vs/platform/theme/common/colorRegistry'; import { IColorTheme, ICssStyleCollector, IThemeService, registerThemingParticipant, ThemeIcon } from 'vs/platform/theme/common/themeService';


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.68.1 OS Version: Windows 10 Steps to Reproduce: When I open a terminal in VSCode the following warning is logged within a few seconds: . I take note of that this issue is not a duplicate of.
A warning as in on the window output channel or devtools console? Do you use powerlevel10k or another complex prompt by chance?
It's in the devtools console. Not using any complex prompt. Just plain CMD.
Oh OK, that's unexpected if it's cmd, thanks for the info
we should probably do something like here

rows: number; } <ins> const shellIntegrationSupportedShellTypes = [PosixShellType.Bash, PosixShellType.Zsh, PosixShellType.PowerShell, WindowsShellType.PowerShell]; </ins> const scrollbarHeight = 5; class TerminalOutputProvider implements ITextModelContentProvider {


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.68.1 OS Version: Windows 10 Steps to Reproduce: When I open a terminal in VSCode the following warning is logged within a few seconds: . I take note of that this issue is not a duplicate of.
A warning as in on the window output channel or devtools console? Do you use powerlevel10k or another complex prompt by chance?
It's in the devtools console. Not using any complex prompt. Just plain CMD.
Oh OK, that's unexpected if it's cmd, thanks for the info
we should probably do something like here

} get disableShellIntegrationReporting(): boolean { if (this._disableShellIntegrationReporting === undefined) { <del> this._disableShellIntegrationReporting = this.shellLaunchConfig.isFeatureTerminal || this.shellLaunchConfig.hideFromUser || this.shellLaunchConfig.executable === undefined; </del> <ins> this._disableShellIntegrationReporting = (this.shellLaunchConfig.hideFromUser || this.shellLaunchConfig.executable === undefined || this.shellType === undefined) || !shellIntegrationSupportedShellTypes.includes(this.shellType); </ins> } return this._disableShellIntegrationReporting; }


Question:
Issue Type: <bBug</bAfter upgrading to 1.68, text selection in the integrated terminal does not show selected text. This is purely a visual glitch, as I can still copy what I had selected on the terminal. My colleague has the same version but does not have this issue, so I'm wondering if it's an issue introduced through my update. VS Code version: Code 1.68.1 (, 2022-06-14T12:48:58.283Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ project-manager12.6.0 github-markdown-preview0.3.0 markdown-checkbox0.3.2 markdown-emoji0.2.1 markdown-footnotes0.0.7 markdown-mermaid1.14.0 markdown-preview-github-styles1.0.1 markdown-yaml-preamble0.1.0 keymapceditor-vsc0.7.7 gitignore0.7.0 doxdocgen1.4.0 transformer1.12.1 git-extension-pack0.1.3 githistory0.6.19 gitlens12.1.1 EditorConfig0.16.4 align-mode0.0.21 better-cpp-syntax1.15.18 cmake-language-support-vscode0.0.4 theme-karyfoundation-themes26.2.1 vscode-docker1.22.0 vscode-dotnet-runtime1.5.0 python2022.8.0 vscode-pylance2022.6.20 jupyter2022.5. jupyter-keymap1.0.0 jupyter-renderers1.0.8 remote-containers0.238.2 remote-ssh0.82.1 remote-ssh-edit0.80.0 remote-wsl0.66.3 vscode-remote-extensionpack0.21.0 cmake-tools1.11.26 cpptools1.10.7 cpptools-extension-pack1.2.0 makefile-tools0.5.0 indent-rainbow8.3.1 vscode-pbtxt0.0.4 cmake0.0.17 vim1.22.2 clang-format1.9.0 vscode-open-in-github1.3.6 (5 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Same issue, I'm using theme. When I switch to a different theme the selection is visible. Looks like a theme issue.
Can you reproduce the issue in Insider's? I see selection in Insider's when using solarized light, but it does seem pretty light !
I believe we're implementing solarized light correctly here and that's how it's meant to work. If you're not a fan of the low contrast selection you can change it with this setting: Otherwise change to a theme that you prefer. Let me know if I misunderstood and the selection is actually not visible (not just subtle).
I was using the theme for a while and I was used to the low contrast on selection. It was quite ok on my screen TBH. Now there's no visible selection. Here I've selected "Counting objects". I've actually pasted it from the terminal instead of typing to be sure. ! I don't think this issue is ready for closing.
Do you have any settings set and does changing help?
I strive to work on defaults. No settings in Setting to true causes selected letters to become slightly lighter, but no background. "si" selected ! Not sure if it has anything to do with it, but the issue seems to have started after the recent update (via PPA on an ubuntu flavor). After updating I didn't restart immediately, but attempted to open an image and everything crashed. Restarted after that and noticed selection not working a bit later.
Some more things to try: Does closing all windows and running fix it? If not, can you share your full file? Running the Generate color theme from current settings command will let us see if there's something weird going on with the theme
Confirming this is only happening in Solarized Light
Disabling GPU doesn't help <details</summary{ "window.menuBarVisibility": "toggle", "editor.minimap.enabled": false, "[javascript]": { "editor.defaultFormatter": "vscode.typescript-language-features" }, "javascript.updateImportsOnFileMove.enabled": "always", "[json]": { "editor.defaultFormatter": "" }, "[typescript]": { "editor.defaultFormatter": "vscode.typescript-language-features" }, "": "stuff=", "explorer.confirmDelete": false, "explorer.confirmDragAndDrop": false, "[html]": { "editor.defaultFormatter": "" }, "[jsonc]": { "editor.defaultFormatter": "" }, "workbench.colorTheme": "Solarized Light", "editor.inlineSuggest.enabled": true, "editor.renderWhitespace": "none", "[css]": { "editor.defaultFormatter": "esbenp.prettier-vscode" } } </details<details<summarycolor theme from current settings</summary</details
I can't reproduce based on those settings so I'm a bit stumped on what to do with this one
So I checked the terminal background on the screenshot and it's which is exactly the same color as the default selection color. the dump I pasted above had in it, which seems odd. But since you didn't raise it, I'm assuming it's supposed to mean the actual background is the one of the panel inside which the terminal is working. What I also noticed about the terminal panel is it's no longer giving me the option to move it to the bottom of the window, which is odd, but most of all when I right-click, it no longer says "move terminal right" as an option, but "move sidebar". I checked, and means I will no longer see my selection. Conclusion is what ends up being the color behind terminal text. The theme should probably set terminal background or change the selection color as a fix. I wonder what else breaks because terminal is now a sidebar not something else.
Ah ok, thanks for looking into it. Because of this, setting the terminal background explicitly is a good solution for now. I doubt it happens in many other themes since contrast is usually pretty high but I'll check Solarized Dark as well when fixing.

"terminal.ansiBrightMagenta": "#6c71c4", "terminal.ansiBrightCyan": "#93a1a1", "terminal.ansiBrightWhite": "#fdf6e3", <ins> // Set terminal background explicitly, otherwise selection becomes invisible when the // terminal is in the side bar "terminal.background": "#FDF6E3", </ins> // Interactive Playground "walkThrough.embeddedEditorBackground": "#00000014" },


Question:
Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-22T05:17:09.661Z Electron: 18.3.4 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0. This is a follow up of Steps to Reproduce: the dnd sample: to the of some logs in : the extension multiple files to the dnd sample view, the uris in the data transfer are not split by line separators. // cc
Are you dragging from the VS Code file explorer view, or your operating system's file explorer?
Sorry forgot to mention, it's from VS Code file explorer
Can you check the actual value, not just the value printed by I debugged this and oddly while just prints: The actual value of is: In this case each file name is separated by a pair
Tested in: Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-23T05:16:43.681Z Electron: 18.3.4 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0. It's still stored in one line: https://user- Is there anything I missed?
Thanks. Only happens on windows for me. Taking a look now
I don't see us setting anywhere and suspect chrome is generating it automatically. See in for how this may happen Also we are possibly hitting
Nice find. I couldn't find us setting anywhere either.
Verified on Windows and Linux in 1.69.0-insider (user setup) Commit: , 022-07-01T05:17:04.343Z

DataTransfers.RESOURCES, ]); <del> export function addExternalEditorsDropData(dataTransfer: VSDataTransfer, dragEvent: DragEvent) { if (dragEvent.dataTransfer && !dataTransfer.has(Mimes.uriList)) { </del> <ins> export function addExternalEditorsDropData(dataTransfer: VSDataTransfer, dragEvent: DragEvent, overwriteUriList = false) { if (dragEvent.dataTransfer && (overwriteUriList || !dataTransfer.has(Mimes.uriList))) { </ins> const editorData = extractEditorsDropData(dragEvent) .filter(input => input.resource) .map(input => input.resource!.toString());


Question:
Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-22T05:17:09.661Z Electron: 18.3.4 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0. This is a follow up of Steps to Reproduce: the dnd sample: to the of some logs in : the extension multiple files to the dnd sample view, the uris in the data transfer are not split by line separators. // cc
Are you dragging from the VS Code file explorer view, or your operating system's file explorer?
Sorry forgot to mention, it's from VS Code file explorer
Can you check the actual value, not just the value printed by I debugged this and oddly while just prints: The actual value of is: In this case each file name is separated by a pair
Tested in: Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-23T05:16:43.681Z Electron: 18.3.4 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0. It's still stored in one line: https://user- Is there anything I missed?
Thanks. Only happens on windows for me. Taking a look now
I don't see us setting anywhere and suspect chrome is generating it automatically. See in for how this may happen Also we are possibly hitting
Nice find. I couldn't find us setting anywhere either.
Verified on Windows and Linux in 1.69.0-insider (user setup) Commit: , 022-07-01T05:17:04.343Z

} const originalDataTransfer = toVSDataTransfer(originalEvent.dataTransfer); <del> addExternalEditorsDropData(originalDataTransfer, originalEvent); </del> <ins> addExternalEditorsDropData(originalDataTransfer, originalEvent, true); </ins> const outDataTransfer = new VSDataTransfer(); for (const [type, item] of originalDataTransfer.entries()) {


Question:
I think we should understand why execution time seems to get slower and slower the more cells there are. Check out this video, it looks as if things get slower and slower: ! Originally posted by in
This test is running the "Run All" command, not the "run one cell" command...

return notebook.cellAt(notebook.cellCount - 1); } <del> async function addCellAndRun(code: string, notebook: vscode.NotebookDocument) { </del> <ins> async function addCellAndRun(code: string, notebook: vscode.NotebookDocument, i: number) { </ins> const cell = await addCell(code, notebook); <del> await vscode.commands.executeCommand('notebook.execute'); </del> <ins> await vscode.commands.executeCommand('notebook.cell.execute', { start: i, end: i + 1 }); </ins> assert.strictEqual(cell.outputs.length, 1, 'execute failed'); return cell; }


Question:
I think we should understand why execution time seems to get slower and slower the more cells there are. Check out this video, it looks as if things get slower and slower: ! Originally posted by in
This test is running the "Run All" command, not the "run one cell" command...

// Run and add a bunch of cells for (let i = 0; i < 10; i++) { <del> await addCellAndRun(`print ${i}`, notebookEditor.notebook); </del> <ins> await addCellAndRun(`print ${i}`, notebookEditor.notebook, i); </ins> } // Verify visible range has the last cell


Question:
! Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-23T05:16:43.681Z Electron: 18.3.4 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.
It's actually allowed to have no scope (for the default fore/background), but the schema is too strict

} }, required: [ <del> 'settings', 'scope' </del> <ins> 'settings' </ins> ], additionalProperties: false }


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

} update(mode: OutputChannelUpdateMode, till?: number): void { <del> this.model.update(mode, till); </del> <ins> this.model.update(mode, till, true); </ins> } clear(): void {


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

export interface IOutputChannelModel extends IDisposable { readonly onDispose: Event<void>; append(output: string): void; <del> update(mode: OutputChannelUpdateMode, till?: number): void; </del> <ins> update(mode: OutputChannelUpdateMode, till: number | undefined, immediate: boolean): void; </ins> loadModel(): Promise<ITextModel>; clear(): void; replace(value: string): void;


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

} clear(): void { <del> this.update(OutputChannelUpdateMode.Clear, this.endOffset); </del> <ins> this.update(OutputChannelUpdateMode.Clear, this.endOffset, true); </ins> } <del> update(mode: OutputChannelUpdateMode, till?: number): void { </del> <ins> update(mode: OutputChannelUpdateMode, till: number | undefined, immediate: boolean): void { </ins> const loadModelPromise: Promise<any> = this.loadModelPromise ? this.loadModelPromise : Promise.resolve(); <del> loadModelPromise.then(() => this.doUpdate(mode, till)); </del> <ins> loadModelPromise.then(() => this.doUpdate(mode, till, immediate)); </ins> } loadModel(): Promise<ITextModel> {


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

return this.model; } <del> private doUpdate(mode: OutputChannelUpdateMode, till?: number): void { </del> <ins> private doUpdate(mode: OutputChannelUpdateMode, till: number | undefined, immediate: boolean): void { </ins> if (mode === OutputChannelUpdateMode.Clear || mode === OutputChannelUpdateMode.Replace) { this.startOffset = this.endOffset = isNumber(till) ? till : this.endOffset; this.cancelModelUpdate();


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

} else { <del> this.appendContent(this.model, token); </del> <ins> this.appendContent(this.model, immediate, token); </ins> } }


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

this.doUpdateModel(model, [EditOperation.delete(model.getFullModelRange())], VSBuffer.fromString('')); } <del> private async appendContent(model: ITextModel, token: CancellationToken): Promise<void> { </del> <ins> private async appendContent(model: ITextModel, immediate: boolean, token: CancellationToken): Promise<void> { </ins> this.appendThrottler.trigger(async () => { /* Abort if operation is cancelled */ if (token.isCancellationRequested) {


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

const lastLineMaxColumn = model.getLineMaxColumn(lastLine); const edits = [EditOperation.insert(new Position(lastLine, lastLineMaxColumn), contentToAppend.toString())]; this.doUpdateModel(model, edits, contentToAppend); <del> }); </del> <ins> }, immediate ? 0 : undefined); </ins> } private async replaceContent(model: ITextModel, token: CancellationToken): Promise<void> {


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

if (!this.modelUpdateInProgress) { if (isNumber(size) && this.endOffset > size) { // Reset - Content is removed <del> this.update(OutputChannelUpdateMode.Clear, 0); </del> <ins> this.update(OutputChannelUpdateMode.Clear, 0, true); </ins> } } <del> this.update(OutputChannelUpdateMode.Append); </del> <ins> this.update(OutputChannelUpdateMode.Append, undefined, false /* Not needed to update immediately. Wait to collect more changes and update. */); </ins> } }


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

override append(message: string): void { this.write(message); <del> this.update(OutputChannelUpdateMode.Append); </del> <ins> this.update(OutputChannelUpdateMode.Append, undefined, this.isVisible()); </ins> } override replace(message: string): void { const till = this._offset; this.write(message); <del> this.update(OutputChannelUpdateMode.Replace, till); </del> <ins> this.update(OutputChannelUpdateMode.Replace, till, true); </ins> } private write(content: string): void {


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?: No (the issue is produced using CMake Tools extension) <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.

this.outputChannelModel.then(outputChannelModel => outputChannelModel.append(output)); } <del> update(mode: OutputChannelUpdateMode, till?: number): void { this.outputChannelModel.then(outputChannelModel => outputChannelModel.update(mode, till)); </del> <ins> update(mode: OutputChannelUpdateMode, till: number | undefined, immediate: boolean): void { this.outputChannelModel.then(outputChannelModel => outputChannelModel.update(mode, till, immediate)); </ins> } loadModel(): Promise<ITextModel> {


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

if (uri === undefined) { return; } // Run the store action to get back a ref <del> const ref = await that.storeEditSession(); </del> <ins> const ref = await that.storeEditSession(false); </ins> // Append the ref to the URI if (ref !== undefined) {


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

await that.progressService.withProgress({ location: ProgressLocation.Notification, title: localize('storing edit session', 'Storing edit session...') <del> }, async () => await that.storeEditSession()); </del> <ins> }, async () => await that.storeEditSession(true)); </ins> } })); }


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

} } <del> async storeEditSession(): Promise<string | undefined> { </del> <ins> async storeEditSession(fromStoreCommand: boolean): Promise<string | undefined> { </ins> const folders: Folder[] = []; <ins> let hasEdits = false; </ins> for (const repository of this.scmService.repositories) { // Look through all resource groups and compute which files were added/modified/deleted


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

} } catch { } <ins> hasEdits = true; </ins> if (await this.fileService.exists(uri)) { workingChanges.push({ type: ChangeType.Addition, fileType: FileType.File, contents: (await this.fileService.readFile(uri)).value.toString(), relativeFilePath: relativeFilePath }); } else {


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

folders.push({ workingChanges, name: name ?? '' }); } <ins> if (!hasEdits) { this.logService.info('Edit Sessions: Skipping storing edit session as there are no edits to store.'); if (fromStoreCommand) { this.notificationService.info(localize('no edits to store', 'Skipped storing edit session as there are no edits to store.')); } return undefined; } </ins> const data: EditSession = { folders, version: 1 }; try {


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

let instantiationService: TestInstantiationService; let sessionSyncContribution: SessionSyncContribution; let fileService: FileService; <ins> let sandbox: sinon.SinonSandbox; </ins> const disposables = new DisposableStore(); <del> setup(() => { </del> <ins> suiteSetup(() => { sandbox = sinon.createSandbox(); </ins> instantiationService = new TestInstantiationService(); // Set up filesystem


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

} }); <ins> // Stub repositories instantiationService.stub(ISCMService, '_repositories', new Map()); </ins> sessionSyncContribution = instantiationService.createInstance(SessionSyncContribution); });


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

}; // Stub sync service to return edit session data <del> const sandbox = sinon.createSandbox(); </del> const readStub = sandbox.stub().returns({ editSession, ref: '0' }); instantiationService.stub(ISessionSyncWorkbenchService, 'read', readStub); <del> // Stub repositories instantiationService.stub(ISCMService, '_repositories', new Map()); </del> // Create root folder await fileService.createFolder(folderUri);


Question: Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.

// Verify edit session was correctly applied assert.equal((await fileService.readFile(fileUri)).value.toString(), fileContents); }); <ins> test('Edit session not stored if there are no edits', async function () { const writeStub = sandbox.stub(); instantiationService.stub(ISessionSyncWorkbenchService, 'write', writeStub); // Create root folder await fileService.createFolder(folderUri); await sessionSyncContribution.storeEditSession(true); // Verify that we did not attempt to write the edit session assert.equal(writeStub.called, false); }); </ins> });


Question:
Testing Have one profile with GitLens installed and other without. Notice how walkthrough shows up in Welcome page on profile without GitLens <img width="1653" alt="image" src="https://user-"
It seems welcome page is not updating when extensions are removed. This has to be fixed in walk throughs / welcome page component. Not sure who owns this now. Can you please assign it to the corresponding owner?
It appears we are handling it correctly here
I see is being invoked for gitlens extension when switching profiles, but I do not know why the walk through page is still showing it. I do not know the implementation of it. Can you please investigate from walk through component perspective first to see why it is still being shown?
I disabled gitlens and used the button to reload the window. The walkthrough is no longer there. is that expected?
!
I changed profiles to the one with Gitlens still enabled and there's still no walkthrough
Hmmm I cannot repro this. Can you provide a gif? If I have the walkthrough open and reload my window the walkthrough page doesn't dissapear
https://user-

} extension.contributes?.walkthroughs?.forEach(section => { <del> const categoryID = extension.identifier.value + '#walkthrough#' + section.id; </del> <ins> const categoryID = extension.identifier.value + '#' + section.id; </ins> section.steps.forEach(step => { const fullyQualifiedID = extension.identifier.value + '#' + section.id + '#' + step.id; this.steps.delete(fullyQualifiedID);


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.0 OS Version: iOS 14.3 Steps to Reproduce: Safari on iOS 14.3 to any vscode server (e.g. , or ) The Safari developer tools console shows the following error:
. I see references to in the following commits: (soft reference) Thoughts?
As this has been supported since iOS 15, do we want to change this?
The changes introduced in completely break vs code for all devices below iOS/iPadOS 15, the other occurrences of don't seem to have any negative impact according to my testing (anything below 1.66.0 works). The fix I proposed in is a more elegant solution that supports all browsers and does not break anything.
We are generally only aiming for latest and greatest browser version. The use of seems small enough to justify a special case but we shouldn't target a lower version nor is there any guarantee that other things won't break, e.g "fixing" this might just reveal another bunch of blocker etc pp.
Sounds good, forwarding to to evaluate the PR.

* @returns whether the provided parameter is of type `Buffer` or Uint8Array dervived type */ export function isTypedArray(obj: unknown): obj is Object { <ins> const TypedArray = Object.getPrototypeOf(Uint8Array); </ins> return typeof obj === 'object' <del> && (obj instanceof Uint8Array || obj instanceof Uint16Array || obj instanceof Uint32Array || obj instanceof Float32Array || obj instanceof Float64Array || obj instanceof Int8Array || obj instanceof Int16Array || obj instanceof Int32Array || obj instanceof BigInt64Array || obj instanceof BigUint64Array || obj instanceof Uint8ClampedArray); </del> <ins> && obj instanceof TypedArray; </ins> } /**