Razor HTML attribute smart indentation does not indent an extra level on enter

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[regression] [worked-in:16.11] For razor files, if I want to do a multiple line statement so its easier to read, when I hit enter, instead of indenting, it literally goes to the far left side of the screen which makes it harder to read. This happens with Visual Studio 2022 Razor Editor. When I use Visual Studio 2019 but do not choose the experimental version, then its fine. I would be really disappointed if there is no way to fix it. I would suggest to at least give the option to use the old editor because otherwise, its a pain everytime I hit enter, then I have to figure out how many tabs to indent. I used the recorder to show this. Even if a something like a div is used, then after I hit enter, then no intending. This means it does not work that well at all. I just hope there is a way to fix it.

---

Original Comments

Feedback Bot on 8/24/2021, 11:27 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Taylor Mullen [MSFT] on 8/26/2021, 02:45 PM:

Would you mind elaborating? We aren’t entirely sure what you are referring to (the recording didn’t come through well). Would it be possible to provide an example with expected and actual results? This sounds bad and we definitely want to resolve this for you!

Why do we ask for more info?
We try to reproduce all issues reported with the information provided in the description and comments. When we can’t reproduce the issue, we ask you for more information so we can resolve the issue as quickly and efficiently as possible.
In our guidelines, you can get tips on how to provide clear and simple reproducible steps.

Andy Walter on 8/27/2021, 08:15 AM:

For example, if using
<div class=“test”
then i hit enter, i expect something like this
<div class=“test”
style=“font-size=5vh”>

However, what happens is something like this
<div class=“test”
style=“font-size=5vh”>

This is bad. Because it means its much harder to read.
Blazor (razor) components do the same thing.

Andy Walter on 8/27/2021, 08:19 AM:

RazorProblemSample.txt

Just in case the previous comment removed the spaces to show my sample, the included text file show the difference between what is expected and what shows up.
Happens when I hit enter after the <div
or any tag to do multiple line.
The problem did not happen with visual studio 2019 if not using the preview razor editor.

Taylor Mullen [MSFT] on 8/27/2021, 11:30 AM:

Interesting, I’m not reproing that experience:

It’s not exactly as your expected results; however, it’s consistent with other HTML/Razor editors in the ecosystem. Does there happen to be any surrounding content in your scenario?

Andy Walter on 9/1/2021, 06:28 AM:

You can see it does not indent a little more to make it easy to tell its part of the same tag.
On the older version when not using preview features, it would indent even more (based on settings).
This means its still a problem.

I can see from your recording, the desired behavior is not quite right. In older versions of the editor before doing experimental, after you hit enter, it would indent a little more. In this case, it only indents to the start of the line, not a little more.

---

Original Solutions

(no solutions)

[NTaylorMullen]

The two areas this issue encompass is attribute smart indent as indicated here:

And self-closing HTML smart indent :

[NTaylorMullen]

Similar issues:

• https://developercommunity.visualstudio.com/t/Blazor-auto-formatting-is-buggy-since-sw/1615656

[ryanbrandenburg]

At first look: This seems to work if you hit Ctrl-K+Ctrl+D, so the problem here likely lies in formatting trigger when we hit a newline.

[NTaylorMullen]

At first look: This seems to work if you hit Ctrl-K+Ctrl+D, so the problem here likely lies in formatting trigger when we hit a newline.

Ah this will be language-configuration.json based. Let me know if you want to chat more

[ryanbrandenburg]

Oh good I'm glad you have ideas because I was out of them lol. I'll probably look at this after I wrap up RestrictChildren and have a break in the VS Main Integration test stuff.

[NTaylorMullen]

FWIW I thinkkkkk React & friends have done this in the VSCode landscape. Good chance we can follow their lead :)

[ryanbrandenburg]

Turns out that React, Angular, and plain HTML in the VSCode landscape all have basically the current experience for us in the LSP editor, so we'll be blazing new trails!

[ryanbrandenburg]

I've got this MOSTLY working, except the behavior when you hit enter at the end of the line. I suspect that either I misunderstand the behavior of "afterText" or there's a bug in the VS-Platform Implementation of it.

[NTaylorMullen]

I've got this MOSTLY working, except the behavior when you hit enter at the end of the line. I suspect that either I misunderstand the behavior of "afterText" or there's a bug in the VS-Platform Implementation of it.

If you're curious how VSCode works with it you can play around with the language-configuration.json VSCode sample

[ryanbrandenburg]

OK, I've got this working for every scenario (I can think of) that our existing "OnEnterRule" rules work. Because of the limitations set out by the languageconfig.json file (only allowed to look at the current or one previous line) I doubt that we'll be able to exceed those limitations. AFAIK doing so would require essentially a full syntax parser (probably too slow, and unlikely to be cross-platform without LSP spec additions anyway) or a guarantee that people won't break certain structures into multiple lines (which rather misses the point).

The scenario in question is

<div
    class="thing"
    stuff="other"></div>|

In this case we'll end up indented instead of back against the margin.

[ryanbrandenburg]

One more quibble, html allows ', not just ", so I'll need to make my regex more permissive.