Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --So, this issue is here for a long time in vscode, i've just noticed another issue with it. Basically, vsCode shows incorrect icons, see on the screensot: ! You see that it shows react icon for babel js and simple js icon for react js. I actually know that it may be better to use .jsx files for react project, but is there any way to fix this? and also Is there a way to automaticaly recognize whether the file is for react or simple javascript(by detecting import/require export/module.exports statements or smth else)?? This is the main question for the issue. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.1(Latest) OS Version: Windows 10 2004 Steps to Reproduce: on the language selector in right bottom corner. in Javascript. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes, and it also shows more incorrect variant. !
Maybe it is the issue with the icon pack extensions that I use, so if needed i'll provide my extensions list.
I don't see this in 1.48.1 ! Can you try without custom extensions? (close all windows and run code --disable-extensions`)
i've already mentioned in my post that i tried without extensions and provided a screenshot. It shows react icon for both js and react js. UPDATE: to be honest, I've just tried again with all windows closed and nothing changed. same result
I think you have the following setting configured. Is that correct?
Yep, you are right. Should i remove that setting entirely or change it? Also the main question was: can VSCode automatically detect whether js file is for react or vanilla js? UPDATE: I removed that setting and now it shows js icon for reactjs ! However, if I select react js the file icon becomes correct) !
It's a bug in the language selection dialog. For getting the langauge icon, we use the icon of the first file extension. In your case that file extension has be reassigned to a different language. I create a PR.
Great, good luck and notify me if some actions from my side will be needed)
I pushed a fix. You can already try it out in our insiders build or in the next stable release.
I am not sure this is fixed, what are the steps? I configured my settings as outlined. I see this: !
The screenshot looks correct. In the language selector, the entry has the correct JS icon. Verification steps: Seti theme add to settings:open a js file, verify it has the react icon open the language mode quick pick, filter for verify that JavaScript shows the JS icon and the JavaScript React the react icon
great, i'll check it in nearest stable update)
Ok, but the main reason I started this issue is if vscode can automatically detect reactjs files and set the propper icon. So please, tell me if I need to start a new issue or if there is a solution for this "problem"
Yes, a new issue is needed. That said, it's a difficult request as language detection has to be very efficient as there can be hundreds of files visible in a view. Analyzing the content and even parsing it or resolving imports would be very expensive. Fee free to file the issue anyways, but I don't think we can do it.

} // Compute mode <ins> let currentLanguageId: string | undefined; </ins> let currentModeId: string | undefined; <del> let modeId: string | undefined; </del> if (textModel) { <del> modeId = textModel.getLanguageIdentifier().language; currentModeId = withNullAsUndefined(this.modeService.getLanguageName(modeId)); </del> <ins> currentModeId = textModel.getLanguageIdentifier().language; currentLanguageId = withNullAsUndefined(this.modeService.getLanguageName(currentModeId)); </ins> } // All languages are valid picks const languages = this.modeService.getRegisteredLanguageNames(); const picks: QuickPickInput[] = languages.sort().map((lang, index) => { <ins> const modeId = this.modeService.getModeIdForLanguageName(lang.toLowerCase()) || 'unknown'; </ins> let description: string; <del> if (currentModeId === lang) { description = nls.localize('languageDescription', "({0}) - Configured Language", this.modeService.getModeIdForLanguageName(lang.toLowerCase())); </del> <ins> if (currentLanguageId === lang) { description = nls.localize('languageDescription', "({0}) - Configured Language", modeId); </ins> } else { <del> description = nls.localize('languageDescriptionConfigured', "({0})", this.modeService.getModeIdForLanguageName(lang.toLowerCase())); </del> <ins> description = nls.localize('languageDescriptionConfigured', "({0})", modeId); </ins> } return { label: lang, <del> iconClasses: getIconClasses(this.modelService, this.modeService, this.getFakeResource(lang)), </del> <ins> iconClasses: getIconClassesForModeId(modeId), </ins> description }; });


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --So, this issue is here for a long time in vscode, i've just noticed another issue with it. Basically, vsCode shows incorrect icons, see on the screensot: ! You see that it shows react icon for babel js and simple js icon for react js. I actually know that it may be better to use .jsx files for react project, but is there any way to fix this? and also Is there a way to automaticaly recognize whether the file is for react or simple javascript(by detecting import/require export/module.exports statements or smth else)?? This is the main question for the issue. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.1(Latest) OS Version: Windows 10 2004 Steps to Reproduce: on the language selector in right bottom corner. in Javascript. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes, and it also shows more incorrect variant. !
Maybe it is the issue with the icon pack extensions that I use, so if needed i'll provide my extensions list.
I don't see this in 1.48.1 ! Can you try without custom extensions? (close all windows and run code --disable-extensions`)
i've already mentioned in my post that i tried without extensions and provided a screenshot. It shows react icon for both js and react js. UPDATE: to be honest, I've just tried again with all windows closed and nothing changed. same result
I think you have the following setting configured. Is that correct?
Yep, you are right. Should i remove that setting entirely or change it? Also the main question was: can VSCode automatically detect whether js file is for react or vanilla js? UPDATE: I removed that setting and now it shows js icon for reactjs ! However, if I select react js the file icon becomes correct) !
It's a bug in the language selection dialog. For getting the langauge icon, we use the icon of the first file extension. In your case that file extension has be reassigned to a different language. I create a PR.
Great, good luck and notify me if some actions from my side will be needed)
I pushed a fix. You can already try it out in our insiders build or in the next stable release.
I am not sure this is fixed, what are the steps? I configured my settings as outlined. I see this: !
The screenshot looks correct. In the language selector, the entry has the correct JS icon. Verification steps: Seti theme add to settings:open a js file, verify it has the react icon open the language mode quick pick, filter for verify that JavaScript shows the JS icon and the JavaScript React the react icon
great, i'll check it in nearest stable update)
Ok, but the main reason I started this issue is if vscode can automatically detect reactjs files and set the propper icon. So please, tell me if I need to start a new issue or if there is a solution for this "problem"
Yes, a new issue is needed. That said, it's a difficult request as language detection has to be very efficient as there can be hundreds of files visible in a view. Analyzing the content and even parsing it or resolving imports would be very expensive. Fee free to file the issue anyways, but I don't think we can do it.

picks.unshift(galleryAction); } <del> configureModeSettings = { label: nls.localize('configureModeSettings', "Configure '{0}' language based settings...", currentModeId) }; </del> <ins> configureModeSettings = { label: nls.localize('configureModeSettings', "Configure '{0}' language based settings...", currentLanguageId) }; </ins> picks.unshift(configureModeSettings); configureModeAssociations = { label: nls.localize('configureAssociationsExt', "Configure File Association for '{0}'...", ext) }; picks.unshift(configureModeAssociations);


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --So, this issue is here for a long time in vscode, i've just noticed another issue with it. Basically, vsCode shows incorrect icons, see on the screensot: ! You see that it shows react icon for babel js and simple js icon for react js. I actually know that it may be better to use .jsx files for react project, but is there any way to fix this? and also Is there a way to automaticaly recognize whether the file is for react or simple javascript(by detecting import/require export/module.exports statements or smth else)?? This is the main question for the issue. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.1(Latest) OS Version: Windows 10 2004 Steps to Reproduce: on the language selector in right bottom corner. in Javascript. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes, and it also shows more incorrect variant. !
Maybe it is the issue with the icon pack extensions that I use, so if needed i'll provide my extensions list.
I don't see this in 1.48.1 ! Can you try without custom extensions? (close all windows and run code --disable-extensions`)
i've already mentioned in my post that i tried without extensions and provided a screenshot. It shows react icon for both js and react js. UPDATE: to be honest, I've just tried again with all windows closed and nothing changed. same result
I think you have the following setting configured. Is that correct?
Yep, you are right. Should i remove that setting entirely or change it? Also the main question was: can VSCode automatically detect whether js file is for react or vanilla js? UPDATE: I removed that setting and now it shows js icon for reactjs ! However, if I select react js the file icon becomes correct) !
It's a bug in the language selection dialog. For getting the langauge icon, we use the icon of the first file extension. In your case that file extension has be reassigned to a different language. I create a PR.
Great, good luck and notify me if some actions from my side will be needed)
I pushed a fix. You can already try it out in our insiders build or in the next stable release.
I am not sure this is fixed, what are the steps? I configured my settings as outlined. I see this: !
The screenshot looks correct. In the language selector, the entry has the correct JS icon. Verification steps: Seti theme add to settings:open a js file, verify it has the react icon open the language mode quick pick, filter for verify that JavaScript shows the JS icon and the JavaScript React the react icon
great, i'll check it in nearest stable update)
Ok, but the main reason I started this issue is if vscode can automatically detect reactjs files and set the propper icon. So please, tell me if I need to start a new issue or if there is a solution for this "problem"
Yes, a new issue is needed. That said, it's a difficult request as language detection has to be very efficient as there can be hundreds of files visible in a view. Analyzing the content and even parsing it or resolving imports would be very expensive. Fee free to file the issue anyways, but I don't think we can do it.

