jiebi/CodeConvo huggingface dataset:
I think I was relying on this behavior 80% of times when I pressed F8. And now it's become quite difficult to predict whether F8 or Shift-F8 would keep you in the current file or move to another one.
We have the two old commands back (in addition to the new commands). That means there is now "Go to Next Problem" and "Go to Next Problem In Files" as well as the other direction. We have not changed the keybindings, so F8/Shift-F8 walks across the project and you would need to reassign the them to get old, old behaviour back.
Wow, I didn't expect this minor issue to get resolved so quickly! Big thanks to the team, it's really a marvel to witness the development of this amazing project.
Thanks to
I verified the new command works as expected, however is the name "in Files" really clear what it does. Why not "across Files"?
We chose "in Files" to match "Find in Files". "across Files" makes sense too though and might be clearer for users who haven't used "Find in Files" before.
mentioned that the diff editor experience is a little confusing because we don't explicitly state that the current editor is the modified one vs the original editor. AFAICT, there's also no way to jump between the original and modified ones. Is this correct? & I'd appreciate your thoughts here. Edit: action items: [ ] add info in help dialog about switch sides command [ ] get accessibility signals to work in original editor
There is the Diff Editor: Switch Sides command that moves focus to the other side. Maybe the wording could be improved. So not sure what needs to be done here? Feels like similar to the other issue you created about missing clarity in announcements on original vs modified.
Yes, I was unaware of that command. We should include it in the diff editor help dialog and include a default keybinding for when in screen reader mode as that's definitely something users would want to do IMO.
pointed out this should maybe be a tab stop if possible
I have the following keybinding, but there was no noticeable change (at least to from a screen reader user's standpoint) after switching into the other side. :
could you tell there was a focus change at all? Is there also no difference if you run the command vs use the keybinding?
Audio cues do not work when I'm navigating in the original editor. !
Testing When I was on the section of the walkthrough I clicked on "open remote repository" and it had the dropdown. I noticed that I couldn't just click outside the dropdown (back on the welcome page) to make the dropdown disappear and instead had to use the "esc" button. From my experience with other dropdowns if you click away from the dropdown it disappears and think that behavior would make sense here.
does the quick pick come from ? If yes, who should I direct this issue to?
Yes that's where the quickpick comes from. owns the desktop git extension.
could you please help with this? Thanks.
Clicking outside of the dropdown still doesn't escape. !
It turns out that the "Remote Repositories" extension does not leverage the picker from the git-base extension so the fix that I made is not relevant. To verify this, please download the latest pre-release version of the "Remote Repositories" extension.
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.
<!-- 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
<!-- 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.
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.
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.
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.
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
<!-- 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. --- VS Code Version: 1.54.3 OS Version: Windows 10 20H2 Steps to Reproduce: a file with the same words with different casing a find replace with preserve casing switched on the preview does not work properly (and the replace also doesn't) preserve casing does not do anything ! I'm pretty sure this worked as expected before.. <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --
The feature came via
This case is not handled. When the match is mixed-case and starts with a lowercase character, I think the replace pattern should have its first character lowercased. Would take a PR that adds this.
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
VSCode Version: 1.19.0 OS Version: openSUSE Tumbleweed (Linux) Steps to Reproduce: "version" in no entry, but should As enhancement it would be nice if the show-all-command would have an entry to display the Visual Studio Code version (I know that I could pass the flag on the command-line). Such a feature exists e.g. in Emacs, where it is possible to enter and get the current Emacs version displayed.
I'd like to take this up. Any pointers? far I though to extend the current to execute and show the result? Or is there a place where we store version globally? we open up the and show the result of there?
No need to execute , that information can be obtained by requiring . Output is good, but a is better.
raised a PR . Currently in the action under . Any better section to add this in?
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.45.1 OS Version: macOS Mojave 10.14.6 Steps to Reproduce: Recently, the autocomplete auto import text has become cropped so short as to be completely useless. In many cases over the past couple of days, I've had the option to import 2-4 same-named classes/components. Normally, I can select the correct one based on the additional text Now the package name is cropped to the same text for all options: This makes the auto-import feature completely useless (one of the most important features in an IDE). See example: ! project with React Native + React Navigation in 'Header' and cmd+space to open autocomplete (It may be that additional conditions apply, for example what the other options presented in the list would be.) <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Press <kbdCmd</kbd+<kbdSpace</kbdagain to see detailed info for suggestions. Changing width of suggestions box already tracked in and
Or just remove this completely useless feature which was around January 2020.
Agree with and others, that current implementation does not make too much sense, and adding this description to the same line as a code snippet makes snippet name and description basically useless.
Since was closed (with reference to some obscure problem from 2017), this ticket is the closest I could come to the new issue. The suggestion-list window is just too narrow for the info that is being presented there. Introducing a new feature to put more information there made the situation worse. It's simple not enough room to read the fully qualified names many are using. Snippets for PS/XML and other languages. (Sample image included) Alternative fixes : Allow us to turn OFF the 'descriptions' in column 2 of the snippet list. Allow people to customize the width of the list-window. Roll back the feature that gave us 2 columns instead of just 1 column (with the name only). I sincerely need a workaround or fix. Very frustrating. !
The autocomplete just got even more useless! Here are the options that I see (cycling using ctrl+space): <img width="735" alt="Screenshot 2020-06-25 at 10 54 43" src="https://user-"<img width="761" alt="Screenshot 2020-06-25 at 10 55 24" src="https://user-"Previously the detail screen showed details on the option, not details why this suggestion is being provided. What's the use of that to a developer? Have I unknowingly enabled some obscure autocomplete-debugging mode or something?
Yes. Press to toggle the suggest debug mode
does nothing. I couldn't find anything similar in the command palette either nor by googling.
Aha! To en/disable the suggest debug mode (on European keyboard): the suggestion dialog (i.e. the same hotkey as for (un)commenting a line) (I figured it out by seeing that on a US keyboard is .) So if you accidentally have the suggestions open when trying to comment out a line, you'll end up with a useless autocomplete system and no idea how to make it work again. May I suggest that a functionality that is useful to 0.01% of users and causes a lot of confusion for 99.99% if accidentally used would not have a default hotkey? It could be clearly labeled as "Toggle autocomplete suggest debug mode" or similar in the command palette, which would be just as easy for suggestion debugging cases but users would not accidentally trigger it.
Just a heads-up that for the suggest widget and its details parts are going to be resizable. See This issue will all about the specific TS case and how to improve the situation for auto-importing modules
There might be more to it and things I don't know esp. the doc for says it might not be human readable but it kinda looks nice already. <img width="584" alt="Screenshot 2020-11-02 at 12 37 51" src="https://user-"