jiebi/CodeConvo huggingface dataset:
Code change:
return this._repository.getMergeBase(ref1, ref2); } <ins> tag(name: string, upstream: string): Promise<void> { return this._repository.tag(name, upstream); } deleteTag(name: string): Promise<void> { return this._repository.deleteTag(name); } </ins> status(): Promise<void> { return this._repository.status(); }

Related discussion:
text: <!-- 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. --When using the Git API extension Repository interface and the corresponding are not exposed. Having access to these functions would be very helpful, since using with returns early and doesn't provide useful errors.
Verified by code review
Code change:
const stylingSchemeEntry = getStylingSchemeEntry(description, deprecationMessage); this.tokenStylingSchema.properties[id] = stylingSchemeEntry; <del> this.typeHierarchy = {}; </del> <ins> this.typeHierarchy = Object.create(null); </ins> } public registerTokenModifier(id: string, description: string, deprecationMessage?: string): void {

Related discussion:
text: Issue Type: <bBug</bSemantic token colorization fails when a token type ID matching any object.prototype property name is provided. Some examples are: , and . is the most problematic name since it is likely to be used as a token type ID. Any string should be able to be used as a token type ID without causing the colorization to fail. Because tries to call on what was thought to be a but was actually a , which throws a TypeError and causes the colorization to fail. The easiest way is probably to use a instead of an object for . Another solution might be to instantiate using instead of an object literal in order to avoid the object.prototype. VS Code version: Code 1.47.2 (, 2020-07-15T18:22:15.161Z) OS version: Linux x64 4.19.0-9-amd64 <!-- generated by issue reporter --
Code change:
this._register(this.viewModel.searchResult.onChange((event) => this.onSearchResultsChanged(event))); this._register(this.onDidChangeBodyVisibility(visible => this.onVisibilityChanged(visible))); <ins> this.updateIndentStyles(this.themeService.getFileIconTheme()); this._register(this.themeService.onDidFileIconThemeChange(this.updateIndentStyles, this)); } private updateIndentStyles(theme: IFileIconTheme): void { this.resultsElement.classList.toggle('hide-arrows', this.isTreeLayoutViewVisible && theme.hidesExplorerArrows); </ins> } private onVisibilityChanged(visible: boolean): void {

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.72.2 OS Version: Windows 11 / MacOS Monterey Steps to Reproduce: . the icons using the command. that the arrows are still not hidden. The vscode-icons extension has a setting called , which, as the name suggests, hides the explorer arrows next to the project folders. This look something like this: ! With the introduction of the tree mode in the search panel, I would not have expected to see any explorer arrows there. Alas, the panel has the search arrows, regardless of the extension setting. ! I already opened an issue on the vscode-icons repository, which you can find .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.72.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Still happens on 1.72.2!
Code change:
if (activationEventsNode?.type === 'array' && activationEventsNode.children) { for (const activationEventNode of activationEventsNode.children) { const activationEvent = getNodeValue(activationEventNode); <ins> // Redundant Implicit Activation </ins> if (info.implicitActivationEvents?.has(activationEvent) && redundantImplicitActivationEventPrefixes.some((prefix) => activationEvent.startsWith(prefix))) { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); diagnostics.push(new Diagnostic(new Range(start, end), redundantImplicitActivationEvent, DiagnosticSeverity.Warning)); <del> } else { for (const implicitActivationEventPrefix of reservedImplicitActivationEventPrefixes) { if (activationEvent.startsWith(implicitActivationEventPrefix)) { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); diagnostics.push(new Diagnostic(new Range(start, end), implicitActivationEvent, DiagnosticSeverity.Error)); } </del> <ins> } // Reserved Implicit Activation for (const implicitActivationEventPrefix of reservedImplicitActivationEventPrefixes) { if (activationEvent.startsWith(implicitActivationEventPrefix)) { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); diagnostics.push(new Diagnostic(new Range(start, end), implicitActivationEvent, DiagnosticSeverity.Error)); </ins> } } <ins> // Star activation if (activationEvent === '*') { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); const diagnostic = new Diagnostic(new Range(start, end), starActivation, DiagnosticSeverity.Information); diagnostic.code = { value: 'star-activation', target: Uri.parse('https://code.visualstudio.com/api/references/activation-events#Start-up'), }; diagnostics.push(diagnostic); } </ins> } } }

Related discussion:
text: We want to discourage extension authors from using activation. We should consider adding a diagnostic warning similar to the one we have for implicit events.
Is it not enough that provides the same prompt in terminal when packaging/publishing an extension?
at that stage in the development lifecycle, authors are more likely to just ignore the warning from vsce. Additionally, they might be publishing in CI and might not see it there either.
verification: in an extension, put in activation events see this: !
Code change:
public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

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:
public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

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:
public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

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:
public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

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:
public updateConfig(): void { const config = this._configHelper.config; <ins> this._safeSetOption('altClickMovesCursor', config.altClickMovesCursor); </ins> this._setCursorBlink(config.cursorBlinking); this._setCursorStyle(config.cursorStyle); this._setCursorWidth(config.cursorWidth);

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:
alwaysFocused: true, verticalScrollMode: ScrollbarVisibility.Visible, ariaLabel: nls.localize('treeAriaLabel', "Quick Picker"), <del> keyboardSupport: this.options.keyboardSupport </del> <ins> keyboardSupport: this.options.keyboardSupport, preventRootFocus: true </ins> }); this.treeElement = this.tree.getHTMLElement();

Related discussion:
text: While testing . VSCode Version: Code - Insiders 1.15.0-insider (, 2017-08-01T05:07:59.267Z) OS Version: Darwin x64 16.7.0 Steps to Reproduce: 3 terminals from the command palette <kbdArrowDown</kbdto the last terminal in the switcher <kbdTab</kbdto rename the terminal -keyboard focus disappears from the input box (and seems to be nowhere). I need a second <kbdTab</kbdto move the keyboard focus to the rename action in the selected row. A single <kbdTab</kbdshould suffice.
This is also an issue with task configuration
Code change:
name: string; value: string; type?: string; <ins> language?: string; expression?: string; </ins> hasNamedChildren: boolean; indexedChildrenCount: number; extensionId: string;

Related discussion:
text: similar to the 'open in data viewer' command from the jupyter variables view, we should allow extensions to contribute a view for a variables for specific language/types on the built in tree view.
That would essentially be number 6 in this screenshot from the Julia extension , right?
Same idea, either with an icon like that or through the context menu on that item. In the jupyter extension's case, we are planning to allow contributions for data viewers from extensions that didn't necessarily provide the variables.
Cool. I think icon and context menu would be great ;) It might also make sense to think a bit ahead there: there are probably some kind of viewers that are relevant for a lot of languages (tabular data, plots) and others that are very language specific. From our end, we would love it if VS Code at some point gained a generic tabular viewer, and a plot viewer that we could utilize and get rid of our custom implementations as well :) So maybe some kind of API design where in the future one could hook into a as of yet not existing generic tabular/plot viewer.
Example implementation here The menu contribution point name will likely change names when we expand the usage beyond notebooks, but any needed migration will be pretty straight forward.
I created a sample extension and cannot see any variables showing up. Do I need to enable something in VS Code for this feature to work. I couldn't find any settings/experiments that had to be enabled for this.
Found that I needed to enable a VS Code experiment (I was looking for Jupyter experiments). Not sure the API is useful in its current form. Currently when i create a viewer for DataFrames, lists, objects, anything I do not get the name of the variable. Hence I have no idea what I'm looking at, all I get is a value, and thats basically a stringified version of the value. Thus its not really possible to create any viewer, unless of course I'm missing something here.
Moving to March for now. Feel free to move back to February if the issue has been verified or once steps are provided and the issue is verifiable in the latest Insiders. Edit: I confirmed using the sample extension that the viewer does not report the variable name.
Code change:
name: string; value: string; type?: string; <ins> language?: string; expression?: string; </ins> hasNamedChildren: boolean; indexedChildrenCount: number; extensionId: string;

Related discussion:
text: verification: sure you have jupyter and python extensions enabled the notebook variable view the or create your own some notebook cells that create variables and open the debug sidebar to see the notebook variable view that the command contributed to the menu is provided information about the variable ( should be the expression that would access that variable)