// User decided to configure settings for current language if (pick === configureModeSettings) { <del> this.preferencesService.openGlobalSettings(true, { editSetting: `[${withUndefinedAsNull(modeId)}]` }); </del> <ins> this.preferencesService.openGlobalSettings(true, { editSetting: `[${withUndefinedAsNull(currentModeId)}]` }); </ins> return; }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --So, this issue is here for a long time in vscode, i've just noticed another issue with it. Basically, vsCode shows incorrect icons, see on the screensot: ! You see that it shows react icon for babel js and simple js icon for react js. I actually know that it may be better to use .jsx files for react project, but is there any way to fix this? and also Is there a way to automaticaly recognize whether the file is for react or simple javascript(by detecting import/require export/module.exports statements or smth else)?? This is the main question for the issue. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.1(Latest) OS Version: Windows 10 2004 Steps to Reproduce: on the language selector in right bottom corner. in Javascript. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes, and it also shows more incorrect variant. !
Maybe it is the issue with the icon pack extensions that I use, so if needed i'll provide my extensions list.
I don't see this in 1.48.1 ! Can you try without custom extensions? (close all windows and run code --disable-extensions`)
i've already mentioned in my post that i tried without extensions and provided a screenshot. It shows react icon for both js and react js. UPDATE: to be honest, I've just tried again with all windows closed and nothing changed. same result
I think you have the following setting configured. Is that correct?
Yep, you are right. Should i remove that setting entirely or change it? Also the main question was: can VSCode automatically detect whether js file is for react or vanilla js? UPDATE: I removed that setting and now it shows js icon for reactjs ! However, if I select react js the file icon becomes correct) !
It's a bug in the language selection dialog. For getting the langauge icon, we use the icon of the first file extension. In your case that file extension has be reassigned to a different language. I create a PR.
Great, good luck and notify me if some actions from my side will be needed)
I pushed a fix. You can already try it out in our insiders build or in the next stable release.
I am not sure this is fixed, what are the steps? I configured my settings as outlined. I see this: !
The screenshot looks correct. In the language selector, the entry has the correct JS icon. Verification steps: Seti theme add to settings:open a js file, verify it has the react icon open the language mode quick pick, filter for verify that JavaScript shows the JS icon and the JavaScript React the react icon
great, i'll check it in nearest stable update)
Ok, but the main reason I started this issue is if vscode can automatically detect reactjs files and set the propper icon. So please, tell me if I need to start a new issue or if there is a solution for this "problem"
Yes, a new issue is needed. That said, it's a difficult request as language detection has to be very efficient as there can be hundreds of files visible in a view. Analyzing the content and even parsing it or resolving imports would be very expensive. Fee free to file the issue anyways, but I don't think we can do it.

const languages = this.modeService.getRegisteredLanguageNames(); const picks: IQuickPickItem[] = languages.sort().map((lang, index) => { <del> const id = withNullAsUndefined(this.modeService.getModeIdForLanguageName(lang.toLowerCase())); </del> <ins> const id = withNullAsUndefined(this.modeService.getModeIdForLanguageName(lang.toLowerCase())) || 'unknown'; </ins> return { id, label: lang, <del> iconClasses: getIconClasses(this.modelService, this.modeService, this.getFakeResource(lang)), </del> <ins> iconClasses: getIconClassesForModeId(id), </ins> description: (id === currentAssociation) ? nls.localize('currentAssociation', "Current Association") : undefined }; });


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --So, this issue is here for a long time in vscode, i've just noticed another issue with it. Basically, vsCode shows incorrect icons, see on the screensot: ! You see that it shows react icon for babel js and simple js icon for react js. I actually know that it may be better to use .jsx files for react project, but is there any way to fix this? and also Is there a way to automaticaly recognize whether the file is for react or simple javascript(by detecting import/require export/module.exports statements or smth else)?? This is the main question for the issue. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.48.1(Latest) OS Version: Windows 10 2004 Steps to Reproduce: on the language selector in right bottom corner. in Javascript. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes, and it also shows more incorrect variant. !
Maybe it is the issue with the icon pack extensions that I use, so if needed i'll provide my extensions list.
I don't see this in 1.48.1 ! Can you try without custom extensions? (close all windows and run code --disable-extensions`)
i've already mentioned in my post that i tried without extensions and provided a screenshot. It shows react icon for both js and react js. UPDATE: to be honest, I've just tried again with all windows closed and nothing changed. same result
I think you have the following setting configured. Is that correct?
Yep, you are right. Should i remove that setting entirely or change it? Also the main question was: can VSCode automatically detect whether js file is for react or vanilla js? UPDATE: I removed that setting and now it shows js icon for reactjs ! However, if I select react js the file icon becomes correct) !
It's a bug in the language selection dialog. For getting the langauge icon, we use the icon of the first file extension. In your case that file extension has be reassigned to a different language. I create a PR.
Great, good luck and notify me if some actions from my side will be needed)
I pushed a fix. You can already try it out in our insiders build or in the next stable release.
I am not sure this is fixed, what are the steps? I configured my settings as outlined. I see this: !
The screenshot looks correct. In the language selector, the entry has the correct JS icon. Verification steps: Seti theme add to settings:open a js file, verify it has the react icon open the language mode quick pick, filter for verify that JavaScript shows the JS icon and the JavaScript React the react icon
great, i'll check it in nearest stable update)
Ok, but the main reason I started this issue is if vscode can automatically detect reactjs files and set the propper icon. So please, tell me if I need to start a new issue or if there is a solution for this "problem"
Yes, a new issue is needed. That said, it's a difficult request as language detection has to be very efficient as there can be hundreds of files visible in a view. Analyzing the content and even parsing it or resolving imports would be very expensive. Fee free to file the issue anyways, but I don't think we can do it.

} }, 50 /* quick input is sensitive to being opened so soon after another */); } <del> private getFakeResource(lang: string): URI | undefined { let fakeResource: URI | undefined; const extensions = this.modeService.getExtensions(lang); if (extensions?.length) { fakeResource = URI.file(extensions[0]); } else { const filenames = this.modeService.getFilenames(lang); if (filenames?.length) { fakeResource = URI.file(filenames[0]); } } return fakeResource; } </del> } export interface IChangeEOLEntry extends IQuickPickItem {


Question: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Since you can have multiple s in a project, it would be great if vscode would be able to detect them and apply the right Language Mode (Groovy). The feature is essentially the same how vscode handles s.

"languages": [{ "id": "groovy", "aliases": ["Groovy", "groovy"], <del> "extensions": [".groovy", ".gvy", ".gradle"], "filenames": [ "Jenkinsfile" ], </del> <ins> "extensions": [".groovy", ".gvy", ".gradle", ".jenkinsfile"], "filenamePatterns": ["Jenkinsfile.*"], </ins> "firstLine": "^#!.*bgroovyb", "configuration": "./language-configuration.json" }],


Question: Issue Type: <bBug</bsomething like Gentoo Linux VSCode in terminal get something like Possible fix: Don't hardcode the path to these :^) VS Code version: Code 1.49.1 (, 2020-09-16T23:23:33.049Z) OS version: Linux x64 5.8.8-gentoo <details<summarySystem Info</summary </details<details<summaryExtensions (6)</summaryExtensionVersion ------ gitlens10.2.2 cpptools1.0.0 vsliveshare1.0.2740 LiveServer5.6.1 vscodeintellicode1.2.10 vscode-icons11.0.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --

*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { exec } from 'child_process'; import { isWindows } from 'vs/base/common/platform'; const cmdline = { windows: 'getmac.exe', unix: '/sbin/ifconfig -a || /sbin/ip link' }; </del> <ins> import { networkInterfaces } from 'os'; </ins> const invalidMacAddresses = new Set([ '00:00:00:00:00:00',


Question: Issue Type: <bBug</bsomething like Gentoo Linux VSCode in terminal get something like Possible fix: Don't hardcode the path to these :^) VS Code version: Code 1.49.1 (, 2020-09-16T23:23:33.049Z) OS version: Linux x64 5.8.8-gentoo <details<summarySystem Info</summary </details<details<summaryExtensions (6)</summaryExtensionVersion ------ gitlens10.2.2 cpptools1.0.0 vsliveshare1.0.2740 LiveServer5.6.1 vscodeintellicode1.2.10 vscode-icons11.0.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --

function doGetMac(): Promise<string> { return new Promise((resolve, reject) => { try { <del> exec(isWindows ? cmdline.windows : cmdline.unix, { timeout: 10000 }, (err, stdout, stdin) => { if (err) { return reject(`Unable to retrieve mac address (${err.toString()})`); } else { const regex = /(?:[a-fd]{2}[:-]){5}[a-fd]{2}/gi; let match; while ((match = regex.exec(stdout)) !== null) { const macAddressCandidate = match[0]; if (validateMacAddress(macAddressCandidate)) { return resolve(macAddressCandidate); } </del> <ins> const ifaces = networkInterfaces(); for (const [, infos] of Object.entries(ifaces)) { for (const info of infos) { if (validateMacAddress(info.mac)) { return resolve(info.mac); </ins> } <del> return reject('Unable to retrieve mac address (unexpected format)'); </del> } <del> }); </del> <ins> } reject('Unable to retrieve mac address (unexpected format)'); </ins> } catch (err) { reject(err); }


Question:
When executing search from extension api 2 checkboxes are not exposed: Preserve Case Use Exclude Settings and Ignore Files !
Hey , Can you please explain a little more about the issue?
It's possible to trigger a search from extension by using this api: And it has a good amount of options: But 2 of them are missing:
Thank got the idea. I will raise a PR to fix the issue ASAP :)
I have raised the . If you get time please review :)
genuinely didn't notice the existing PR, apologies
Thanks :). No problem
It great now that it's possible to control it but why does it called ? Would it possible to have the same name as in label:
Updated to as per suggestion and for consistency with search editor post . Also these to the keybindings intellisense registry.

export interface IFindInFilesArgs { query?: string; replace?: string; <ins> preserveCase?: boolean; </ins> triggerSearch?: boolean; filesToInclude?: string; filesToExclude?: string; isRegex?: boolean; isCaseSensitive?: boolean; matchWholeWord?: boolean; <ins> excludeSettingAndIgnoreFiles?: boolean; </ins> } export const FindInFilesCommand: ICommandHandler = (accessor, args: IFindInFilesArgs = {}) => {


Question:
When executing search from extension api 2 checkboxes are not exposed: Preserve Case Use Exclude Settings and Ignore Files !
Hey , Can you please explain a little more about the issue?
It's possible to trigger a search from extension by using this api: And it has a good amount of options: But 2 of them are missing:
Thank got the idea. I will raise a PR to fix the issue ASAP :)
I have raised the . If you get time please review :)
genuinely didn't notice the existing PR, apologies
Thanks :). No problem
It great now that it's possible to control it but why does it called ? Would it possible to have the same name as in label:
Updated to as per suggestion and for consistency with search editor post . Also these to the keybindings intellisense registry.

if (typeof args.triggerSearch === 'boolean' && args.triggerSearch) { this.triggerQueryChange(); } <ins> if (typeof args.preserveCase === 'boolean') { this.searchWidget.replaceInput.setPreserveCase(args.preserveCase); } if (typeof args.excludeSettingAndIgnoreFiles === 'boolean') { this.inputPatternExcludes.setUseExcludesAndIgnoreFiles(args.excludeSettingAndIgnoreFiles); } </ins> } toggleQueryDetails(moveFocus = true, show?: boolean, skipLayout?: boolean, reverse?: boolean): void {


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --Version: 1.50.0-insider Commit: Date: 2020-09-18T05:28:58.063Z Browser: Mozilla/5.0 (Linux; Android 10; Surface Duo) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.116 Mobile Safari/537.36 EdgA/45.09.62.5078 Steps to Reproduce: Codespaces in a browser on Android (for me, I used Surface Duo) in the editor and hit key In the editor pane you expect it to delete the last character Instead, it does nothing. Here the input: ! NOTE: This appears to be a Monaco bug as the samples on the Monaco website have the same problem. In the terminal you expect it to delete the last character on the prompt I typed "asdf" and then backspace rather than doing nothing or deleting anything... It adds an extra "asd" to my prompt (so I now have "asdfasd"). Then I hit backspace again... It adds "as" to my prompt (so I now have "asdfasdas")... Backspace again adds an "a" (so now "asdfasdasa".... Backspace again and this time it does nothing.... Backspace one more time and it actually starts working. Here's the input next to codespaces: ! I've seen very similar behavior in Azure Cloud Shell in the Azure Mobile App so I have a feeling the terminal bug is in Feel free to reach out if you want me to give something a try! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No
This is probably because you're using an on screen keyboard. It's probably a tricky problem for the terminal which is why hasn't been solved yet.
I believe it's tricky :/ one clarification, I also tried using a bluetooth keyboard and got the same result.
Forgot that we already had an old issue in Monaco-editor and
UPDATE: I switched to GBoard from SwiftKey to see if that has any change (SwiftKey is the default installed keyboard because Microsoft :) ) and GBoard actually WORKS... both in the terminal and in the editor... The only thing that didn't work in my minimal testing was backspace on an empty line did not delete the line.
Wow that's great to hear, that there may be a temporary working solution with alternative keyboards. However I wanted to add that for me, connecting a physical keyboard via USB, with an adapter, was working perfectly (since the virtual keyboard doesn't appear and, I guess, is not used at all).
The editor should now work fine via
nice! When might I be able to give this a spin?
With the next insiders or right now if you can run from master on your device. I hope things will work with a real device, I have been using an Android emulator to implement this...
I no longer have this phone to try this out :(
This could have also improved with

|| (keyCode === KeyCode.End) || (keyCode === KeyCode.PageDown) || (keyCode === KeyCode.PageUp) <ins> || (keyCode === KeyCode.Backspace) </ins> ) { // "Dispatch" on keyCode for these key codes to workaround issues with remote desktoping software // where the scan codes appear to be incorrect (see https://github.com/microsoft/vscode/issues/24107)


Question:
1) install the Remote-SSH and the Codespaces extension 2) Open the remote explorer 3) Select SSH Targets 3) Grab the SSH Targets view and drag it onto the activity bar -the drop down still shows both entries but without any view -the dropped view only shows SSH Targets (as expected) and so there is no way to get to Codespaces anymore 4) Use the SSH Targets view and move it back into the Remote Explorer -two views, one of them a zombie
Looks like somehow the remote explorer got enable for moving views again...

