jiebi/CodeConvo huggingface dataset:
Code change:
const editorOptions = this._configurationService.getValue<IEditorOptions>('editor'); const xterm = new Terminal({ <ins> altClickMovesCursor: config.altClickMovesCursor, </ins> scrollback: config.scrollback, theme: this._getXtermTheme(), drawBoldTextInBrightColors: config.drawBoldTextInBrightColors,

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:
const editorOptions = this._configurationService.getValue<IEditorOptions>('editor'); const xterm = new Terminal({ <ins> altClickMovesCursor: config.altClickMovesCursor, </ins> scrollback: config.scrollback, theme: this._getXtermTheme(), drawBoldTextInBrightColors: config.drawBoldTextInBrightColors,

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.
Code change:
const editorOptions = this._configurationService.getValue<IEditorOptions>('editor'); const xterm = new Terminal({ <ins> altClickMovesCursor: config.altClickMovesCursor, </ins> scrollback: config.scrollback, theme: this._getXtermTheme(), drawBoldTextInBrightColors: config.drawBoldTextInBrightColors,

Related discussion:
text: Now that we've recognized it's broken and updated the xTerm dependency to a version that allows us to get rid of the broken "feature", the default behavior from a VSCode perspective should be to have the feature disabled, since we really never wanted it in the first place. Also, as pointed out, when the typical user hits this strange behavior, are we just expecting them to "VSCode terminal fills with ^[[D^[[D^[[D^[[D^[[D^[[D and locks up" into Google and hope for the best? This "feature" does not work 100%. It should be considered beta/experimental and disabled by default.
I can attempt a PR that Changes the setting name to perhaps (something that doesn't mention vs. ) Default value of But I'm not sure how the open-source community handles requests like this. Any advice on how to proceed? Or is this a closed/merged PR and conversation over?
After re-reading this I realized this is capturing the bug (alt+click conflict) as well as the feature request (new setting), I thought they were separate issues. to fix let's: Override the value of to be false when . Document this override in 's description, that also makes the name correct as this feature only ever works on alt+click. I think that name is good as it aligns with . we're a little tight on time as we're closing in on the end of the iteration, can handle it
Thanks, and I'm really looking forward to being able to click links in the terminal again.
/verified
Code change:
args.push('--ignore-submodules'); } <del> if (opts?.similarityThreshold) { </del> <ins> // --find-renames option is only available starting with git 2.18.0 if (opts?.similarityThreshold && this._git.compareGitVersionTo('2.18.0') !== -1) { </ins> args.push(`--find-renames=${opts.similarityThreshold}%`); }

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: 1.79.0-insider OS Version: macOS 13.3.1 Steps to Reproduce: VSCode in a computer with a relatively old version of Git (2.16.2 does it). a project under version control. control fails silently and only shows the Publish button. Trying to publish causes an error. This seems to be related to a change that makes use of the option in , which doesn't seem to be supported by old-ish Git.
sorry about this. I will try to get this fixed this week.
I am also experiencing the same issue. VS Code Version: 1.79.0-insider OS: Windows_NT x64 10.0. git version 2.17.1
It looks like the option was in git 2.18.0. Ideally you would want to keep your git installation up to date to keep up with the security fixes. Having said that I do understand that there are scenarios in which one cannot install the latest git release, so I have pushed a fix for this issue. The fix will be included in the next Insiders release.
Thanks a lot! I agree with keeping git up to date. Unfortunately I use VSCode with the remote extension in many servers where I don't have control of what version of Git is installed, so having at least some basic Git functionality there is much appreciated.
Code change:
args.push('--ignore-submodules'); } <del> if (opts?.similarityThreshold) { </del> <ins> // --find-renames option is only available starting with git 2.18.0 if (opts?.similarityThreshold && this._git.compareGitVersionTo('2.18.0') !== -1) { </ins> args.push(`--find-renames=${opts.similarityThreshold}%`); }

Related discussion:
text: Hi, I encountered the same issue with my VSCode + WSL1 (I haven't upgraded to WSL2 for some reason) git version: 2.11.0 VSCode Version: 1.79.0
could you please share the complete contents of the ? What version of git are you running inside WSL? This flag should only be in case you have a version of git that support it.
Same issue here
Affecting me too. This seems like a major breaking change. Is there a bugfix release planned? Thanks.
could you please share more about your environment? What version of git are you running (git --version). Are you also using WSL, or any other remote environments? Anything that helps me reproduce the issue would be extremely valuable (ex: the contents of ). Thanks!
Thanks Ladislau Using git 2.17. I don't want to upgrade to insiders build Get Outlook for iOS
could you please run and share the exact output. My current hypothesis is that for some reason we are unable to correctly detect the version number and that is why we incorrectly add the flag.
Let's continue the investigation in this issue Thanks!
Code change:
<del> 2019-08-30T20:24:23.714Z </del> <ins> 2020-10-05T20:24:23.714Z </ins>

Related discussion:
text: Issue Type: <bBug</bPlotting a large plot (e.g seaborn pairplot) with many columns via jupyter interactive mode and then viewing in plots viewer is very slow to view/zoom/pan VS Code version: Code 1.45.1 (, 2020-05-14T08:27:35.169Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ vscode-django0.20.0 vscode-markdownlint0.36.1 python-extension-pack1.6.0 gc-excelviewer2.1.35 r1.4.2 vsc-python-indent1.10.1 MagicPython1.1.0 anaconda-extension-pack1.0.1 python2020.6. vscode-yaml0.8.0 vscodeintellicode1.2.8 </details<!-- generated by issue reporter --
This sounds like a problem caused by the extension providing the Jupyter Notebooks. Please file the issue there.
Hi same problem here, are there any workarounds in place for this?
I've moved to
Code change:
<del> 2019-08-30T20:24:23.714Z </del> <ins> 2020-10-05T20:24:23.714Z </ins>

Related discussion:
text: Following the discussion in Repro steps on Windows: use a monospace font, make sure ligatures are not used, etc. (i.e. default editor related settings) change the scale setting of the display the editor decorations / selection should render correctly (on top of the correct text) (the problem was that the font measurements done with a certain display scale were used across all display scales).
Code change:
type: 'boolean', default: true, description: nls.localize('comments.visible', "Controls the visibility of the comments bar and comment threads in editors that have commenting ranges and comments. Comments are still accessible via the Comments view and will cause commenting to be toggled on in the same way running the command "Comments: Toggle Editor Commenting" toggles comments.") <ins> }, 'comments.maxHeight': { type: 'boolean', default: true, description: nls.localize('comments.maxHeight', "Controls whether the comments widget scrolls or expands.") </ins> } } });

Related discussion:
text: PR introduced a max-height on comments, which goes against my team's use case when using the . Since our tours have animated GIFs that support our hands-on coding labs, the reduced max-height makes it impossible for a user to see entire images in the comment frame at once, which imposes a negative learner experience. (See: for comparison across versions). Proposed feature is to allow a user to set a max-height rather than imposing a max-height.
I also think it should be settable through the API. My original on the PR has a comment exchange with about this at the place where I originally hardwired it.
Generally we try not to add API unless we see a clear case for having it. At the time suggested the max height I wasn't aware of a use case that would require a comment peek view to have a larger size. your case makes sense, and makes the case for having API for this. I would make this API rather than user configurable.
Yes, making the max-height configurable via the API makes perfect sense, since any extension can be configured with that functionality to set a max-height attribute that makes sense for the use case. Would the default behavior go back to expanding the height with the content?
I'm not sure yet which would be default. I will discuss with our UX folks and see what they prefer.
My humble preference would be to adopt the old behavior as the default. Though the CodeTour extension is open source, it’s only seen one update in the past year. My team has a stale PR from 2021 on the CodeTour repo that was never commented on, so I’m afraid that even if we opened a PR with a fix for the max-height problem, it might not ever get accepted and merged. On the other hand, my team has been discussing forking CodeTour so that we can control the addition of new functionality and bug fixes.
There wasn't enough interest in adding API for this, so I the user setting .
thanks! Is a boolean? If so, is the default (maintaining the as by default) or (no defined?
It is a boolean and the default is true, meaning the max height of a comment will be 20em.
<!-- 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.
Code change:
type: 'boolean', default: true, description: nls.localize('comments.visible', "Controls the visibility of the comments bar and comment threads in editors that have commenting ranges and comments. Comments are still accessible via the Comments view and will cause commenting to be toggled on in the same way running the command "Comments: Toggle Editor Commenting" toggles comments.") <ins> }, 'comments.maxHeight': { type: 'boolean', default: true, description: nls.localize('comments.maxHeight', "Controls whether the comments widget scrolls or expands.") </ins> } } });

Related discussion:
text: If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified Works great! Thanks!
Thanks for verifying!
Code change:
import { IPreferencesService } from 'vs/workbench/services/preferences/common/preferences'; import { ILogService } from 'vs/platform/log/common/log'; import { IChatService } from 'vs/workbench/contrib/chat/common/chatService'; <ins> import { CONTEXT_IN_CHAT_INPUT } from 'vs/workbench/contrib/chat/common/chatContextKeys'; </ins> CommandsRegistry.registerCommandAlias('interactiveEditor.start', 'inlineChat.start'); CommandsRegistry.registerCommandAlias('interactive.acceptChanges', ACTION_ACCEPT_CHANGES);

Related discussion:
text: Testing Repro: /explain in inline chat to get a long response. using to focus the last response (does not work) to focus the last response using to scroll up in list view of chat messages. (does not work)
Same for panel chat. I believe the keybinding simply isn't bound
You may have to press it twice, once to move the cursor to the top of the editor, and then another time to trigger the chat keybinding, does that work? It's working fine for me.
Oh, not in inline chat though
I can't remember what terminal chat looked like in March, do you still want this disabled? I think we probably want it enabled in all chat widgets now:
I fixed this so that cmd+up/down will work in the terminal and inline chat widgets. But in the terminal, once the list is focused, then the arrow keys still navigate history. It looks like the terminal widget is registering a bunch of its own commands for history and for moving focus around. You shouldn't need to do that anymore, since you can use the commands that the ChatWidget has.
Code change:
private _lastAcceptedCompletionTimestamp: number = 0; private _lastUserData?: string; <ins> isPasting: boolean = false; </ins> static requestCompletionsSequence = 'x1b[24~e'; // F12,e static requestGlobalCompletionsSequence = 'x1b[24~f'; // F12,f static requestEnableGitCompletionsSequence = 'x1b[24~g'; // F12,g

Related discussion:
text: Steps to Reproduce: text into PowerShell (with Terminal suggest enabled) see batched pasting behavior
maybe related to
Haha, I think this is it triggering completions while the pasted text is being send then kicking in. Pastes should never trigger completions so let's track that here.
When verifying make sure you're on macOS.
Code change:
"keybindingLabel.foreground": "#000000e4", "list.activeSelectionBackground": "#e8e8e8", "list.activeSelectionForeground": "#000000", <del> "list.activeSelectionIconForeground": "#000000", </del> "list.hoverBackground": "#f2f2f2", "menu.border": "#D4D4D4", "notebook.cellBorderColor": "#E8E8E8",

Related discussion:
text: Light Theme the Extensions view the Extension item in the list -all letters turn black, the contrast is not good !
Looks like these buttons are inheriting the codicon styling, and as a result, the color. I removed it from Light+ V2 to reset it back to null. Ideally this button wouldn't use codicon styling cc
Code change:
if (selections) { const ranges: ILineRange[] = []; for (const selection of selections) { <del> let endLineNumber = selection.endLineNumber; if (selection.endColumn === 1) { --endLineNumber; } const startLineNumber = selection.startLineNumber; ranges.push(endLineNumber >= selection.startLineNumber ? { startLineNumber, endLineNumber } : { endLineNumber, startLineNumber }); </del> <ins> const { startLineNumber, endLineNumber } = selection; ranges.push(endLineNumber >= startLineNumber ? { startLineNumber, endLineNumber } : { endLineNumber, startLineNumber }); </ins> } foldingModel.removeManualRanges(ranges); foldingController.triggerFoldingModelChanged();

Related discussion:
text: Remove Manual Folding Range doesn't work Originally posted by in select a range in the editor invoke . Selection turns into a folding range put the cursor at the beginning of the collapsed line invoke . Should remove the manual folding range
It works when the cursor is at the second column or to the right of that, but not when it's right at the beginning of the line, which is exactly where it is placed after running the create manual folding range command.
Code change:
const historyItemGroupHoverLabelForegroundColor = colorTheme.getColor(historyItemGroupHoverLabelForeground); markdown.appendMarkdown(`nn---nn`); <del> markdown.appendMarkdown(historyItem.labels.map(label => { </del> <ins> markdown.appendMarkdown(historyItemLabels.map(label => { </ins> const historyItemGroupHoverLabelBackgroundColor = label.title === currentHistoryItemGroup?.name ? historyItemGroupLocalColor : label.title === currentHistoryItemGroup?.remote?.name ? historyItemGroupRemoteColor :

Related discussion:
text: Testing I find it a little weird how there is a cloud badge on the list item and that represents 2 different items origin/main and origin/HEAD in the hover? <img width="1031" alt="Screenshot 2024-08-27 at 10 31 23 AM" src=""Should these be different icons? Should it be a single item ? Should they be the same color?
Code change:
$openTunnel(tunnelOptions: TunnelOptions, source: string | undefined): Promise<TunnelDto | undefined>; $closeTunnel(remote: { host: string; port: number }): Promise<void>; $getTunnels(): Promise<TunnelDescription[]>; <del> $setTunnelProvider(features?: TunnelProviderFeatures): Promise<void>; </del> <ins> $setTunnelProvider(features: TunnelProviderFeatures | undefined, enablePortsView: boolean): Promise<void>; </ins> $setRemoteTunnelService(processId: number): Promise<void>; $setCandidateFilter(): Promise<void>; $onFoundNewCandidates(candidates: CandidatePort[]): Promise<void>;

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 ?