jiebi/CodeConvo huggingface dataset:
Does it make sense? Yes, that is correct. actually, your visual explanation has helped me understand the entire experience better. I initially thought that there was no cursor in the text field at all while the user was typing.
thanks a lot for your comments! I really want to sit down and play with aria-live some more based on your idea. Considering that this issue is pressing, I've made a small change to get the placeholder to be read out.
happy to test that change when it becomes available in an insiders build, or remotely with you in case you want earlier testing. for my idea to work, it would require some changes in keyboard behavior as well, and careful testing so that we don't break current user expectations around a widget which is critical for some customers. feel free to reach out if you need additional input.
<!-- 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!
I did some testing using the latest insiders build and NVDA Results with screen reader mode on: Placeholder text is announced when the widget receives focus. When typing in the text field, the number of results is announced by NVDA but not the highlighted option. This can be a productivity killer. I believe the announcement of the highlighted option is the most important piece of information while typing. the number of results is irrelevant at this point. It becomes important when the user starts to navigate with the arrow keys, and at that time the screen reader takes care of it. Screen reader mode off: When the widget receives focus, the number of results is communicated by NVDA followed by the announcement of the quick input list and the highlighted element, but the placeholder text is not announced, likely because the "combobox" portion doesn't have focus. when typing, NVDA announces changes in the highlighted option in Braille and speech as expected.
Version: 1.77.0-insider (user setup) Commit: Date: 2023-03-23T10:21:45.873Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
Closed Verified the issue in latest environment: Version: 1.78.0-insider (user setup) Issue is fixed. Hence closing the bug. please find attachment for reference. https://user-
Type: <bBug</bthe settings like below: : new terminal via ctrl+` from terminal input. Pressing Shift+Tab moves to the terminal buffer. Shift+Tab should be passed to terminal as an input key. The focus needs to remain in the terminal input field. We need when cycling back through shell auto-suggestion or ipython completion. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-19T05:34:51.441Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (90)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.1.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 dscodegpt2.1.14 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.12 copilot1.97.271 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.1 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11.
python2023.12.0 vscode-pylance2023.7.30 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.301.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.1717 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5873 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.2 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.20.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.23 latex-utilities0.4.10 chatgpt1.1.2 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
related this also reproduces in stable VS code
We're going to remove the keybinding altogether as it should enter the buffer when toggle tab moves focus is enabled and not (as designed) without that
Changing the keybinding could throw users off,
though is wondering if we can treat this like a widget with results/ input and allow moving between the two with keybindings consistent with
Shift+tab is still going to the workbench even when I remove that keybinding and have tab moves focus mode off
We now allow using or to go to the terminal accessible buffer instead. I think it makes sense to remove as a keybinding next iteration if we agree that makes sense and The only downside of that would be users might already have in their muscle memory.
If we cannot resolve the synchronization issue with autocomplete and shift +Tab, I am in favor of removing the key-binding. there are worse things than retraining mussel memory.
Yes, and I just discussed, and we agree it can be removed this iteration.
We will also remove the tab index
I cannot reproduce the original issue in stable (either 1.81 or 1.78). What are the steps to verify?
Sorry, to verify, focus a terminal with screen reader mode enabled. Use . the accessible buffer should not open.
This does input and no longer shows the a11y buffer, but the event also bubbles beyond and moves the focus to the panel title incorrectly: !
Guessing we need to do something with tabindex that must've been removed in order to get this to work
I think it would be either shift+tab needs to be specially handled in or we should handle it and cancel the event in the custom key event handler.
not sure how this was working before. I dug through commits and tried reverting this one, which didn't help.
I love VS Code, But please, don't make that option default : mirrorCursorOnMatchingTag it's a nightmare Thank's
can you please share more detail about what behavior makes it so bad for you that you had to change the setting?
/needsMoreInfo
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our guidelines. Please take the time to review these and update the issue. Happy Coding!
Hey I agree with with this one here. I first came across this new feature today after updating VSCode, and after some searching, saw the setting & feature mentioned over at IMHO - This should be disabled because it feels unnatural to select an HTML tag after it's initially created and want my IDE to automatically create multiple cursors on it's closing tag by default. I'm more likely to go to an opening tag and add attributes (or like when I'm working on an Angular/React project, add directives, inputs and outputs to my components) than want to have multi-cursors to rename the component/tags (which if needed, can be done with the Ctrl+D key binding anyway). Took a few minutes of head scratching to figure this all out, and seems like I'm not alone on this one. I'd say it's one of those things that could be enabled if needed, but disabled by default. :)
I might have a narrow use case here but I use to write Angular code. These multi-cursors on HTML tags completely ruined my ability to edit the file. I tried copying the current line with and it copied both the line where my cursor was and the line with the matching HTML tag. I didn't notice this until I tried pasting with and it pasted both the line I copied and the line with the matching tag a couple lines above that. I noticed it changed more of the file than I intended but it took me multiple operations before I realized multi-cursors were the culprit. I tried using to open a line below my current line and it two lines because there were two cursors. Then I tried using to append to the end of a line (after an HTML tag) and it appended only on the first cursor (the opening tag), which meant I couldn't append to the end of the line. Thank you for adding the setting because this was infuriating to me.
I couldn't understand how my vim plugin was so horribly broken. I could probably complain to the vsvim project that they should disable this setting when installing the extension but I figured I might as well throw my use case into this issue first.
Instead of mirror cursor on matching tag (which conflicts with vsvim for me), have some feature which only changes the matching tag name. I don't want to add to the closing div tag (as it just happened to me). Also when using vsvim, and you press to open a new line, it opens a new line in both locations.
While I like the idea of being able to edit start/end tags at the same time, the way mirrorCursorOnMatchingTag works currently has some flaws that are really easy to trip over. I noticed it has special handling for typing a space in the start tag which is nice, but there are some other cases that can cause problems. For example, pasting - currently if I try pasting an attribute into a bare start tag, my end tag gets the attributes too, which I don't want and have been frustrated by a number of times. There's also an issue with getting double comments when toggling comments for a tag that starts and ends on the same line. A third issue is that it doesn't seem to work when making a selection with the mouse (either by double clicking the start tag or by dragging a selection in the start tag), which is my primary way to rename tags. Suffice to say, my initial impression is that this feature is buggy and doesn't completely accomplish what it was meant to do, and so I don't think it should be a default option until it can work more smoothly and not cause disruptions to my regular editing.
I just wanted to change the closing tag of a specific element. Since this feature enabled itself after the last update unawares to me, I could not change the tag because the feature also changed the opening tag that element, and also other identical strings in the file. I had to google myself silly just to turn it off. Then, when I tried to turn it back on to test it, it didn't work at all. I don't see any productivity benefit with this feature, at least not in the current unreliable state. The use cases where I'd want to turn if off far outweigh the productivity benefit that I might glean from having it on by default.
It's irresponsible to introduce and enable a new feature by default. I wasn't pleasantly surprised at all.
As mentioned in some comments above, I don't mind the feature but the fact that there are two cursors simply because the cursor is inside and next to the tag name is a bit weird in my opinion. I mostly work using Angular and it's a bit frustrating when code is pasted in the opening tag and gets pasted in the closing tag too. Why not make the feature that the double cursor appears when any text of the tag name is selected (i.e. highlighted)? If I explicitly want to change the tag name I would then simply double click tag name name type therefore changing the opening and closing tag. ! If for some reason I select part of the opening tag name, the closing tag name gets selected too (and vice-versa). !
As we were in the comments, it is wonderful that VS Code allows a plugin mechanism so that I can have extensions that make all sorts of nifty things happen when I edit, such as adding matching tags, inserting tags from abbreviations, or whatever. That's what extensions are for. But the VS Code made two big mistakes here. First they turned on a a feature automatically that should be an extension. It fundamentally changes how the editor operates. I make some changes here, and I don't expect, without some further action on my part, that it will at the same time make changes over there. I see flashing cursors everywhere while I'm trying to edit it, and things I did not touch suddenly get modified. An editor is not for surprises, especially when it comes to modifying content. It was bad enough turning this thing on by default, but the other horrendous mistake was pushing out this half-baked, ill tested feature on us. It has huge bugs, which have been reported already by many—see for example . If I have an element that has attributes, when I select and delete the attributes this new buggy feature selects and deletes content outside the closing tag, completely corrupting content; removing essential, unrelated content; breaking the document; and losing the information. VS Code is becoming my go-to editor, and it is becoming beloved by a huge community. Don't squander this support by starting forcing half-baked and ill-tested gadgets on us.
There are thousands of gadgets we can turn on with extensions, and it's awesome that such a facility is available for us. At the least, the very least, this should have been tested and re-tested for six or nine months, made available in an extension or an option, and then if there was an outpouring of requests perhaps a dialog that pops up after an update that says, "hey, you should really turn this on". If all goes well, and still no problems, you could turn it on for new installs. But instead you threw something together half-baked and forced it on existing installations! Are you starting to see how it this interesting idea was executed all wrong? Look, if you have all these extra coding cycles and want to implement something cool, why not go which is one of the huge remaining bugs that mar an otherwise fabulous editor. Congratulations on the editor in general, and good luck learning from this lesson and making it even better.
Since you can use Rename Symbol (F2 by default) on HTML tags, I think having automatic double cursors is unnecessary. In my experience, renaming HTML tags does not happen often enough to warrant the automatic double cursors - since I am already used to renaming symbols with F2, it's more intuitive to do it that way.
you the needsMoreInfo tag to this issue. Is there sufficient info now or is there something else you're still waiting on? ? Anything else you need?
We can consider disabling it by default, but that means this feature won't be discoverable at all. Some issues are hard to fix, others are impossible. We are working on an improvement. You can find more details in . This feature does what it says: Creating another cursor when you are on an open/close tag. Some actions, when two cursors are present, perform differently than one cursor. Like, if you press Enter when two cursors are there, it produces two newlines. We can't bend multi-cursor to work differently, just so when you press Enter it only creates one newline. I'm not sure how you can use VSVim in VS Code (isn't it only for Visual Studio)? During my testing it had some issues with VSCodeVim, because of the way VSCodeVim is implemented. But most of the time it works fine.
In short: we'll use this iteration to find workaround for some of the issues. If there's no easy workaround, we might take a more general approach in , and meanwhile disable this feature by default. If you have issues with concrete reproducible cases, please open new issues.
So you're saying then that this will be Microsoft's policy moving forward, that is, to make new and unpopular features enabled by default in order to make them 'discoverable', so that users then have to sacrifice their time and productivity with vetting processes like this? It would seem that it would be in the user's best interest to let users discover new features in the release notes and let those who wish to test the feature do so on their own time, rather than forcing new features on the general userbase who actually depend on reliable editors to meet deadlines and earn their daily bread. Thanks for informing us of this policy now so that users can let it inform their choice of editor in the future.
I can't dictate Microsoft policy. Please don't make extreme straw man statement to criticize it. We'll consider disabling it by default. That's why the issue is open and marked with .
Yep, sorry, I meant , totally messed up there. :manfacepalming: I think the issue here is that by enabling the feature by default, I had no idea what the feature "said" or that it even existed. All I knew was that multiple cursors kept popping up when my cursor was on an HTML tag. Yes, precisely. That's the problem. Some actions performed differently and I didn't know why. Nobody is asking for the multi-cursor feature to behave differently, we're saying that only the users who want_ multi-cursors should deal with those nuances. This GitHub issue is full of comments from people who were confused/frustrated by the change in default behavior, which is arguing for it to be disabled by default. I'm curious, what is the argument for enabling the feature by default? Is that discussion documented somewhere? I'd like to see why the feature was considered so useful as to warrant being enabled by default because as far as I can tell, the only benefit is in the case where you need to rename an HTML tag. And I agree with comment: Is there another use case that I'm missing?
With all due respect, it should be obvious that it's the decision to enable it by default that most people in this thread are objecting to. That's either a one-off decision that was made for this particular feature or it's a policy decision that will be made for other new features moving forward. I apologize if my comment came off wrong - Code is a great editor. What I'm saying is that I hope this is just a one-off, because if it were to become the default method of launching new features, it might affect users' willingness to use Code or to upgrade for fear of encountering unwanted new features that result in loss of productivity.
as noted, I run into this multiple times a day working in Angular. I had thought it was an extension gone rouge, as it seemed like a feature that an extension would add. So I spent my morning disabling them one by one, until I opted to search and see if this was a new vscode "feature" . For what it's worth, I also disagree with the notion that new features should be enabled by default to encourage "discovery". That's what the update and changelogs are for. If I was a new VSCode user coming in post-update and I ran into this not knowing it was a "feature", it would turn me off from the editor completely. It's not what I would consider typical behavior for what an editor should do, but that's just my two cents.
I specifically looked to find this issue/topic as I've been hit by it multiple times during a day of coding now and it did introduce bugs in my code. The worst case is when I reorganize HTML code and sometimes have to delete or edit the starting tag. Then the closing tag can get deleted too, but nothing is of course re- if I start typing in the new/changed starting tag because it has now no ending tag counterpart. Well, maybe it's immediately after my new starting tag, in the completely wrong place. This can introduce hard to immediately discover bugs in my HTML because of sometimes deep nesting in long blocks of code and removed or messed up closing tags (I've particularly discovered things like suddenly missing end brackets that I've only noticed early on thanks to syntax highlighting?).
It's especially frustrating because sometimes things happen and other times it doesn't seem to, and I have a hard time mentally getting around when and why it's doing things, so I end up having to baby sit the editor. I think that for me, it would be easier to have more predictable behavior back again. I'm very used to renaming both tags, no problem there. But sure, at least now I know what the setting is. I'm just offering this as feedback on "how does this impact me negatively".
This feature is a poor substitute for real code refactoring, and should never have been enabled by default (IMO it should never have been to the main application at all). If you were worried that users would not discover the feature, you could have a hint about it in the changelog. Or better yet; you could have made it as an extension, and advertised it in the extensions panel. Multiple cursors are really handy in certain scenarios, but it is vital that the user is fully aware and in control of where they are. One really essential problem with this feature is detecting when the user is actually modifying the tag name, and not just adjacent code. Another is that there are other ways of modifying the tag name than just adding or removing characters. I do not believe that these issues can be solved without proper code awareness, and if the editor has that then this feature is redundant anyway. Given this code example... ...I have three examples of how this feature breaks the code while I am editing: want to remove the extra whitespace preceding the class-attribute, so I place the cursor at the end of the tag name and hit <kbddel</kbd. Code is now broken because the end-tag has no closing angle bracket (). inadvertently typed in the attribute "component" without a space after the tag name "custom-angular", and I fix it quickly by placing the cursor between the two and hit <kbdspace</kbd. Code is now broken because the end-tag does not match the start-tag. want to remove the prefix "custom-" and I do so by placing the cursor at the end of the prefix and hitting <kbd<- Backspace</kbdrepeatedly.