containerIcon: icon || viewContainer?.icon, containerTitle: item.contextualTitle || viewContainer?.name, canToggleVisibility: true, <del> canMoveView: true, </del> <ins> canMoveView: viewContainer?.id !== REMOTE, </ins> treeView: type === ViewType.Tree ? this.instantiationService.createInstance(CustomTreeView, item.id, item.name) : undefined, collapsed: this.showCollapsed(container) || initialVisibility === InitialVisibility.Collapsed, order: order,


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The UI allows us to click-set a breakpoint and then do "Edit Breakpoint" and set Expression, Hit Count or Log Message at any point before or during a debug session. However, not all debug adapters support these features. As soon as the debug adapter runs and capabilities are received on initialization, it should be clear if these will actually be supported. Before the debug session starts, I can hover over the breakpoint and see its details. ! Once debug session starts, breakpoint gets an exclamation point in the middle of it. At first, I thought that meant that the breakpoint was special - i.e. had conditions, but now I am realizing that it means the breakpoint has a problem. If I stop on entry and hover over the breakpoint or if I hover over it while the program is running, I do see "Breakpoints of this type are not supported by the debugger". I can no longer see all of the conditions on hover that I could see before the session started. The error message does not make it clear which of the features are not supported. That would be quite helpful as the debuggers might support different subsets. ! If the debug session hits the breakpoint, then none of the hovers are available anymore for any breakpoint, hit or not. At first I thought this was the only available behavior (see first version of this bug), not realizing that I could get more info if hovering in other conditions. It would be great if the same available information was displayed no matter when you hover over a breakpoint. ! It would also be great if the unsupported options could be disabled in the UI as unavailable while the debug adapter is running.
What you are saying makes sense, however before a user starts debugging there is no debug adapter so we can not disalow setting log points function breakpoint etc even if they will not be supported - we do not know. Yes we could disable some functionality while the debug adapter is running. For that I have decided to leave this issue open and assing to the backlog so we potentially tackle this in the future.
To clarify my original request: I am not asking for any modification before the DA runs. I understand that it is impossible and tried to make that clear in the first paragraph of my original post. I do think that it is important to make this clear after the DA runs. Disabling functionality for new breakpoints is the the last suggestion I made and would be a cherry on top. Please do take a look at my thoughts in the middle of my original report. Depending on where you are in the program, you might or might not get a hover error message "Breakpoints of this type are not supported by the debugger", but even when you do (not always), it doesn't list any of the details. Is it the hit count that is not supported? The expression? Both? There is no way to tell.
Agree. We should improve this.
I will fix this I don't want to do this, since the fact that one debug type is running does not mean that the user doesn't want other debuggers to be run as well.

if (breakpoint.logMessage || breakpoint.condition || breakpoint.hitCondition) { const messages: string[] = []; <ins> let icon = breakpoint.logMessage ? icons.logBreakpoint.regular : icons.conditionalBreakpoint.regular; </ins> if (!breakpoint.supported) { <del> return { icon: icons.debugBreakpointUnsupported, message: localize('breakpointUnsupported', "Breakpoints of this type are not supported by the debugger"), }; </del> <ins> icon = icons.debugBreakpointUnsupported; messages.push(localize('breakpointUnsupported', "Breakpoints of this type are not supported by the debugger")); </ins> } if (breakpoint.logMessage) {


Question:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The UI allows us to click-set a breakpoint and then do "Edit Breakpoint" and set Expression, Hit Count or Log Message at any point before or during a debug session. However, not all debug adapters support these features. As soon as the debug adapter runs and capabilities are received on initialization, it should be clear if these will actually be supported. Before the debug session starts, I can hover over the breakpoint and see its details. ! Once debug session starts, breakpoint gets an exclamation point in the middle of it. At first, I thought that meant that the breakpoint was special - i.e. had conditions, but now I am realizing that it means the breakpoint has a problem. If I stop on entry and hover over the breakpoint or if I hover over it while the program is running, I do see "Breakpoints of this type are not supported by the debugger". I can no longer see all of the conditions on hover that I could see before the session started. The error message does not make it clear which of the features are not supported. That would be quite helpful as the debuggers might support different subsets. ! If the debug session hits the breakpoint, then none of the hovers are available anymore for any breakpoint, hit or not. At first I thought this was the only available behavior (see first version of this bug), not realizing that I could get more info if hovering in other conditions. It would be great if the same available information was displayed no matter when you hover over a breakpoint. ! It would also be great if the unsupported options could be disabled in the UI as unavailable while the debug adapter is running.
What you are saying makes sense, however before a user starts debugging there is no debug adapter so we can not disalow setting log points function breakpoint etc even if they will not be supported - we do not know. Yes we could disable some functionality while the debug adapter is running. For that I have decided to leave this issue open and assing to the backlog so we potentially tackle this in the future.
To clarify my original request: I am not asking for any modification before the DA runs. I understand that it is impossible and tried to make that clear in the first paragraph of my original post. I do think that it is important to make this clear after the DA runs. Disabling functionality for new breakpoints is the the last suggestion I made and would be a cherry on top. Please do take a look at my thoughts in the middle of my original report. Depending on where you are in the program, you might or might not get a hover error message "Breakpoints of this type are not supported by the debugger", but even when you do (not always), it doesn't list any of the details. Is it the hit count that is not supported? The expression? Both? There is no way to tell.
Agree. We should improve this.
I will fix this I don't want to do this, since the fact that one debug type is running does not mean that the user doesn't want other debuggers to be run as well.

} return { <del> icon: breakpoint.logMessage ? icons.logBreakpoint.regular : icons.conditionalBreakpoint.regular, </del> <ins> icon, </ins> message: appendMessage(messages.join('n')) }; }


