jiebi/CodeConvo huggingface dataset:
Code change:
this._register(this.remoteExplorerService.onEnabledPortsFeatures(() => this._proxy.$registerCandidateFinder(this.processFindingEnabled()))); } this._register(this.configurationService.onDidChangeConfiguration(async (e) => { <del> if (e.affectsConfiguration(PORT_AUTO_FORWARD_SETTING) || e.affectsConfiguration(PORT_AUTO_SOURCE_SETTING)) { </del> <ins> if (this.remoteExplorerService.portsFeaturesEnabled && (e.affectsConfiguration(PORT_AUTO_FORWARD_SETTING) || e.affectsConfiguration(PORT_AUTO_SOURCE_SETTING))) { </ins> return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); } })); <del> this._register(this.tunnelService.onAddedTunnelProvider(() => { return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); </del> <ins> this._register(this.tunnelService.onAddedTunnelProvider(async () => { if (this.remoteExplorerService.portsFeaturesEnabled) { return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); } </ins> })); }

Related discussion:
text: Type: <bBug</bvscode with wsl: or similar tool to monitor CPU usage when vscode is idle or minimized to the taskbar. Expected: CPU usage for vscode's remote server should stay around 0% at idle conditions. Actual: CPU usage stays between 2-10 % VS Code version: Code 1.91.1 (, 2024-07-09T22:06:49.809Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 6.6.36.3-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ remote-wsl0.88.2 material-icon-theme5.6.0 vim1.27.3 markdown-checkbox0.4.0 gitlens15.2.0 prettier-vscode10.4.0 hexeditor1.10.0 advanced-new-file1.2.2 vscode-fileutils3.10.3 even-better-toml0.19.2 </details<!-- generated by issue reporter --
I had earlier opened the issue at where I provided more in-depth issue description. I'm just going to put the same description here. I recently noticed high CPU usage and faster battery drain (intel cpu) when working with any project under WSL. To find out what's taking so much cpu time (even when I'm doing nothing, apart from staring at the screen), I used to list processes in the order of cpu usage: ! Looked like vscode's remote server running inside wsl is taking CPU. So, I went a little further to profile the running instance of the remote server and I found: ! ! from is being called at a regular interval with a small delay (~1000ms). : ! I was able to trace back to : ! And I finally found where it is being called repeatedly: ! Now, why is it a bug? Because I've disabled all related settings in my config, yet the tunnel monitoring service is running in the background. I expect the service to not be running when or related configs are disabled. The service is currently always running.
Wow, great job, thanks for tracking down the problem!
I'm having trouble understanding this: Is WSL going to end up being a ?
Code change:
this._register(this.remoteExplorerService.onEnabledPortsFeatures(() => this._proxy.$registerCandidateFinder(this.processFindingEnabled()))); } this._register(this.configurationService.onDidChangeConfiguration(async (e) => { <del> if (e.affectsConfiguration(PORT_AUTO_FORWARD_SETTING) || e.affectsConfiguration(PORT_AUTO_SOURCE_SETTING)) { </del> <ins> if (this.remoteExplorerService.portsFeaturesEnabled && (e.affectsConfiguration(PORT_AUTO_FORWARD_SETTING) || e.affectsConfiguration(PORT_AUTO_SOURCE_SETTING))) { </ins> return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); } })); <del> this._register(this.tunnelService.onAddedTunnelProvider(() => { return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); </del> <ins> this._register(this.tunnelService.onAddedTunnelProvider(async () => { if (this.remoteExplorerService.portsFeaturesEnabled) { return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); } </ins> })); }

