jiebi/CodeConvo huggingface dataset:
Code change:
id: MenuId.NotebookCellTitle, when: ContextKeyExpr.and(NOTEBOOK_EDITOR_FOCUSED, NOTEBOOK_EDITOR_EDITABLE), group: CellOverflowToolbarGroups.Copy, <ins> order: 3, </ins> }, keybinding: platform.isNative ? undefined : { when: ContextKeyExpr.and(NOTEBOOK_EDITOR_FOCUSED, ContextKeyExpr.not(InputFocusedContextKey)),

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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce: a ntoebook click on a cell, and notice the order of the cell actions same entries for regular editors is All places the order is We might want to consider changing this.
is this a papercut or ux issue I'm concerned that changing this now could result in issues due to muscle memory (i.e. users being used to this order). Thus changing this might not be a good idea, then again, i don't think it is. Thoughts?
discussed with team, Lets change this
Code change:
return this._overflowContainer; } <del> override getControl(): NotebookEditorWidget | undefined { return undefined; </del> <ins> override getControl(): INotebookTextDiffEditor | undefined { return this; </ins> } protected override setEditorVisible(visible: boolean, group: IEditorGroup | undefined): void {

Related discussion:
text: Testing Ideally there would be commands to navigate between changes. And they might deserve an action in the diff title bar. Same as the editor diff experience. !
Why is for these commands? I would expect them to be available from the command palette, since in a regular text editor Show Previous Change and Show Next Change both appear.
Code change:
return this._overflowContainer; } <del> override getControl(): NotebookEditorWidget | undefined { return undefined; </del> <ins> override getControl(): INotebookTextDiffEditor | undefined { return this; </ins> } protected override setEditorVisible(visible: boolean, group: IEditorGroup | undefined): void {

Related discussion:
text: Testing Notice that the scroll range is below the decorations, even though they're on screen <img width="717" alt="image" src="https://user-"Meanwhile if I scroll to where they're shown, they aren't in viewport <img width="713" alt="image" src="https://user-"This was on the following gif: <img width="401" alt="image" src="https://user-"
Code change:
constructor( private readonly _diff: IMergedEnvironmentVariableCollectionDiff, private readonly _terminalId: number, <del> @ITerminalService private readonly _terminalService: ITerminalService </del> <ins> @ITerminalService private readonly _terminalService: ITerminalService, @IExtensionService private readonly _extensionService: IExtensionService </ins> ) { }

Related discussion:
text: Testing Show extension display name instead of extension id. You can also make them links to open the extension editor. <img width="522" alt="image" src="https://user-"
what's the right way to do this? I had a look and could only see async methods to do this which seemed odd to me (and would require some refactoring to get the tooltip to work with async).
1 I see this as well
There are multiple ways depending upon the source of this extension id. Since it is a running extension, I would prefer to use this api since you do not want to have async
thanks will use that. You don't have an id -name map to avoid iterating over it multiple times though?
There exists one, but it is async
Code change:
resetScrollbarVisibility(): void { this._wrapperElement.classList.remove('force-scrollbar'); } <ins> setParentContextKeyService(parentContextKeyService: IContextKeyService): void { this._scopedContextKeyService.updateParent(parentContextKeyService); } </ins> } class TerminalInstanceDragAndDropController extends Disposable implements dom.IDragAndDropObserverCallbacks {

Related discussion:
text: Type: <bBug</bPinning a terminal editor does not set some of the context variables that are normally set when pining a text editor. Here are the ones I've noticed: activeEditorIsDirty activeEditorIsFirstInGroup activeEditorIsLastInGroup activeEditorIsNotPreview activeEditorIsPinned In the case of activeEditorIsPinned this makes it impossible to detect if the current terminal editor is pinned. Since there is no command to toggle the pin on an editor this means it's not possible to create a single keybinding that can intelligently pin and unpin the current terminal editor. In the case of activeEditorIsLastInGroup it means it's not possible to create a keybinding to move a terminal editor out of the "pinned section" of editors in the current group. When editors are pinned they are moved to the left side of the current editor group. When moving an editor to the previous position in the current group if it happens to cross into the pinned section it will become pinned. But the inverse is not possible: you cannot move a pinned editor out of the pinned section unless there happens to be something else unpinned to the right of it. So I have a keybinding to unpin the current editor if it's the last editor in the current group. Since terminal editors don't set the required context they break this binding. Steps to Repro: Open a terminal in the editor area Pin the terminal editor Inspect context keys Notice activeEditorIsPinned is not set VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
The type of editor should not play any role in this. I somewhat doubt this is a bug in our code, so setting label that we need confirmation. Open for help, investigation, suggested fixes, PR.
This one I cannot confirm or reproduce. See this gif where I open a terminal, pin it and then inspect the context keys: ! What are some exact steps?
Looks like it depends where you click when inspecting context keys.
Code change:
resetScrollbarVisibility(): void { this._wrapperElement.classList.remove('force-scrollbar'); } <ins> setParentContextKeyService(parentContextKeyService: IContextKeyService): void { this._scopedContextKeyService.updateParent(parentContextKeyService); } </ins> } class TerminalInstanceDragAndDropController extends Disposable implements dom.IDragAndDropObserverCallbacks {

Related discussion:
text: I'm clicking inside the terminal, where my cursor is, because I'm attempting to make keybindings that work when using the terminal. You're clicking the editor tab. So it appears the context is set for the editor, but when you focus the terminal within it that context is removed. Interestingly I still see some of the context so not all of it is removed.
Quite likely that the terminal itself sets its own context keys.
<!-- 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!
/verified, but while confirming the fix I noticed more issues with these context keys
Code change:
}, dataOverrides); if (issueReporterData.extensionId) { <del> const extensionExists = extensionData.some(extension => extension.id === issueReporterData.extensionId); </del> <ins> const extensionExists = extensionData.some(extension => extension.id.toLowerCase() === issueReporterData.extensionId?.toLowerCase()); </ins> if (!extensionExists) { console.error(`Extension with ID ${issueReporterData.extensionId} does not exist.`); }

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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce: type and enter that issue reporter is opened with correct extension selected. !
Code change:
//#region Workspaces History async addRecentlyOpened(recentToAdd: IRecent[]): Promise<void> { <del> const workspaces: Array<IRecentFolder | IRecentWorkspace> = []; const files: IRecentFile[] = []; </del> <ins> let workspaces: Array<IRecentFolder | IRecentWorkspace> = []; let files: IRecentFile[] = []; </ins> for (const recent of recentToAdd) { // Workspace if (isRecentWorkspace(recent)) { <del> if (!this.workspacesManagementMainService.isUntitledWorkspace(recent.workspace) && this.indexOfWorkspace(workspaces, recent.workspace) === -1) { </del> <ins> if (!this.workspacesManagementMainService.isUntitledWorkspace(recent.workspace) && !this.containsWorkspace(workspaces, recent.workspace)) { </ins> workspaces.push(recent); } } // Folder else if (isRecentFolder(recent)) { <del> if (this.indexOfFolder(workspaces, recent.folderUri) === -1) { </del> <ins> if (!this.containsFolder(workspaces, recent.folderUri)) { </ins> workspaces.push(recent); } } // File else { <del> const alreadyExistsInHistory = this.indexOfFile(files, recent.fileUri) >= 0; </del> <ins> const alreadyExistsInHistory = this.containsFile(files, recent.fileUri); </ins> const shouldBeFiltered = recent.fileUri.scheme === Schemas.file && WorkspacesHistoryMainService.COMMON_FILES_FILTER.indexOf(basename(recent.fileUri)) >= 0; if (!alreadyExistsInHistory && !shouldBeFiltered) {

Related discussion:
text: The steps are outlined here:
<!-- 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!
/verified
Thanks!
Code change:
this._widget?.inlineChatWidget.updateInfo(!this._activeSession.lastExchange ? localize('thinking', "Thinkingu2026") : ''); this._ctxHasActiveRequest.set(true); <del> const reply = await raceCancellationError(Promise.resolve(task), requestCts.token); </del> <ins> const reply = await raceCancellationError(Promise.resolve(task), this._activeRequestCts.token); </ins> if (progressiveEditsQueue.size > 0) { // we must wait for all edits that came in via progress to complete await Event.toPromise(progressiveEditsQueue.onDrained);

Related discussion:
text: use generate cell in notebooks make a request while the request is active press stop a bunch of errors are printed
It seems not wise at all to maintain my own *chatcontroller. I'd love to look into how do I ensure I reuse the most of Inline Chat Controller later.
Is the generate cell feature just with using ctrl+i from within a cell body? Not sure how I can trigger it.
Code change:
import { extractGitHubRemotesFromGitConfig } from 'vs/workbench/contrib/url/browser/trustedDomains'; function linkAllowedByRules(link: string, rules: string[]) { <del> assert.ok(isURLDomainTrusted(URI.parse(link), rules), `Linkn${link}n should be protected by rulesn${JSON.stringify(rules)}`); </del> <ins> assert.ok(isURLDomainTrusted(URI.parse(link), rules), `Linkn${link}n should be allowed by rulesn${JSON.stringify(rules)}`); </ins> } function linkNotAllowedByRules(link: string, rules: string[]) { <del> assert.ok(!isURLDomainTrusted(URI.parse(link), rules), `Linkn${link}n should NOT be protected by rulesn${JSON.stringify(rules)}`); </del> <ins> assert.ok(!isURLDomainTrusted(URI.parse(link), rules), `Linkn${link}n should NOT be allowed by rulesn${JSON.stringify(rules)}`); </ins> } suite('GitHub remote extraction', () => {

Related discussion:
text: Issue Type: <bBug</bWrite http://192.168.1.7:3000/ into a text file. Command-click it to try to open the link. You will get an alert asking whether you want to open the external website. Click “Configure Trusted Domains”. <img width="1025" alt="link and dialog asking to confirm opening external website" src="https://user-"Look at the second option in the menu. It says “Trust 1.7:3000 and all its subdomains”. But 1.7:3000 is not a valid address. <img width="1024" alt="link and menu with buggy entry “Trust 1.7:3000 and all its subdomains”" src="https://user-"I can only guess that VS Code thinks that “7” is a TLD and “1.7” is a full domain name. What I actually want to do is whitelist opening all links to IP addresses like . In other words, white-list the subnet . At least, I think that makes sense. But I am not a network engineer, so if it makes more sense to recommend to the user whitelisting some other subnet such as , or whitelisting only the address but on any port, that would be fine too. VS Code version: Code 1.40.1 (, 2019-11-13T16:47:44.719Z) OS version: Darwin x64 18.7.0 <!-- generated by issue reporter --
Code change:
return null; } } <del> /** * Returns url from link as link may contain line and column information. * * @param link url link which may contain line and column number. */ extractLinkUrl(link: string): string | null { const matches: string[] | null = this._localLinkRegex.exec(link); if (!matches) { return null; } return matches[1]; } </del> } export interface ILineColumnInfo {

Related discussion:
text: Originally posted on without success. <!-- 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.69.2 OS Version: linux Steps to Reproduce: project has files like "Bar`1.cs" to represent generic types, as is done in the dotnet SDK build task contains "problemMatcher": { "base": "$msCompile" } When such a file has errors/warnings, I get this: is fine. But I cannot control-click on that filename to open it. The file's path is not underlined as normal - there is a clickable part before the bactick, and after. Someone from SO offered this guess: " probably backticks are not part of the regex that matches the filepath, or backticks are not in the w regex set"
I can reproduce this, it is correctly validating the link, but it then recognizes it as a folder: ! I guess nothing happens if Test doesn't exist? As for the fallback "word links", you can support this type of link if you remove backtick from word separators:
This falls apart when converting the link to a URI in !
And that happens because backticks aren't allowed in the local path regex:
Thanks
Code change:
type: 'boolean', default: false }, <ins> 'terminal.integrated.altClickMovesCursor': { description: localize('terminal.integrated.altClickMovesCursor', "If enabled, alt/option + click will move the prompt cursor to position underneath the mouse. This may not work reliably depending on your shell."), type: 'boolean', default: true }, </ins> 'terminal.integrated.copyOnSelection': { description: localize('terminal.integrated.copyOnSelection', "Controls whether text selected in the terminal will be copied to the clipboard."), type: 'boolean',

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:
type: 'boolean', default: false }, <ins> 'terminal.integrated.altClickMovesCursor': { description: localize('terminal.integrated.altClickMovesCursor', "If enabled, alt/option + click will move the prompt cursor to position underneath the mouse. This may not work reliably depending on your shell."), type: 'boolean', default: true }, </ins> 'terminal.integrated.copyOnSelection': { description: localize('terminal.integrated.copyOnSelection', "Controls whether text selected in the terminal will be copied to the clipboard."), type: 'boolean',

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:
type: 'boolean', default: false }, <ins> 'terminal.integrated.altClickMovesCursor': { description: localize('terminal.integrated.altClickMovesCursor', "If enabled, alt/option + click will move the prompt cursor to position underneath the mouse. This may not work reliably depending on your shell."), type: 'boolean', default: true }, </ins> 'terminal.integrated.copyOnSelection': { description: localize('terminal.integrated.copyOnSelection', "Controls whether text selected in the terminal will be copied to the clipboard."), type: 'boolean',

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.