Question:
Connect a mac-windows SSH remote Open terminal See this popup ! So fails here because it checks ".PATH" on the environment when this is actually "Path" on windows. has special behavior where it resolves property accesses in a case-insensitive way on Windows. We changed many accesses from using to a constructed environment object, and need the same behavior there.
is this a mac-specific issue or are there steps to repro/verify on Windows?
Can't be verified on windows. Thanks

return result; } <ins> export function getCaseInsensitive(target: obj, key: string): any { const lowercaseKey = key.toLowerCase(); const equivalentKey = Object.keys(target).find(k => k.toLowerCase() === lowercaseKey); return equivalentKey ? target[equivalentKey] : target[key]; } </ins>


Question:
Connect a mac-windows SSH remote Open terminal See this popup ! So fails here because it checks ".PATH" on the environment when this is actually "Path" on windows. has special behavior where it resolves property accesses in a case-insensitive way on Windows. We changed many accesses from using to a constructed environment object, and need the same behavior there.
is this a mac-specific issue or are there steps to repro/verify on Windows?
Can't be verified on windows. Thanks

diff = objects.distinct(base, obj); assert.deepEqual(diff, obj); }); <del> }); </del>  No newline at end of file <ins> test('getCaseInsensitive', () => { const obj1 = { lowercase: 123, mIxEdCaSe: 456 }; assert.equal(obj1.lowercase, objects.getCaseInsensitive(obj1, 'lowercase')); assert.equal(obj1.lowercase, objects.getCaseInsensitive(obj1, 'lOwErCaSe')); assert.equal(obj1.mIxEdCaSe, objects.getCaseInsensitive(obj1, 'MIXEDCASE')); assert.equal(obj1.mIxEdCaSe, objects.getCaseInsensitive(obj1, 'mixedcase')); }); }); </ins>


Question:
Connect a mac-windows SSH remote Open terminal See this popup ! So fails here because it checks ".PATH" on the environment when this is actually "Path" on windows. has special behavior where it resolves property accesses in a case-insensitive way on Windows. We changed many accesses from using to a constructed environment object, and need the same behavior there.
is this a mac-specific issue or are there steps to repro/verify on Windows?
Can't be verified on windows. Thanks

import { readFile, exists } from 'vs/base/node/pfs'; import * as path from 'vs/base/common/path'; import { isString } from 'vs/base/common/types'; <ins> import { getCaseInsensitive } from 'vs/base/common/objects'; </ins> let mainProcessParentEnv: IProcessEnvironment | undefined;


Question:
Connect a mac-windows SSH remote Open terminal See this popup ! So fails here because it checks ".PATH" on the environment when this is actually "Path" on windows. has special behavior where it resolves property accesses in a case-insensitive way on Windows. We changed many accesses from using to a constructed environment object, and need the same behavior there.
is this a mac-specific issue or are there steps to repro/verify on Windows?
Can't be verified on windows. Thanks

const fullPath = path.join(cwd, command); return await exists(fullPath) ? fullPath : undefined; } <del> if (paths === undefined && isString(env.PATH)) { paths = env.PATH.split(path.delimiter); </del> <ins> const envPath = getCaseInsensitive(env, 'PATH'); if (paths === undefined && isString(envPath)) { paths = envPath.split(path.delimiter); </ins> } // No PATH environment. Make path absolute to the cwd. if (paths === undefined || paths.length === 0) {


Question: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.50.1 OS Version: Steps to Reproduce: vscode/extensions/theme-tomorrow-night- that wrong value for themeLabel is given ("Quiet Light" instead of "Tomorrow Night Blue") <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Incorrect value "Quiet Light" commited in

{ "displayName": "Tomorrow Night Blue Theme", "description": "Tomorrow night blue theme for Visual Studio Code", <del> "themeLabel": "Quiet Light" </del> <ins> "themeLabel": "Tomorrow Night Blue" </ins> }


Question:
Testing Unfiltered notebook noob feedback: ! I was expecting a tooltip to tell me what it meant.
Agreed that we should add tooltip for it.
how would you interpret it if there was a tooltip that said "Execution Order"?
when you run all cells it goes in that order? I was expecting that to be sequential from the top?
It's the order that it was executed it, not the order it will execute in. Hopefully a user would figure that out if they run the cell and see it change.
oh, more explicit would be better then imo I also question why this is useful but I'm guessing this is a common notebooks feature elsewhere?
Yeah it's what people expect from Jupyter and can help you understand the state of the kernel
Thanks that needs to be localized though. btw if you are going to merge your change in, you can just commit directly, no PR needed

const runToolbar = this.setupRunToolbar(runButtonContainer, container, contextKeyService, disposables); const executionOrderLabel = DOM.append(cellContainer, $('div.execution-count-label')); <ins> executionOrderLabel.setAttribute('title', 'Execution Order'); </ins> const editorPart = DOM.append(cellContainer, $('.cell-editor-part')); const editorContainer = DOM.append(editorPart, $('.cell-editor-container'));


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --FYI Related to ? Steps to Reproduce: Set up a keybinding for with any Trigger the keybinding, search editor opens but none of the are used Same keybinding works in Stable Demo using a workspace file: Same result: (not involving OneDrive) ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Version: 1.53.0-insider (user setup) Commit: Date: 2021-01-29T21:49:22.151Z Electron: 11.2.1 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: Windows_NT x64 10.0. Log Window) with enabled: [2021-01-31 19:44:09.185] [renderer1] [trace] CommandService#executeCommand [2021-01-31 19:44:15.502] [renderer1] [trace] KeybindingService#dispatch Ctrl+Shift+G [2021-01-31 19:44:15.502] [renderer1] [trace] CommandService#executeCommand
Thanks, I can reproduce.
To verify: Add a keybinding like: Execute it, expect to see the context line input properly filled out.
Works for me (W10). Used this keybinding just to test more args (see below for a comment in the args): I suppose an issue should be filed on not working if it was intended to - it does properly insert the full path, ala but fails silently and button does nothing.
thanks, as far as I'm aware directly putting that absolute path into the entry would fail as well, correct? So not a new issue.
Yes, it fails inserting it directly into the arg (escaped properly) and in the view in the Panel input - although in Search view it does show the error highlight around the query box and hover error message. I will not file an issue on this.