Related discussion:
text: I don't think we actually want to show the ports view in WSL even if the Tunnels extension isn't installed.
I agree. For non-managed remote authorities created just via the in the workbench, how did we determine whether or not to show the ports view? We should apply the same logic here...
The ports view is controlled by a context key getting set. It gets set in two ways: an extension that wants the ports view. This is what dev containers does. a tunnel factory getting . Since the tunnel factory is always now, we're always enabling it. I should be able to add a check if the tunnel factory is coming from an extension and only do 2 if that's the case.
Looks like we also show the ports view when there's an extension with an actiation event: Is this perhaps no longer needed with the work you did for tunnels I don't remember exactly why I it.
I've moved the check to happen when there's been a port forwarded.
Looks like this was actually a feature: You can set to disable this. I'm also going to try to improve the description of and .
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
To verify: the descriptions of and . Verify that you can understand what the settings do and how they're related. (These settings may be a bit confusing. We should consider deprecating and only have ) . to or if it isn't already. the WSL extension, connect to a WSL remote. the log level to Trace for the Remote Extension Host. the output for the Remote Extension Host. Verify that you see a steady stream of log lines that say "candidate" coming in. This means that port discovery is on. to and to . Reload. sure that the log level of the Remote Extension Host is still set to Trace the output for the Remote Extension Host. Verify that you DO NOT see a steady stream of log lines that say "candidate" coming in.
Code change:
this._register(this.remoteExplorerService.onEnabledPortsFeatures(() => this._proxy.$registerCandidateFinder(this.processFindingEnabled()))); } this._register(this.configurationService.onDidChangeConfiguration(async (e) => { <del> if (e.affectsConfiguration(PORT_AUTO_FORWARD_SETTING) || e.affectsConfiguration(PORT_AUTO_SOURCE_SETTING)) { </del> <ins> if (this.remoteExplorerService.portsFeaturesEnabled && (e.affectsConfiguration(PORT_AUTO_FORWARD_SETTING) || e.affectsConfiguration(PORT_AUTO_SOURCE_SETTING))) { </ins> return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); } })); <del> this._register(this.tunnelService.onAddedTunnelProvider(() => { return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); </del> <ins> this._register(this.tunnelService.onAddedTunnelProvider(async () => { if (this.remoteExplorerService.portsFeaturesEnabled) { return this._proxy.$registerCandidateFinder(this.processFindingEnabled()); } </ins> })); }

Related discussion:
text: In the WSL workspace, I don't see any log lines that say "candidate" even after starting a Python HTTP server.
I can't repro this. Do you have an old version of WSL installed?
I verified that on my machine the work.
I haven't checked with Insider, but in stable I can confirm 'candidate' logs are not visible after Step 6 of the verification steps. Thanks. I also want to point out that it's not clear from the description that there's a process monitoring service running in the background, and that it can be disabled using . Should the default option be instead of ?
Thanks for trying it out If we set it to , then we might end up not showing any ports in the Ports view. In insiders, I updated the text of the setting: Sets the source from which ports are automatically forwarded when is true. When is false, will be used to find information about ports that have already been forwarded. On Windows and macOS remotes, the process and hybrid options have no effect and output will be used. It still doesn't explicitly say there will be process monitoring, but it should be clearer.
Code change:
} try { <del> return super.write(resource, value, options); </del> <ins> return await super.write(resource, value, options); </ins> } catch (error) { // In case of permission denied, we need to check for readonly

Related discussion:
text: On previous versions of VSCode (1.47) you received a message when attempting to save a file that was marked read only: ! As of 1.48, you receive a different message that lacks an overwrite option: ! When a file is simply marked as read only, retrying as admin is not an appropriate option and fails to resolve the issue. Please restore Overwrite functionality as it is very useful for us that use archaic source control systems that rely on making files read only. VSCode Version: 1.48.0 OS Version: Windows 10 (1903) Steps to Reproduce: a file with the read only flag set a change to the file the file Does this issue occur on the latest insiders build?: Yes Does this issue occur when all extensions are disabled?: Yes
Thanks, a regression we can probably fix for recovery.
Was just about to post this as well. This changed about 3-4 weeks back in VSCode Insiders as well if that time frame helps.
Works great, I have verified the fix on windows with read-only files.
Code change:
if (seenVersions.has(version.version)) { return; } <del> seenVersions.add(version.version); </del> if (await this.isValidVersion(version, preRelease ? 'prerelease' : 'release', true, allTargetPlatforms, targetPlatform)) { result.push({ version: version.version, date: version.lastUpdated, isPreReleaseVersion: isPreReleaseVersion(version) }); <ins> seenVersions.add(version.version); </ins> } } catch (error) { /* Ignore error and skip version */ } }));

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version:Version: 1.64.0-insider (user setup) Commit: Date: 2022-01-30T20:09:01.122Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: to install version 1.8.0 (pre-release) or 1.8.1 (pre-release) of the C/C++ extension using VS Code (possible) versus VS Code Insiders (not possible). FYI, we have 1.8.2 (non-pre release) and 1.8.3 (pre-release) released.
Before I was getting this dialog After the fix I can nicely install -verified !
Closing as it appears to have been merged into release branch and verified
Code change:
* or via Size to Content Width */ fixedDimensions?: IFixedTerminalDimensions; <ins> /** * Opt-out of the default terminal persistence on restart and reload */ disablePersistence?: boolean; </ins> } export interface ICreateContributedTerminalProfileOptions {

Related discussion:
text: Currently we enable the persistent terminal/reconnect feature if a terminal is launched by an extension, unlike the env var relaunch where we disable outright because it can cause issues with the extension as it loses access to the terminal upon relaunch. Relaunching the PowerShell extension right now for example is a bit of a weird experience though because it creates the "PowerShell Integrated Console", and that reconnects upon reload but is no longer managed by the extension. Before reload: ! After reload it is restored, but no longer owned by the extension: ! Assigning to March for exploration. Thoughts
I think just allowing opt-out/opt-in on this behavior would be more than enough for PowerShell's case.
Has there been any progress on this? Now that persistent terminals are the default, this gets quite annoying and bothers users when extension-owned terminals come back but aren't actually connected.
No progress, we'll try get it in the next version
proposal:
Is this still ongoing and targeted for February?
Yes it is
Code change:
"list.activeSelectionBackground": "#707070", "list.focusBackground": "#707070", "list.inactiveSelectionBackground": "#4e4e4e", <del> "list.hoverBackground": "#707070", </del> <ins> "list.hoverBackground": "#444444", </ins> "list.highlightForeground": "#e58520", "button.background": "#565656", "editor.background": "#1e1e1e",

Related discussion:
text: Light themes have relatively low contrast for foreground and hover colors. ideally we do not need to create a new color. Either we can tweak the default list colors which are used for quick pick , SelectBox, Explorer et cetera. Light Default: ! Bad Hover contrast: ! I suggest we increase the contrast for the default listHoverBackground applicable to all users. For the foreground color we could make this slightly darker again for the default. I don't see why we would create new colors either, I think whatever is good for selectBox should be the same and good for the quick pick Tagging this "under discussion" hopefully that is correct.
I finally figured out the listFocusForeground has no default, it's inherited from Monaco-shell. If we define it and listFocusHover in light-defaults we won't create any other colors. Screenshot does not do justice to foreground, you probably want to try it on your own machines. Let me know what you guys think. Below light+ with foreground, hover darkened: foreground === originally hover === # !
can you make a PR for me to try out your suggested color change?
Code change:
osx: string[]; windows: string[]; }; <ins> altClickMovesCursor: boolean; </ins> macOptionIsMeta: boolean; macOptionClickForcesSelection: boolean; rendererType: 'auto' | 'canvas' | 'dom' | 'experimentalWebgl';

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.46.1 OS Version: Ubuntu 20.04 LTS x86_64 shell: bash When alt-clicking in terminal (e. g. to open a file or URL), it gets filled up with lots of or : ! Steps to Reproduce: integrated terminal (or, for a more practical example, in a temp dir) -click anywhere <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Having the same issue in WSL with Ubuntu 18.04 when alt+clicking any link.
Looks like this is an issue where the alt+click feature (move cursor when clicking) is conflicting with links, only when is used.
This issue also occurs on MacOS, only with Opt+Click instead of Alt+Click. I thought at first that this was related to the Opt+Click on a detected link in the terminal (since that is an Alt+Click on Windows/Linux). But this truly does occur when Opt+Clicking anywhere in the terminal while a command is waiting for input. I can confirm that this occurs on my MacOS regardless of the value of setting.
set in , now the way you click url is cmd + click, and it wont happen again
nope, that only slightly changes the junk that is dumped into the Terminal, but it doesn't get rid of it... With (default): With :
emmm, you say is right, i just change a way to open url in vscode terminal to avoid echo ^[[D but not fix it , this also occurs in , if you use option + click. by the way,my final setting as follows (if , vscode still let you click url with option + click ) !
Oh! That's a great observation, Alt+Click fills the terminal with junk even in the standard MacOS Terminal app and also in iTerm2. Now, I am aware that is originally reporting this for Ubuntu. I checked my Linux laptop (Fedora 31), and Alt+Click in the standard system terminal emulator does nothing. It only occurs in VSCode's terminal.
Code change:
osx: string[]; windows: string[]; }; <ins> altClickMovesCursor: boolean; </ins> macOptionIsMeta: boolean; macOptionClickForcesSelection: boolean; rendererType: 'auto' | 'canvas' | 'dom' | 'experimentalWebgl';

Related discussion:
text: But this still makes me wonder if all of this is system-level issues, or perhaps terminal "emulator" issues, not really a VSCode issue. Hard to know. But the Microsoft devs would know.
As for your workaround, thank you so much for that!!! I still don't see any change in VSCode's behavior when using , but changing definitely avoids the core issue. I hope you don't mind me describing in more detail... According to , "The Go To Definition and Open Link gestures will also respect this setting and adapt such that they do not conflict. For example, when the setting is ctrlCmd, multiple cursors can be with Ctrl/Cmd+Click, and opening links or going to definition can be invoked with Alt+Click." You probably did what I did when originally installing VSCode... I'm using to using Ctrl+Click in Linux and Cmd+Click in MacOS to multi-select files in Finder, items in a list, etc. So I set to be . However, this means that attempting to click on a link in the terminal (for example, an error message referencing the offending line in your source code) requires the use of the other shortcut (Alt + Click). Since it seems that Linux and MacOS have various strange behaviors when Alt + Clicking in a terminal, you are suggesting we switch back to the default . Now we'll use Ctrl+Click / Cmd+Click to follow links in the Terminal, avoiding all that ^[[D^[[D^[[D^[[D nonsense that sometimes causes the terminal to hang. For multi-selecting in the editor window, we'll have to get used to using Alt + Click for that, but in my opinion, that is better than having terminal hanging issues unexpectedly.
So to clarify what I originally posted to Alt+Click will still cause junk to fill the screen, regardless of the value of "editor.multiCursorModifier" setting. However, the above workaround means we don't need the Alt+Click anymore.
it's a feature that's sending keys to move the terminal cursor to the position of the mouse cursor. It needs support in whatever program is running in the terminal though which is why you might see the printed, we cannot detect this support though. The advice right now is to avoid alt clicking if it doesn't work in the program.
Code change:
osx: string[]; windows: string[]; }; <ins> altClickMovesCursor: boolean; </ins> macOptionIsMeta: boolean; macOptionClickForcesSelection: boolean; rendererType: 'auto' | 'canvas' | 'dom' | 'experimentalWebgl';

