vscode: Don't enable `mirrorCursorOnMatchingTag` by default

Hey @kieferrm,

I agree with @cotiga 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 https://github.com/Microsoft/vscode/issues/66634

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. 😃

As we were discussing on Stack Overflow 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 #86978. 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 fix #32320, 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.

I’ll turn this off by default and work on https://github.com/microsoft/vscode/issues/88424, which will be an opt-in feature.

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.

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.

I might have a narrow use case here but I use vsvim 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 yy 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 p 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 o to open a line below my current line and it added two lines because there were two cursors. Then I tried using a 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 html.mirrorCursorOnMatchingTag 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.

I also got hit with this today. I mangaged to edit the opening element but it did not auto select the closing element. When I then tried to edit the closing element it auto-selected the opening element parent to the first one. See picture for example.

I also ran into the same issue as @j040p3d20 and by then my blood was boiling and I literaly screamed from frustration. Features like this should not be activated by default when it clearly messes with peoples personal coding behaviour/styles.

This kind of falls into the same category as any setting that can help users reduce keystrokes (similar to autoClosingBrackets). When you’ve built up some muscle memory or expectation for how things behave, and that suddenly changes, it can take time to get used to. Personally I have many of these features disabled because of being used to unconsciously doing many of them manually, and the time investment in changing that and fixing mistakes that occur in-between hasn’t seemed worth it.

It can be especially frustrating when you are in the middle of something and a feature like this is introduced. Even more so if finding the name of the feature in order to disable it winds up taking more than a trivial amount of time.

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).

A use case that this feature completely corrupts is reordering HTML tags using the option+↑/↓ key binding. It took me ages to realise that when I was refactoring some html, reordering things, why my html was all of a sudden being corrupted because the corresponding tag was being moved as well, and more often than not, incorrectly.

This should definitely not be on by default. Thanks for reading.

I’m also having issues when moving lines with alt-arrow . I want to move the starting tag higher to include block of code above, but ending tag also gets moved.

The worst part is for those who are uninformed, which is everybody who didn’t see the patch notes, the name of this feature would remain elusive until you either find the correct patch notes on stumble upon this thread.

How can one disable a feature that has no name?

Personally I thought it was a bug with multi-select / multi-cursor that got enabled on accident. Still do actually.

Had four lines of <label> elements. Selected the opening tags for all four as distinct selections, and then edited to add <label title=""> to each. Didn’t realize it was corrupting content in the close tags. Uck. Too dangerous to use, let alone enable by default.

This feature is a poor substitute for real code refactoring, and should never have been enabled by default (IMO it should never have been added to the main application at all). If you were worried that users would not discover the feature, you could have added 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…

<div  class="main">
  <custom-angularcomponent [with]="inputs" (and)="eventHandling()"></custom-angularcomponent>
</div>

…I have three examples of how this feature breaks the code while I am editing:

1. I want to remove the extra whitespace preceding the class-attribute, so I place the cursor at the end of the tag name and hit <kbd>del</kbd>. Code is now broken because the end-tag has no closing angle bracket (>).
2. I 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 <kbd>space</kbd>. Code is now broken because the end-tag does not match the start-tag.
3. I want to remove the prefix “custom-” and I do so by placing the cursor at the end of the prefix and hitting <kbd><- Backspace</kbd> repeatedly. Now if I go back too far, accidentally removing the opening angle bracket (<), and then re-type that character to fix my error, then the code is broken because the end-tag has been converted to a new start-tag.

Now all of these are simple examples, and if you are aware of the feature and/or see the errors as they occur, it is super easy to fix the code again. Either manually or by using the undo-feature. But if the code is longer and more complex and the end-tag is out-of-view when the errors occur, it may be quite difficult both to discover the errors and to fix them.

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.

as @garretwilson 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.

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.

Created a draft PR, seemed like a pretty trivial change, just need to hear if I have to do any other tests/etc for this

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-added if I start typing in the new/changed starting tag because it has now no ending tag counterpart. Well, maybe it’s added 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”.

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 class=.. to the closing div tag (as it just happened to me). Also when using vsvim, and you press o to open a new line, it opens a new line in both locations.

@cotiga can you please share more detail about what behavior makes it so bad for you that you had to change the setting?