`force-expand-multiline` not working correctly with handlebars block statements

[brokenalarms]

Description

This is getting really close to a perfect working formatter of hbs files in VSCode... just still one more issue. There doesn't seem to be any way to -not- get the formatting to inline the first attribute for handlebars block statements. So these stay the same and all the HTML elements do have their attributes put as multiline.

Input

The code looked like this before beautification:

{{#hbs-block my-attribute="1"
  my-second-attribute="2"
}}
<div my-attribute="1"
  my-second-attribute="2"></div>

Expected Output

The code should have looked like this after beautification:

{{#hbs-block
  my-attribute="1"
  my-second-attribute="2"
}}
  <div
    my-attribute="1"
    my-second-attribute="2"
  >
  </div>

Actual Output

The code actually looked like this after beautification:

{{#hbs-block my-attribute="1"
  my-second-attribute="2"
}}
  <div
    my-attribute="1"
    my-second-attribute="2"
  >
  </div>

Steps to Reproduce

Environment

OS:

Settings

{
    "html.format.enable": true,
    "html.format.maxPreserveNewLines": 1,
    "html.format.preserveNewLines": true,
    "html.autoClosingTags": true,
    "html.format.extraLiners": "head, body, /html, t-def",
    "html.format.unformatted": "wbr,t-def",
    "html.format.wrapAttributes": "force-multiline",
}

[bitwiseman]

This is somewhere between a bug and enhancement. This handlebars behavior has never been great and it is possible to argue that it is better than it has ever been, but part of how that was accomplished meant not parsing handlebars tag contents as attributes, but just as text. See #1469.

If this was working before, it was likely coincidence and caused other issues such as #1040.

It looks like someone did a drive reporting of this a while back (#795). Thanks for the solid bug report.

Side note: "html.format.contentUnformatted": "pre,code,textarea,{{#", is an interesting attempt but it won't do what you're shooting for, sorry. For the example above, you'd need to use creative-edit-panel instead of {{# and it would need to be added to the unformattted list, which would have other side effects. 😞This needs to be fixed internally not by additional setting.

[bitwiseman]

In the latest 1.8.x beautifier, you shouldn't need to have wbr in the unformatted list.

[bitwiseman]

@brokenalarms
I'm trying to understand where the attributes rule applies. Is it only for name=value or can it be other cases such as just name.

So, for {{#each items}} the "items" should not be treated as an attribute right? Or should it?

Same question for {{#each child as |childValue childKey|}}.

[bitwiseman]

@brokenalarms
Okay, I looked at https://handlebarsjs.com/ and I get something now.
The items you'd like to be treated like attributes are in fact parameters to helpers . I understand they become attributes in the output, but they really aren't attributes in handlebars. Which is why figuring out how they should behave is problematic.

I would love help implementing better behavior but it may need to be an opt-in setting to ensure it doesn't break other users.

[brokenalarms]

Yes, ideally it should only be the prop=value lines that are formatted as these since they are more generally in the context of "block level helpers" which are frequently components and therefore more analogous to HTML web components which would be similarly formatted.

{{#block}}{{/block}}

Having it for built in helpers like {{#each child as |childValue childKey|}} would not give the desired effect since these are purely parameters to helpers and not thought of in the same way as passing props/attributes to components - it was actually a previous issue I lodged that the formatting for these got messed up and became

child
as
childKey

Which was another earlier blocker to having autosave for hbs files switched on in VSCode.

It's now at the point where I can actually have autosave on and it's close enough except for not wrapping the first attribute to the hbs components. It does wrap the second onwards though, whilst it no longer wraps each (as is desired), so it does seem like it's treating them differently and understands wrapping for component props but is just not applying to the first one.

[bitwiseman]

@brokenalarms
Right now the beautifier treats the the handlebars as literal text, so the following remains unchanged:

{{#hbs-block my-attribute="1"
      my-second-attribute="2" my-second-attribute="2"
}}
  <div
    my-attribute="1"
    my-second-attribute="2"
  ></div>
  <div
    my-attribute="1"
    my-second-attribute="2"
  ></div>

But the means newlines are preserved and so is indenting, which means it doesn't break formatting that you have the way you want it ... Except for the first item after the helper name. :sad: That is #1469.

I think we'll fix #1469 and then keep this open to track the larger problem of actually beautifying the these.

[brokenalarms]

Sounds good, thanks for looking into this!

…

On Sat, Sep 8, 2018, 13:25 Liam Newman ***@***.***> wrote: @brokenalarms <https://github.com/brokenalarms> Right now the beautifier treats the the handlebars as literal text, so the following remains unchanged: {{#hbs-block my-attribute="1" my-second-attribute="2" my-second-attribute="2"}} <div my-attribute="1" my-second-attribute="2" ></div> <div my-attribute="1" my-second-attribute="2" ></div> But the means newlines are preserved and so is indenting, which means it doesn't *break* formatting that you have the way you want it ... Except for the first item after the helper name. :sad: That is #1469 <#1469>. I think we'll fix #1469 <#1469> and then keep this open to track the larger problem of actually beautifying the these. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1537 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHC8CkdFqG5pfML2H_Cy0embgu06Zny1ks5uZCfDgaJpZM4WdwIn> .