Related discussion:
text: could you clarify... Is this a feature in Linux that's doing it, and vscode is not able to see that it's happening? Or do you mean this is a feature in vscode to move the cursor, and vscode is not able to tell if the terminal shell supports it?
it's a feature in , you can see the PR here
what an interesting feature, and I never even knew that was there. Thank you for the perspective. I looked through that PR and searched the settings in VSCode; unfortunately, there doesn't seem to be any way to disable that cursor-moving feature.
Yeah, that feature might be useful but the ability to disable it or, even better, change a modifier to another one (so that it doesn't conflict with the “open file in editor” one) :)
I'm seeing this happen regardless of the setting, on Ubuntu 18.04
Just to inform that is waiting for a community PR for this.
Um, how is project related to VSCode?
Hey great question. The package is a direct dependency as you can see here: means that the behavior will first have to be patched in the underlying package and then it will likely be made available through a setting in VSCode in a future release.
I opened a PR with which would make it possible to disable this feature:
The PR was merged. What is required in order to pass the new option to in VSCode?
I meant no offense; perhaps my "Um" conveyed an unintended tone. I was simply asking, as a non-developer user who has never looked through the VSCode codebase, but is experiencing the OP's issue... how an xterm project would be blocked by an issue in VSCode.
Ah sorry, I assumed you were familiar with the package because of your previous posts (and although it’s no excuse) I’ve learned my lesson and will henceforth refrain from posting prior to my morning coffee - the tone was indeed unnecessary. The original message has been duly modified.
So, does anyone know how to disable it in vscode?
The problem with has been fixed. Could you kindly suggest what are our next steps here?
Sorry, I've been out for a while. We updated in vscode yesterday, so the next steps are to expose it as a setting in vscode. Searching for a similar setting should show how/where to do something like this.
Code change:
osx: string[]; windows: string[]; }; <ins> altClickMovesCursor: boolean; </ins> macOptionIsMeta: boolean; macOptionClickForcesSelection: boolean; rendererType: 'auto' | 'canvas' | 'dom' | 'experimentalWebgl';