registerAction2(class OpenSearchEditorAction extends Action2 { constructor() { super({ <del> id: SearchEditorConstants.OpenNewEditorCommandId, title: localize('search.openNewEditor', "Open New Search Editor"), </del> <ins> id: 'search.action.openNewEditorFromView', title: localize('search.openNewEditor', "Open New Search Editor from View"), </ins> category, icon: searchNewEditorIcon, <del> f1: true, </del> menu: [{ id: MenuId.ViewTitle, group: 'navigation',


Question:
There is no drop hover feedback in the Explorer, for example, when in Light+ theme.
Broken by:

export const listInactiveFocusOutline = registerColor('list.inactiveFocusOutline', { dark: null, light: null, hc: null }, nls.localize('listInactiveFocusOutline', "List/Tree outline color for the focused item when the list/tree is inactive. An active list/tree has keyboard focus, an inactive does not.")); export const listHoverBackground = registerColor('list.hoverBackground', { dark: '#2A2D2E', light: '#F0F0F0', hc: null }, nls.localize('listHoverBackground', "List/Tree background when hovering over items using the mouse.")); export const listHoverForeground = registerColor('list.hoverForeground', { dark: null, light: null, hc: null }, nls.localize('listHoverForeground', "List/Tree foreground when hovering over items using the mouse.")); <del> export const listDropBackground = registerColor('list.dropBackground', { dark: listFocusBackground, light: listFocusBackground, hc: null }, nls.localize('listDropBackground', "List/Tree drag and drop background when moving items around using the mouse.")); </del> <ins> export const listDropBackground = registerColor('list.dropBackground', { dark: '#062F4A', light: '#D6EBFF', hc: null }, nls.localize('listDropBackground', "List/Tree drag and drop background when moving items around using the mouse.")); </ins> export const listHighlightForeground = registerColor('list.highlightForeground', { dark: '#0097fb', light: '#0066BF', hc: focusBorder }, nls.localize('highlight', 'List/Tree foreground color of the match highlights when searching inside the list/tree.')); export const listInvalidItemForeground = registerColor('list.invalidItemForeground', { dark: '#B89500', light: '#B89500', hc: '#B89500' }, nls.localize('invalidItemForeground', 'List/Tree foreground color for invalid items, for example an unresolved root in explorer.')); export const listErrorForeground = registerColor('list.errorForeground', { dark: '#F88070', light: '#B01011', hc: null }, nls.localize('listErrorForeground', 'Foreground color of list items containing errors.'));


Question:
I've seen this happen a few times now, and this last time it seemed to happen right after I closed a VS Code window. After that, I got the following notification in all my other open VS Code windows. ! Here is the Shared Process output
Going to look into whether we can wait for the process input to stop before actually killing the process for windows as another workaround for This process can take a bit of time now if needed since it's off the window being shutdown which has limited time to react.
It looks like we are using the same method as before where we indicate to dispose immediate. Perhaps it's different before because the window going down would more aggressively shut down its child processes?
we can consider bringing this in for the recovery build if we start seeing reports.
No, a few seconds after I open a second VSCode instance, this error message appears in both instances. It also happens if I open a second terminal in one instance
an extension may be closing the terminal, or it might be getting relaunched if an extension changes the environment (like the git extension will do when opening a new workspace). Does it happen if you open a new window and then wait 10 seconds before opening a terminal, such that extensions can activate?
I had the problem even with uninstalled extensions. But the good old "did you try turning it off an on again" helped. After a windows reboot, everything works fine
To clarify the scope of this fix since is still seeing lingering issues in insiders for this that we aren't able to nail down. Verified here means that the mechanism to delay killing the process on Windows for up to 5 seconds works as expected.
Don't know if this helps, but I've noticed that it consistently happens if I open a terminal in 2nd level (is that the vscode term for running vscode "inside" vscode?), after closing that 2nd level all terminals are stuck.
VSCode 1.55.0, the issue is still there. Single instance of VSCode looks fine, but starting another instance fires the warning almost immediately, breaking terminals in both instances.
It did not happened with git console but happens a lot with powershell but git has this other problem .
I've been getting this recently, though consistently throughout my day, while doing remote ssh sessions through the vscode terminal window. I open a new terminal and then use wsl2, and within wsl2 doing the ssh sessions. I experience this in both of the following VSCode versions: Version: 1.55.1 (user setup) Commit: Date: 2021-04-07T15:06:02.360Z Electron: 11.3.0 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0. Version: 1.56.0-insider (user setup) Commit: Date: 2021-04-09T09:50:06.816Z Electron: 11.4.2 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0.
for me, even single instanse of vscode show this message, if i want to restart "watch" task
Update:
Started getting this error in VSCode 1.55.2 after upgrading to Chrome OS v90; appears to cause the whole VM to seize. Persists after full powerwash & fresh VM/Code install, no exts enabled. :( UPDATE: FWIW, I have not experienced the issue on Chrome OS Version 90.0.4430.100 since updating to Code v1.56.0
I'm getting this error all the time since some months. If I start an npm script in VS Code this error occurs. So I had to switch to the git bash terminal (Windows). Hope this gets fixed... Still happens with 1.56.0
I am receiving this same error myself. I only have a few extensions installed and I've been extremely stable until I installed the PowerShell Extension. At that point I immediately receive the error that "The connection to the terminal's pty host process is unresponsive", as well as two others: "the language service could not be started", and "Loading the PowerShell extension is taking longer than expected. If you're using privilege enforcement software, this can affect start up performance" I'm pretty new to using VS and programming in general so I'm not sure what to do about this.
this should be fixed in the build as of today, coming to stable in a month or so.
Hey forgive me if this is a dumb question but the Insiders build is kind of like a "beta" build? So there's the potential for it to have issues in other areas? Just weighing the pros and cons of getting the extension working vs. potentially having issues in other areas.
yes it is, you may get some instability but also access to new fixes/features. But this issue is fixed (finally), it just won't be available in stable until early next month.
sounds like you have the accessibility mode on, click the "screen reader optimized" button in the status bar.
I get this all the time even in the Insiders build and with no extensions. It started for me right after updating to macOS Big Sur v11.4
this is the only know case where this can happen on macOS
I'm getting this issue all the time at Windows10 (so I guess it's not just related to macOS) I usually keep open plenty of VS code projects (usually 2-5 at the same time). TBH it just got so unbearable, I launch external terminals manually whenever it's possible. (So basically every time, except when I'm using a debugger) My system specs are Any feedback/fix suggestions are greatly appreciated
the new release which fixes this should be out next week.

.pipe(jsFilter) .pipe(util.rewriteSourceMappingURL(sourceMappingURLBase)) .pipe(jsFilter.restore) <del> .pipe(createAsar(path.join(process.cwd(), 'node_modules'), ['**/*.node', '**/vscode-ripgrep/bin/*', '**/node-pty/build/Release/*', '**/*.wasm'], 'node_modules.asar')); </del> <ins> .pipe(createAsar(path.join(process.cwd(), 'node_modules'), [ '**/*.node', '**/vscode-ripgrep/bin/*', '**/node-pty/build/Release/*', '**/node-pty/lib/worker/conoutSocketWorker.js', '**/node-pty/lib/shared/conout.js', '**/*.wasm' ], 'node_modules.asar')); </ins> let all = es.merge( packageJsonStream,


Question:
I've seen this happen a few times now, and this last time it seemed to happen right after I closed a VS Code window. After that, I got the following notification in all my other open VS Code windows. ! Here is the Shared Process output
Going to look into whether we can wait for the process input to stop before actually killing the process for windows as another workaround for This process can take a bit of time now if needed since it's off the window being shutdown which has limited time to react.
It looks like we are using the same method as before where we indicate to dispose immediate. Perhaps it's different before because the window going down would more aggressively shut down its child processes?
we can consider bringing this in for the recovery build if we start seeing reports.
No, a few seconds after I open a second VSCode instance, this error message appears in both instances. It also happens if I open a second terminal in one instance
an extension may be closing the terminal, or it might be getting relaunched if an extension changes the environment (like the git extension will do when opening a new workspace). Does it happen if you open a new window and then wait 10 seconds before opening a terminal, such that extensions can activate?
I had the problem even with uninstalled extensions. But the good old "did you try turning it off an on again" helped. After a windows reboot, everything works fine
To clarify the scope of this fix since is still seeing lingering issues in insiders for this that we aren't able to nail down. Verified here means that the mechanism to delay killing the process on Windows for up to 5 seconds works as expected.
Don't know if this helps, but I've noticed that it consistently happens if I open a terminal in 2nd level (is that the vscode term for running vscode "inside" vscode?), after closing that 2nd level all terminals are stuck.
VSCode 1.55.0, the issue is still there. Single instance of VSCode looks fine, but starting another instance fires the warning almost immediately, breaking terminals in both instances.
It did not happened with git console but happens a lot with powershell but git has this other problem .
I've been getting this recently, though consistently throughout my day, while doing remote ssh sessions through the vscode terminal window. I open a new terminal and then use wsl2, and within wsl2 doing the ssh sessions. I experience this in both of the following VSCode versions: Version: 1.55.1 (user setup) Commit: Date: 2021-04-07T15:06:02.360Z Electron: 11.3.0 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0. Version: 1.56.0-insider (user setup) Commit: Date: 2021-04-09T09:50:06.816Z Electron: 11.4.2 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0.
for me, even single instanse of vscode show this message, if i want to restart "watch" task
Update:
Started getting this error in VSCode 1.55.2 after upgrading to Chrome OS v90; appears to cause the whole VM to seize. Persists after full powerwash & fresh VM/Code install, no exts enabled. :( UPDATE: FWIW, I have not experienced the issue on Chrome OS Version 90.0.4430.100 since updating to Code v1.56.0
I'm getting this error all the time since some months. If I start an npm script in VS Code this error occurs. So I had to switch to the git bash terminal (Windows). Hope this gets fixed... Still happens with 1.56.0
I am receiving this same error myself. I only have a few extensions installed and I've been extremely stable until I installed the PowerShell Extension. At that point I immediately receive the error that "The connection to the terminal's pty host process is unresponsive", as well as two others: "the language service could not be started", and "Loading the PowerShell extension is taking longer than expected. If you're using privilege enforcement software, this can affect start up performance" I'm pretty new to using VS and programming in general so I'm not sure what to do about this.
this should be fixed in the build as of today, coming to stable in a month or so.
Hey forgive me if this is a dumb question but the Insiders build is kind of like a "beta" build? So there's the potential for it to have issues in other areas? Just weighing the pros and cons of getting the extension working vs. potentially having issues in other areas.
yes it is, you may get some instability but also access to new fixes/features. But this issue is fixed (finally), it just won't be available in stable until early next month.
sounds like you have the accessibility mode on, click the "screen reader optimized" button in the status bar.
I get this all the time even in the Insiders build and with no extensions. It started for me right after updating to macOS Big Sur v11.4
this is the only know case where this can happen on macOS
I'm getting this issue all the time at Windows10 (so I guess it's not just related to macOS) I usually keep open plenty of VS code projects (usually 2-5 at the same time). TBH it just got so unbearable, I launch external terminals manually whenever it's possible. (So basically every time, except when I'm using a debugger) My system specs are Any feedback/fix suggestions are greatly appreciated
the new release which fixes this should be out next week.

"native-is-elevated": "0.4.3", "native-keymap": "2.2.1", "native-watchdog": "1.3.0", <del> "node-pty": "0.10.1", </del> <ins> "node-pty": "0.11.0-beta7", </ins> "nsfw": "2.1.2", "spdlog": "^0.13.0", "sudo-prompt": "9.2.1",


Question:
I've seen this happen a few times now, and this last time it seemed to happen right after I closed a VS Code window. After that, I got the following notification in all my other open VS Code windows. ! Here is the Shared Process output
Going to look into whether we can wait for the process input to stop before actually killing the process for windows as another workaround for This process can take a bit of time now if needed since it's off the window being shutdown which has limited time to react.
It looks like we are using the same method as before where we indicate to dispose immediate. Perhaps it's different before because the window going down would more aggressively shut down its child processes?
we can consider bringing this in for the recovery build if we start seeing reports.
No, a few seconds after I open a second VSCode instance, this error message appears in both instances. It also happens if I open a second terminal in one instance
an extension may be closing the terminal, or it might be getting relaunched if an extension changes the environment (like the git extension will do when opening a new workspace). Does it happen if you open a new window and then wait 10 seconds before opening a terminal, such that extensions can activate?
I had the problem even with uninstalled extensions. But the good old "did you try turning it off an on again" helped. After a windows reboot, everything works fine
To clarify the scope of this fix since is still seeing lingering issues in insiders for this that we aren't able to nail down. Verified here means that the mechanism to delay killing the process on Windows for up to 5 seconds works as expected.
Don't know if this helps, but I've noticed that it consistently happens if I open a terminal in 2nd level (is that the vscode term for running vscode "inside" vscode?), after closing that 2nd level all terminals are stuck.
VSCode 1.55.0, the issue is still there. Single instance of VSCode looks fine, but starting another instance fires the warning almost immediately, breaking terminals in both instances.
It did not happened with git console but happens a lot with powershell but git has this other problem .
I've been getting this recently, though consistently throughout my day, while doing remote ssh sessions through the vscode terminal window. I open a new terminal and then use wsl2, and within wsl2 doing the ssh sessions. I experience this in both of the following VSCode versions: Version: 1.55.1 (user setup) Commit: Date: 2021-04-07T15:06:02.360Z Electron: 11.3.0 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0. Version: 1.56.0-insider (user setup) Commit: Date: 2021-04-09T09:50:06.816Z Electron: 11.4.2 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0.
for me, even single instanse of vscode show this message, if i want to restart "watch" task
Update:
Started getting this error in VSCode 1.55.2 after upgrading to Chrome OS v90; appears to cause the whole VM to seize. Persists after full powerwash & fresh VM/Code install, no exts enabled. :( UPDATE: FWIW, I have not experienced the issue on Chrome OS Version 90.0.4430.100 since updating to Code v1.56.0
I'm getting this error all the time since some months. If I start an npm script in VS Code this error occurs. So I had to switch to the git bash terminal (Windows). Hope this gets fixed... Still happens with 1.56.0
I am receiving this same error myself. I only have a few extensions installed and I've been extremely stable until I installed the PowerShell Extension. At that point I immediately receive the error that "The connection to the terminal's pty host process is unresponsive", as well as two others: "the language service could not be started", and "Loading the PowerShell extension is taking longer than expected. If you're using privilege enforcement software, this can affect start up performance" I'm pretty new to using VS and programming in general so I'm not sure what to do about this.
this should be fixed in the build as of today, coming to stable in a month or so.
Hey forgive me if this is a dumb question but the Insiders build is kind of like a "beta" build? So there's the potential for it to have issues in other areas? Just weighing the pros and cons of getting the extension working vs. potentially having issues in other areas.
yes it is, you may get some instability but also access to new fixes/features. But this issue is fixed (finally), it just won't be available in stable until early next month.
sounds like you have the accessibility mode on, click the "screen reader optimized" button in the status bar.
I get this all the time even in the Insiders build and with no extensions. It started for me right after updating to macOS Big Sur v11.4
this is the only know case where this can happen on macOS
I'm getting this issue all the time at Windows10 (so I guess it's not just related to macOS) I usually keep open plenty of VS code projects (usually 2-5 at the same time). TBH it just got so unbearable, I launch external terminals manually whenever it's possible. (So basically every time, except when I'm using a debugger) My system specs are Any feedback/fix suggestions are greatly appreciated
the new release which fixes this should be out next week.

"jschardet": "3.0.0", "minimist": "^1.2.5", "native-watchdog": "1.3.0", <del> "node-pty": "0.10.1", </del> <ins> "node-pty": "0.11.0-beta7", </ins> "nsfw": "2.1.2", "spdlog": "^0.13.0", "tas-client-umd": "0.1.4",


Question:
I've seen this happen a few times now, and this last time it seemed to happen right after I closed a VS Code window. After that, I got the following notification in all my other open VS Code windows. ! Here is the Shared Process output
Going to look into whether we can wait for the process input to stop before actually killing the process for windows as another workaround for This process can take a bit of time now if needed since it's off the window being shutdown which has limited time to react.
It looks like we are using the same method as before where we indicate to dispose immediate. Perhaps it's different before because the window going down would more aggressively shut down its child processes?
we can consider bringing this in for the recovery build if we start seeing reports.
No, a few seconds after I open a second VSCode instance, this error message appears in both instances. It also happens if I open a second terminal in one instance
an extension may be closing the terminal, or it might be getting relaunched if an extension changes the environment (like the git extension will do when opening a new workspace). Does it happen if you open a new window and then wait 10 seconds before opening a terminal, such that extensions can activate?
I had the problem even with uninstalled extensions. But the good old "did you try turning it off an on again" helped. After a windows reboot, everything works fine
To clarify the scope of this fix since is still seeing lingering issues in insiders for this that we aren't able to nail down. Verified here means that the mechanism to delay killing the process on Windows for up to 5 seconds works as expected.
Don't know if this helps, but I've noticed that it consistently happens if I open a terminal in 2nd level (is that the vscode term for running vscode "inside" vscode?), after closing that 2nd level all terminals are stuck.
VSCode 1.55.0, the issue is still there. Single instance of VSCode looks fine, but starting another instance fires the warning almost immediately, breaking terminals in both instances.
It did not happened with git console but happens a lot with powershell but git has this other problem .
I've been getting this recently, though consistently throughout my day, while doing remote ssh sessions through the vscode terminal window. I open a new terminal and then use wsl2, and within wsl2 doing the ssh sessions. I experience this in both of the following VSCode versions: Version: 1.55.1 (user setup) Commit: Date: 2021-04-07T15:06:02.360Z Electron: 11.3.0 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0. Version: 1.56.0-insider (user setup) Commit: Date: 2021-04-09T09:50:06.816Z Electron: 11.4.2 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0.
for me, even single instanse of vscode show this message, if i want to restart "watch" task
Update:
Started getting this error in VSCode 1.55.2 after upgrading to Chrome OS v90; appears to cause the whole VM to seize. Persists after full powerwash & fresh VM/Code install, no exts enabled. :( UPDATE: FWIW, I have not experienced the issue on Chrome OS Version 90.0.4430.100 since updating to Code v1.56.0
I'm getting this error all the time since some months. If I start an npm script in VS Code this error occurs. So I had to switch to the git bash terminal (Windows). Hope this gets fixed... Still happens with 1.56.0
I am receiving this same error myself. I only have a few extensions installed and I've been extremely stable until I installed the PowerShell Extension. At that point I immediately receive the error that "The connection to the terminal's pty host process is unresponsive", as well as two others: "the language service could not be started", and "Loading the PowerShell extension is taking longer than expected. If you're using privilege enforcement software, this can affect start up performance" I'm pretty new to using VS and programming in general so I'm not sure what to do about this.
this should be fixed in the build as of today, coming to stable in a month or so.
Hey forgive me if this is a dumb question but the Insiders build is kind of like a "beta" build? So there's the potential for it to have issues in other areas? Just weighing the pros and cons of getting the extension working vs. potentially having issues in other areas.
yes it is, you may get some instability but also access to new fixes/features. But this issue is fixed (finally), it just won't be available in stable until early next month.
sounds like you have the accessibility mode on, click the "screen reader optimized" button in the status bar.
I get this all the time even in the Insiders build and with no extensions. It started for me right after updating to macOS Big Sur v11.4
this is the only know case where this can happen on macOS
I'm getting this issue all the time at Windows10 (so I guess it's not just related to macOS) I usually keep open plenty of VS code projects (usually 2-5 at the same time). TBH it just got so unbearable, I launch external terminals manually whenever it's possible. (So basically every time, except when I'm using a debugger) My system specs are Any feedback/fix suggestions are greatly appreciated
the new release which fixes this should be out next week.

resolved "https://registry.yarnpkg.com/node-addon-api/-/node-addon-api-3.1.0.tgz#98b21931557466c6729e51cb77cd39c965f42239" integrity sha512-flmrDNB06LIl5lywUz7YlNGZH/5p0M7W28k8hzd9Lshtdh1wshD2Y+U4h9LD6KObOy1f+fEVdgprPrEymjM5uw== <del> node-pty@0.10.1: version "0.10.1" resolved "https://registry.yarnpkg.com/node-pty/-/node-pty-0.10.1.tgz#cd05d03a2710315ec40221232ec04186f6ac2c6d" integrity sha512-JTdtUS0Im/yRsWJSx7yiW9rtpfmxqxolrtnyKwPLI+6XqTAPW/O2MjS8FYL4I5TsMbH2lVgDb2VMjp+9LoQGNg== </del> <ins> node-pty@0.11.0-beta7: version "0.11.0-beta7" resolved "https://registry.yarnpkg.com/node-pty/-/node-pty-0.11.0-beta7.tgz#aed0888b5032d96c54d8473455e6adfae3bbebbe" integrity sha512-uApPGLglZRiHQcUMWakbZOrBo8HVWvhzIqNnrWvBGJOvc6m/S5lCdbbg93BURyJqHFmBS0GV+4hwiMNDuGRbSA== </ins> dependencies: nan "^2.14.0"


Question:
I've seen this happen a few times now, and this last time it seemed to happen right after I closed a VS Code window. After that, I got the following notification in all my other open VS Code windows. ! Here is the Shared Process output
Going to look into whether we can wait for the process input to stop before actually killing the process for windows as another workaround for This process can take a bit of time now if needed since it's off the window being shutdown which has limited time to react.
It looks like we are using the same method as before where we indicate to dispose immediate. Perhaps it's different before because the window going down would more aggressively shut down its child processes?
we can consider bringing this in for the recovery build if we start seeing reports.
No, a few seconds after I open a second VSCode instance, this error message appears in both instances. It also happens if I open a second terminal in one instance
an extension may be closing the terminal, or it might be getting relaunched if an extension changes the environment (like the git extension will do when opening a new workspace). Does it happen if you open a new window and then wait 10 seconds before opening a terminal, such that extensions can activate?
I had the problem even with uninstalled extensions. But the good old "did you try turning it off an on again" helped. After a windows reboot, everything works fine
To clarify the scope of this fix since is still seeing lingering issues in insiders for this that we aren't able to nail down. Verified here means that the mechanism to delay killing the process on Windows for up to 5 seconds works as expected.
Don't know if this helps, but I've noticed that it consistently happens if I open a terminal in 2nd level (is that the vscode term for running vscode "inside" vscode?), after closing that 2nd level all terminals are stuck.
VSCode 1.55.0, the issue is still there. Single instance of VSCode looks fine, but starting another instance fires the warning almost immediately, breaking terminals in both instances.
It did not happened with git console but happens a lot with powershell but git has this other problem .
I've been getting this recently, though consistently throughout my day, while doing remote ssh sessions through the vscode terminal window. I open a new terminal and then use wsl2, and within wsl2 doing the ssh sessions. I experience this in both of the following VSCode versions: Version: 1.55.1 (user setup) Commit: Date: 2021-04-07T15:06:02.360Z Electron: 11.3.0 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0. Version: 1.56.0-insider (user setup) Commit: Date: 2021-04-09T09:50:06.816Z Electron: 11.4.2 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: WindowsNT x64 10.0.
for me, even single instanse of vscode show this message, if i want to restart "watch" task
Update:
Started getting this error in VSCode 1.55.2 after upgrading to Chrome OS v90; appears to cause the whole VM to seize. Persists after full powerwash & fresh VM/Code install, no exts enabled. :( UPDATE: FWIW, I have not experienced the issue on Chrome OS Version 90.0.4430.100 since updating to Code v1.56.0
I'm getting this error all the time since some months. If I start an npm script in VS Code this error occurs. So I had to switch to the git bash terminal (Windows). Hope this gets fixed... Still happens with 1.56.0
I am receiving this same error myself. I only have a few extensions installed and I've been extremely stable until I installed the PowerShell Extension. At that point I immediately receive the error that "The connection to the terminal's pty host process is unresponsive", as well as two others: "the language service could not be started", and "Loading the PowerShell extension is taking longer than expected. If you're using privilege enforcement software, this can affect start up performance" I'm pretty new to using VS and programming in general so I'm not sure what to do about this.
this should be fixed in the build as of today, coming to stable in a month or so.
Hey forgive me if this is a dumb question but the Insiders build is kind of like a "beta" build? So there's the potential for it to have issues in other areas? Just weighing the pros and cons of getting the extension working vs. potentially having issues in other areas.
yes it is, you may get some instability but also access to new fixes/features. But this issue is fixed (finally), it just won't be available in stable until early next month.
sounds like you have the accessibility mode on, click the "screen reader optimized" button in the status bar.
I get this all the time even in the Insiders build and with no extensions. It started for me right after updating to macOS Big Sur v11.4
this is the only know case where this can happen on macOS
I'm getting this issue all the time at Windows10 (so I guess it's not just related to macOS) I usually keep open plenty of VS code projects (usually 2-5 at the same time). TBH it just got so unbearable, I launch external terminals manually whenever it's possible. (So basically every time, except when I'm using a debugger) My system specs are Any feedback/fix suggestions are greatly appreciated
the new release which fixes this should be out next week.

util "^0.11.0" vm-browserify "^1.0.1" <del> node-pty@0.10.1: version "0.10.1" resolved "https://registry.yarnpkg.com/node-pty/-/node-pty-0.10.1.tgz#cd05d03a2710315ec40221232ec04186f6ac2c6d" integrity sha512-JTdtUS0Im/yRsWJSx7yiW9rtpfmxqxolrtnyKwPLI+6XqTAPW/O2MjS8FYL4I5TsMbH2lVgDb2VMjp+9LoQGNg== </del> <ins> node-pty@0.11.0-beta7: version "0.11.0-beta7" resolved "https://registry.yarnpkg.com/node-pty/-/node-pty-0.11.0-beta7.tgz#aed0888b5032d96c54d8473455e6adfae3bbebbe" integrity sha512-uApPGLglZRiHQcUMWakbZOrBo8HVWvhzIqNnrWvBGJOvc6m/S5lCdbbg93BURyJqHFmBS0GV+4hwiMNDuGRbSA== </ins> dependencies: nan "^2.14.0"


Question:
We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.

private _startBarrier: Barrier; private _persistentTerminalId: number; <ins> public get id(): number { return this._persistentTerminalId; } </ins> private _inReplay = false; constructor( <del> readonly id: number, </del> <ins> private readonly _instanceId: number, </ins> readonly shouldPersist: boolean, private readonly _shellLaunchConfig: IShellLaunchConfig, private readonly _activeWorkspaceRootUri: URI | undefined,


Question:
We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.

env: this._shellLaunchConfig.env }; <del> this._logService.trace('Spawning remote agent process', { terminalId: this.id, shellLaunchConfigDto }); </del> <ins> this._logService.trace('Spawning remote agent process', { terminalId: this._instanceId, shellLaunchConfigDto }); </ins> const result = await this._remoteTerminalChannel.createTerminalProcess( shellLaunchConfigDto,


Question:
We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.

this.onActiveTabChanged(() => isRemote ? this._updateRemoteState() : this._updateLocalState()); this.onActiveInstanceChanged(() => isRemote ? this._updateRemoteState() : this._updateLocalState()); this.onInstancesChanged(() => isRemote ? this._updateRemoteState() : this._updateLocalState()); <ins> // The state must be updated when the terminal is relaunched, otherwise the persistent // terminal ID will be stale and the process will be leaked. this.onInstanceProcessIdReady(() => isRemote ? this._updateRemoteState() : this._updateLocalState()); </ins> } public setNativeWindowsDelegate(delegate: ITerminalNativeWindowsDelegate): void {


Question:
We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.

terminals: instances.map(t => { return { relativeSize: isHorizontal ? t.cols / totalSize : t.rows / totalSize, <del> terminal: t.persistentTerminalId ? t.persistentTerminalId : t.id </del> <ins> terminal: t.persistentTerminalId || 0 </ins> }; }) };


Question:
Tracks bundling TS 4.2.3 with VS Code. This includes a
Should be in recovery and in main now

"license": "MIT", "description": "Dependencies shared by all extensions", "dependencies": { <del> "typescript": "4.2.2" </del> <ins> "typescript": "4.2.3" </ins> }, "scripts": { "postinstall": "node ./postinstall"


Question:
Tracks bundling TS 4.2.3 with VS Code. This includes a
Should be in recovery and in main now

resolved "https://registry.yarnpkg.com/fast-plist/-/fast-plist-0.1.2.tgz#a45aff345196006d406ca6cdcd05f69051ef35b8" integrity sha1-pFr/NFGWAG1AbKbNzQX2kFHvNbg= <del> typescript@4.2.2: version "4.2.2" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.2.2.tgz#1450f020618f872db0ea17317d16d8da8ddb8c4c" integrity sha512-tbb+NVrLfnsJy3M59lsDgrzWIflR4d4TIUjz+heUnHZwdF7YsrMTKoRERiIvI2lvBG95dfpLxB21WZhys1bgaQ== </del> <ins> typescript@4.2.3: version "4.2.3" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.2.3.tgz#39062d8019912d43726298f09493d598048c1ce3" integrity sha512-qOcYwxaByStAWrBf4x0fibwZvMRG+r4cQoTjbPtUlrWjBHbmCAww1i448U0GJ+3cNNEtebDteo/cHOR3xJ4wEw== </ins> vscode-grammar-updater@^1.0.3: version "1.0.3"


Question:
Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via

import { NativeHostService } from 'vs/platform/native/electron-sandbox/nativeHostService'; import { getIconsStyleSheet } from 'vs/platform/theme/browser/iconsStyleSheet'; import { applyZoom, zoomIn, zoomOut } from 'vs/platform/window/electron-sandbox/window'; <ins> import { StandardKeyboardEvent } from 'vs/base/browser/keyboardEvent'; import { KeyCode } from 'vs/base/common/keyCodes'; </ins> const DEBUG_FLAGS_PATTERN = /s--(inspect|debug)(-brk|port)?=(d+)?/; const DEBUG_PORT_PATTERN = /s--(inspect|debug)-port=(d+)/;


Question:
Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via

this.tree.setInput({ processes: { processRoots } }); this.tree.layout(window.innerHeight, window.innerWidth); <ins> this.tree.onKeyDown(e => { const event = new StandardKeyboardEvent(e); if (event.keyCode === KeyCode.KeyE && event.altKey) { const selectionPids = this.getSelectedPids(); void Promise.all(selectionPids.map((pid) => this.nativeHostService.killProcess(pid, 'SIGTERM'))).then(() => this.tree?.refresh()); } }); </ins> this.tree.onContextMenu(e => { if (isProcessItem(e.element)) { this.showContextMenu(e.element, true);


Question:
Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via

label: localize('copy', "Copy"), click: () => { // Collect the selected pids <del> const selectionPids = this.tree?.getSelection()?.map(e => { if (!e || !('pid' in e)) { return undefined; } return e.pid; }).filter(e => !!e) as number[]; </del> <ins> const selectionPids = this.getSelectedPids(); </ins> // If the selection does not contain the right clicked item, copy the right clicked // item only. if (!selectionPids?.includes(pid)) {


Question:
Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via

} }, 200); } <ins> private getSelectedPids() { return this.tree?.getSelection()?.map(e => { if (!e || !('pid' in e)) { return undefined; } return e.pid; }).filter(e => !!e) as number[]; } </ins> } function createCodiconStyleSheet() {


constructor(@IStateService private stateService: IStateService, @IConfigurationService private configurationService: IConfigurationService) { super(); <ins> // System Theme this._register(this.configurationService.onDidChangeConfiguration(e => { if (e.affectsConfiguration('window.systemColorTheme')) { this.updateSystemColorTheme(); } })); this.updateSystemColorTheme(); </ins> // Color Scheme changes <del> nativeTheme.on('updated', () => { this._onDidChangeColorScheme.fire(this.getColorScheme()); }); </del> <ins> this._register(Event.fromNodeEventEmitter(nativeTheme, 'updated')(() => this._onDidChangeColorScheme.fire(this.getColorScheme()))); } private updateSystemColorTheme(): void { switch (this.configurationService.getValue<'default' | 'auto' | 'light' | 'dark'>('window.systemColorTheme')) { case 'dark': nativeTheme.themeSource = 'dark'; break; case 'light': nativeTheme.themeSource = 'light'; break; case 'auto': switch (this.getBaseTheme()) { case 'vs': nativeTheme.themeSource = 'light'; break; case 'vs-dark': nativeTheme.themeSource = 'dark'; break; default: nativeTheme.themeSource = 'system'; } break; default: nativeTheme.themeSource = 'system'; break; } </ins> } getColorScheme(): IColorScheme {


let background = this.stateService.getItem<string | null>(THEME_BG_STORAGE_KEY, null); if (!background) { <del> const baseTheme = this.stateService.getItem<string>(THEME_STORAGE_KEY, 'vs-dark').split(' ')[0]; switch (baseTheme) { </del> <ins> switch (this.getBaseTheme()) { </ins> case 'vs': background = DEFAULT_BG_LIGHT; break; case 'hc-black': background = DEFAULT_BG_HC_BLACK; break; case 'hc-light': background = DEFAULT_BG_HC_LIGHT; break;


return background; } <ins> private getBaseTheme(): 'vs' | 'vs-dark' | 'hc-black' | 'hc-light' { const baseTheme = this.stateService.getItem<string>(THEME_STORAGE_KEY, 'vs-dark').split(' ')[0]; switch (baseTheme) { case 'vs': return 'vs'; case 'hc-black': return 'hc-black'; case 'hc-light': return 'hc-light'; default: return 'vs-dark'; } } </ins> saveWindowSplash(windowId: number | undefined, splash: IPartsSplash): void { // Update in storage


if (typeof windowId === 'number') { this.updateBackgroundColor(windowId, splash); } <ins> // Update system theme this.updateSystemColorTheme(); </ins> } private updateBackgroundColor(windowId: number, splash: IPartsSplash): void {


<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import { localize } from 'vs/nls'; import { Registry } from 'vs/platform/registry/common/platform'; import { IConfigurationRegistry, Extensions as ConfigurationExtensions, ConfigurationScope } from 'vs/platform/configuration/common/configurationRegistry'; import { isLinux } from 'vs/base/common/platform'; const configurationRegistry = Registry.as<IConfigurationRegistry>(ConfigurationExtensions.Configuration); configurationRegistry.registerConfiguration({ 'properties': { 'window.systemColorTheme': { 'type': 'string', 'enum': ['default', 'auto', 'light', 'dark'], 'enumDescriptions': [ localize('window.systemColorTheme.default', "System color theme matches the configured OS theme."), localize('window.systemColorTheme.auto', "Enforce a light system color theme when a light workbench color theme is configured and the same for configured dark workbench color themes."), localize('window.systemColorTheme.light', "Enforce a light system color theme."), localize('window.systemColorTheme.dark', "Enforce a dark system color theme."), ], 'markdownDescription': localize('window.systemColorTheme', "The system color theme applies to native UI elements such as native dialogs, menus and title bar. Even if your OS is configured in light appearance mode, you can select a dark system color theme for the window. You can also configure to automatically adjust based on the `#workbench.colorTheme#` setting."), 'default': 'default', 'included': !isLinux, // not supported on Linux (https://github.com/electron/electron/issues/28887) 'scope': ConfigurationScope.APPLICATION } } }); </ins>


// Terminal import 'vs/workbench/contrib/terminal/electron-sandbox/terminal.contribution'; <del> // Themes Support </del> <ins> // Themes </ins> import 'vs/workbench/contrib/themes/browser/themes.test.contribution'; <ins> import 'vs/workbench/services/themes/electron-sandbox/themes.contribution'; </ins> // User Data Sync import 'vs/workbench/contrib/userDataSync/electron-sandbox/userDataSync.contribution';


Question: It doesn't look right compared to all the other placeholders: ! It's more noticeable when using editor font (font gets smaller): VS Code version: Code - Insiders 1.56.0-insider (, 2021-04-16T11:25:09.662Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --

position: absolute; pointer-events: none; z-index: 1; <del> padding: 2px 6px 3px 6px; </del> <ins> padding: 3px 6px; </ins> box-sizing: border-box; width: 100%; overflow: hidden;


Question:
See I think the best way for this would be for VS Code core to rename the terminal if gets a new request with a different name -- opened an issue for that Or, at least, try to use a terminal of the same name if one exists (which would be easier and probably more feasible since the is not writable.) Code pointer:
Also fyi
I'm going to take a swing at this. Here is my current understanding of the problem and I would appreciate any feedback or comments. The issue - Launching debug sessions in integrated terminal will open duplicate terminals. Solution - Code can attempt to find a terminal instance that has the same title as the launch request and is not currently in use. If located, it can reuse that instance, otherwise it can use the existing logic to create a new instance. I believe this should also address the concerns in as Code will stop spawning new terminal instances for repeat debug sessions. Please let me know if I have any misunderstandings on the issue.
Sounds good to me
I'm looking over the current code for checking out an integrated terminal and came across the minUseDelay for determining which of the terminals is available for use. It was a fix for . As I understand it, when compound node tasks were run, they would all try to grab the same terminal instance so only the first one to run would actually get the terminal, the others would fail to run. By introducing the minUseDelay, it insured that all of the launch tasks would get a new terminal instance. Once microsoft/vscode-js-debug is merged, each Node launch task will most likely have a unique name and therefore a dedicated terminal instance (ideally) which would mean we could always return the first terminal without a child process that has the same title and get rid of minUseDelay. Right?
Obviously if someone had two launch configurations with the same name (why?) this would fall apart.
We could even enforce name-matching and reopen the terminal if nothing's running in it and the name mismatches

const shell = this._terminalService.getDefaultShell(true, configProvider); const shellArgs = this._terminalService.getDefaultShellArgs(true, configProvider); <ins> const terminalName = args.title || nls.localize('debug.terminal.title', "Debug Process"); </ins> const shellConfig = JSON.stringify({ shell, shellArgs }); <del> let terminal = await this._integratedTerminalInstances.checkout(shellConfig); </del> <ins> let terminal = await this._integratedTerminalInstances.checkout(shellConfig, terminalName); </ins> let cwdForPrepareCommand: string | undefined; let giveShellTimeToInitialize = false;


Question:
See I think the best way for this would be for VS Code core to rename the terminal if gets a new request with a different name -- opened an issue for that Or, at least, try to use a terminal of the same name if one exists (which would be easier and probably more feasible since the is not writable.) Code pointer:
Also fyi
I'm going to take a swing at this. Here is my current understanding of the problem and I would appreciate any feedback or comments. The issue - Launching debug sessions in integrated terminal will open duplicate terminals. Solution - Code can attempt to find a terminal instance that has the same title as the launch request and is not currently in use. If located, it can reuse that instance, otherwise it can use the existing logic to create a new instance. I believe this should also address the concerns in as Code will stop spawning new terminal instances for repeat debug sessions. Please let me know if I have any misunderstandings on the issue.
Sounds good to me
I'm looking over the current code for checking out an integrated terminal and came across the minUseDelay for determining which of the terminals is available for use. It was a fix for . As I understand it, when compound node tasks were run, they would all try to grab the same terminal instance so only the first one to run would actually get the terminal, the others would fail to run. By introducing the minUseDelay, it insured that all of the launch tasks would get a new terminal instance. Once microsoft/vscode-js-debug is merged, each Node launch task will most likely have a unique name and therefore a dedicated terminal instance (ideally) which would mean we could always return the first terminal without a child process that has the same title and get rid of minUseDelay. Right?
Obviously if someone had two launch configurations with the same name (why?) this would fall apart.
We could even enforce name-matching and reopen the terminal if nothing's running in it and the name mismatches

shellPath: shell, shellArgs: shellArgs, cwd: args.cwd, <del> name: args.title || nls.localize('debug.terminal.title', "debuggee"), </del> <ins> name: terminalName, </ins> }; giveShellTimeToInitialize = true; terminal = this._terminalService.createTerminalFromOptions(options, true);


Question:
See I think the best way for this would be for VS Code core to rename the terminal if gets a new request with a different name -- opened an issue for that Or, at least, try to use a terminal of the same name if one exists (which would be easier and probably more feasible since the is not writable.) Code pointer:
Also fyi
I'm going to take a swing at this. Here is my current understanding of the problem and I would appreciate any feedback or comments. The issue - Launching debug sessions in integrated terminal will open duplicate terminals. Solution - Code can attempt to find a terminal instance that has the same title as the launch request and is not currently in use. If located, it can reuse that instance, otherwise it can use the existing logic to create a new instance. I believe this should also address the concerns in as Code will stop spawning new terminal instances for repeat debug sessions. Please let me know if I have any misunderstandings on the issue.
Sounds good to me
I'm looking over the current code for checking out an integrated terminal and came across the minUseDelay for determining which of the terminals is available for use. It was a fix for . As I understand it, when compound node tasks were run, they would all try to grab the same terminal instance so only the first one to run would actually get the terminal, the others would fail to run. By introducing the minUseDelay, it insured that all of the launch tasks would get a new terminal instance. Once microsoft/vscode-js-debug is merged, each Node launch task will most likely have a unique name and therefore a dedicated terminal instance (ideally) which would mean we could always return the first terminal without a child process that has the same title and get rid of minUseDelay. Right?
Obviously if someone had two launch configurations with the same name (why?) this would fall apart.
We could even enforce name-matching and reopen the terminal if nothing's running in it and the name mismatches

private _terminalInstances = new Map<vscode.Terminal, { lastUsedAt: number, config: string }>(); <del> public async checkout(config: string) { </del> <ins> public async checkout(config: string, name: string) { </ins> const entries = [...this._terminalInstances.entries()]; const promises = entries.map(([terminal, termInfo]) => createCancelablePromise(async ct => { <ins> // Only allow terminals that match the title.  See #123189 if (terminal.name !== name) { return null; } </ins> if (termInfo.lastUsedAt !== -1 && await hasChildProcesses(await terminal.processId)) { return null; }