Don't enable mirrorCursorOnMatchingTag by default

[cotiga]

I love VS Code,
But please, don't make that option default :
mirrorCursorOnMatchingTag
it's a nightmare
Thank's

[kieferrm]

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

[kieferrm]

/needsMoreInfo

[vscodebot]

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.

Happy Coding!

[jarodsmk]

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

[keforbes]

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.

[Kiiyya]

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.

[Tschrock]

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.

[vanadu]

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.

[dangrima90]

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

[garretwilson]

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.

[mducharm]

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.

[keforbes]

@kieferrm, you added the needsMoreInfo tag to this issue. Is there sufficient info now or is there something else you're still waiting on?

@octref ? Anything else you need?

[octref]

@keforbes 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 #88424.
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 #88424, and meanwhile disable this feature by default.

If you have issues with concrete reproducible cases, please open new issues.

[vanadu]

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.

[octref]

Microsoft's policy

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 under-discussion.

[keforbes]

I'm not sure how you can use VSVim in VS Code (isn't it only for Visual Studio)?

Yep, sorry, I meant VSCodeVim, totally messed up there. 🤦‍♂️

This feature does what it says

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.

Some actions, when two cursors are present, perform differently than one cursor.

Yes, precisely. That's the problem. Some actions performed differently and I didn't know why.

We can't bend multi-cursor to work differently, just so when you press Enter it only creates one newline.

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 @mducharm's comment:

In my experience, renaming HTML tags does not happen often enough to warrant the automatic double cursors

Is there another use case that I'm missing?

[vanadu]

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 under-discussion.

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.

[epstarr]

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.

[jonasnordlund]

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

[superole]

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 del. 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 space. 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 <- Backspace 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.

[Chrinkus]

Here is a use case where the default "on" of this new "feature" is incorrect.

tl;dr - A proficient vim user can make a horrible mess very quickly with mirror cursor.

I rarely use VSCode but at work I need to write up some documentation from time to time and I prefer to do so in html. So I fired up VSCode for the first time in a while and started typing up a doc. I use vim bindings and don't need to look at my editor too much especially when working in the way I was today. So I wasn't paying attention to my editor. About halfway through I opened my work in a browser to review how my old CSS settings were treating the work. It was a garbled mess of half paragraphs and repetition.

Using '/', '?' and other regular vim navigators causes multi-cursor insertions EVERYWHERE.

Change the default to "off" and test these features against different editing options like Vim and Emacs in the future.

[sbossarte]

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.

[seibee]

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.

[j040p3d20]

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.

[85joel]

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.

[Phrogz]

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.

[ryanm2000]

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.

[jarodsmk]

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

[renntbenrennt]

All the complains above explains well, and I just want to add my current brand new face to face experience, which I encountered numerous times and today I finally, "enough is enough"...

Anyway, thanks for the hard works, to those who work with this feature... but please make it off as default... Thanks...........

[octref]

I'll turn this off by default and work on #88424, which will be an opt-in feature.

[andrepapermart]

Great, it is nice to hear that it will be turned off by default