Related discussion:
text: if no one picks this up from the community it would be a good change for you in debt week.
Thank you so much! :tada:
Once it's released in insider's, to verify, set
Hi! Thanks for fixing this Just to understand, may I ask: Why will the future setting default to true? One year ago the problem didn't happen on a fresh install, so why not fix the regression Why is this issue closed but the bug still exists in the latest Insiders? Thank you
As far as I understand this is a new feature in . The special characters only get displayed in certain situations (probably when the running command prevents the shell from moving the cursor). Also the default setting for multicursor is <kbdCtrl</kbdso you would not use <kbdAlt</kbdnormally unless you want exactly this new feature.
I just want to open a file from within the terminal out of the box ! I typically do when running in watch mode On Linux the shortcut is Ctrl+Alt+Click even if the screenshot says otherwise Can users do this without having to find this issue and the corresponding setting? Also, when the filling happens, often the terminal gets stuck, I cannot kill the process with anymore, should I open another issue about this?
Thank you for voicing your concerns - I have to agree that OFF should be the default behavior as Alt-Click is mapped to the file open command in VS Code, and ON is therefore most likely to be the undesired behavior.
<kbdAlt</kbd+<kbdClick</kbdis not the default. The default for opening links and definitions is the one key not used by the multicursor modifier which is by default <kbdAlt</kbd. You can confirm this by looking in the docs or viewing the default value in the settings UI.
Just tried in Portable mode on Linux with no settings nor extension installed. The problem still reproduces. fixes the problem but I'm not sure how new users would know about this
You may be misunderstanding what this option attempts to solve. It's unfortunate that the name was chosen for the setting, since the setting is not about vs. , but rather about enabling or disabling the pseudo-mouse-cursor-moving feature in xTerm entirely. I concur with go back a year and VSCode didn't have this annoying broken "feature" of the terminal.