Atom-beautify: Vue beautifier adds extra newline characters

[sosnail]

RT

[prettydiff]

@Glavin001 Any idea what the "\n" characters are there in vue-beautifier.coffee?

[Glavin001]

Nope. @aidistan implemented it with this PR: https://github.com/Glavin001/atom-beautify/pull/1136

[aidistan]

@gmj413966791 Which part is redundant?

@prettydiff To make sure the text starts from the second line:

<template>
  text...
  text
</template>

instead of

<template>text...
text</template>

[prettydiff]

I am not sure how white space is regarded in Vue.

In XML and HTML all white space is passed into the parser and the default rendering scheme is tokenized whitespace. Tokenized white space means all consecutive white space characters are reduced to a single character and then converted to a space. The visual rendering is adjustable with CSS but the white space is still there which can influence how the text is read by users, search bots, and assisting technologies.

The important thing is that white space is always there and has value. Here are some brief examples:

<span>car </span>pet
<span>car</span>pet

In the above example car and pet are two separate words and will be read as such. On the second line there is no space between the two words and will be read by people as a single word with a very different meaning.

When I beautify markup in Pretty Diff I account for this by not inserting space between (no indentation) for text that is immediately adjacent to a tag. This means four possibilities for tags that contain text:

• text only adjacent to its start tag
• text only adjacent to its end tag
• text adjacent to both start and end tags
• text adjacent to neither tags

I treat self-closing tags as though they were text with regard to the above 4 criteria.

In HTML some tags have semantic value and some don't. Some tags are blocks and some are inline. Some tags suggest presentation and some don't. Ultimately this is stupid and poorly designed. HTML is a series of binary rules without a serious consideration for structure outside things like lists and tables. As a result I don't take these rules to the second and third order effect. Consider the following example:

<span><span>car </span> pet</span>

I am not going to make assumptions as to what the code author is attempting to perform. I will indent between the outer tags from their child set. Yes, this could have implications for rendering, but I am not going to attempt to read people's minds or second guess their design decisions.

I recommend removing the new lines as @gmj413966791 suggested.

[sosnail]

@Glavin001 I use template jade

Like this：
<template lang="jade">
.test text...
    .test2 text2...
</template>

When I use formatter it changed like this：
<template lang="jade">

.test text...
    .test2 text2...

</template>
Go round and begin again...

[qm3ster]

Same issue here. (it adds a new line every iteration, even if a blank line was present)
Please also note that it replaces spaces with tabs.

Perhaps there is a simple way for it to invoke the other beautifiers as set up by atom-beautify configs for the language, instead of grabbing raw beautifier modules? @Glavin001

[Glavin001]

Perhaps there is a simple way for it to invoke the other beautifiers as set up by atom-beautify configs for the language, instead of grabbing raw beautifier modules?

I'm not sure what you mean.

---

I would be happy to review and merge a Pull Request resolving this: https://github.com/kaven276/atom-beautify/blob/master/src/beautifiers/vue-beautifier.coffee#L23-L45

Maybe @aidistan has some ideas as to why the original PR had the extra newlines: https://github.com/Glavin001/atom-beautify/pull/1136

[qm3ster]

@Glavin001 perhaps I misunderstand, but it seems that for instance vue-beautifier.coffee#L25 we are importing the third party js-beautify module. This would lead to it operating on the, in this case, HTML, in a default and unconfigurable way. Furthermore, if someone wants their HTML to be processed by Pretty Diff, that's not available.

This project already has a configuration and a selection of beautifiers for anything that can be embedded in vue. Hence, my suggestion was that for cases when a language is embedded in another, and for vue in particular, atom-beautify, with its corresponding configuration per lang, be called recursively, instead of just naked beautifiers.
In some other cases, eg js in pug, the easy option might be to just pass corresponding settings to pug-beautify, regarding the js, but since vue-beautifier is being essentially developed right here in the repository, and is essentially among the biggest examples of pluggable embedded languages, I thought this to be a place where it is both necessary and easy.
Finally, this should probably be strongly taken into account in Unibeautify, being entirely different from the Cascading Beautifiers feature. Who knows, maybe Unibeautify will change the landscape enough that people won't pull their own embedded beautifiers into new languages and just pass the blocks to Unibeautify.

[Glavin001]

Oooh, I see what you mean, @qm3ster , and 100% agree with your statements above! I'm not a fan of how Vue beautifier currently works. I think https://github.com/Unibeautify/unibeautify/issues/4 will eventually address complex beautifiers for languages like Vue. For now, unfortunately Vue beautification support is not great and is left wanting.

My current plan for Unibeautify is to allow for "beautification plans":
1) Support Composite Languages (e.g. Vue) where it is broken into parts, with each part being a different language and recursively beautifying those parts, and then stitching them back together
2) Allow Languages to have an ordered list of Beautifiers to apply

I have yet to detail this plan in full in Unibeautify Issues, such as https://github.com/Unibeautify/unibeautify/issues/4 , however I am keeping Vue in mind when I design the future of Atom-Beautify 😃 . Thank you for your feedback!

[Glavin001]

I've fixed the Vue beautifier adding extra newlines and will be publishing in next release 😃.

[Glavin001]

Published to v0.29.20

[qm3ster]

Can confirm, no more newlines.
Still changes spaces to tabs in Pug, whether the indent char is left at default or set manually.
Rather than patch the options through, can you tell me, knowing how the whole thing works, if there is an easy way to call "atom-beautify this string of lang x" returning a string?
Something like the following should be isolated from all atom-specific logic anyway, right?

selectedBeautifier = beautifier.getBeautifierForLanguage(language)
allOptions = beautifier.getOptionsForPath(filePath)
selectedBeautifier.beautify(input, allOptions, language)

[Glavin001]

Still changes spaces to tabs in Pug, whether the indent char is left at default or set manually.

There are bugs with option handling because the Vue beautifier implementation uses the packages directly instead of passing the options data through Atom-Beautify again to transform for beautifier-specific options.

See Vue beautifier pug and jade support: https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/vue-beautifier.coffee#L25
The pug-beautify package expects fill_tab option, not indent_char which is translated at https://github.com/Glavin001/atom-beautify/blob/master/src/beautifiers/pug-beautify.coffee#L10-L13
However, the current Vue beautifier does not pass through the PugBeautify beautifier for Atom-Beautify and therefore does not transform indent_char to fill_tab.

As always, Pull Requests welcome! 😃

[Glavin001]

Rather than patch the options through, can you tell me, knowing how the whole thing works, if there is an easy way to call "atom-beautify this string of lang x" returning a string?
Something like the following should be isolated from all atom-specific logic anyway, right?

Not yet. Unibeautify will be making sure beautification is separated from Atom and can be easily called programmatically.