mdast-util-to-hast: access options from wrap()

[TRIAEIOU]

Hi,

Is there a way to reach the toHast() options from wrap.js?

The current implementation results in {type: 'text', value: '\n'} hast nodes being inserted for every newline in the source markdown. I am guessing that the reason for this is to achieve output HTML from hast-util-to-html that matches the commonmark samples? Unfortunately it makes manipulating/restructuring the hast a little trickier as there are now "non-rendered" nodes inserted everywhere. From a conceptual level it may be the case that those newlines should be inserted (preferably optionally) during serialization rather than "in the hast"?

Thanks

[wooorm]

The output is indeed readable. And is similar to how CommonMark generates line endings. It doesn’t match the CommonMark examples entirely in several places.

Unfortunately it makes manipulating/restructuring the hast a little trickier

I see good reason for the HTML generated by this project to be readable, I don’t see a good reason to make it less readable.
If you want less readable output, rehype-minify, specifically, rehype-minify-whitespace can help?

Whitespace is part of the tree in HTML and it affects many things.
That also means that formatting and minifying them can happen on the AST.
And I think I believe it should happen there instead of a serializer.

[TRIAEIOU]

I see good reason for the HTML generated by this project to be readable, I don’t see a good reason to make it less readable.
If you want less readable output, rehype-minify, specifically, rehype-minify-whitespace can help?

Granted, they are fairly simple to strip from the hast when coming from mdast (the below will treat a code span that only contains a newline incorrectly):

import {remove} from 'unist-util-remove'
remove(hast, (nd) => {return nd.type === 'text' && nd.value === '\n'})

I understand the point of making the rendered HTML readable, and I note that the HTML spec includes the "source" line breaks in the DOM (similar to how toHast inserts them) so that is definitely a "spec compliance" argument there. However from another view data/hast manipulation is easier when there is no "source formatting information" mixed in with "the data". For instance "insert a list item before the last if the last contains xyz" becomes more of a hassle when the last list item is not the last child of the list etc.

And I think I believe it should happen there instead of a serializer.

Fair enough, I was simply looking to not insert them to begin with rather than first inserting them and then removing them again as, the first results in very little overhead, not so for the second.

[wooorm]

they are fairly simple to strip from the hast when coming from mdast

When using other plugins, that’s going to create more false positives. But even with normal markdown, such as:

*a*
_b_

…you are stripping that line ending.

I recommend writing plugins that work well with arbitrary other plugins. While perhaps more complex. The composability of unified is also very beneficial.
Write plugins that can handle line endings. (e.g., with https://github.com/syntax-tree/hast-util-whitespace).
What you cal “becomes more of a hassle”, I’d call “becomes more resilient”

However from another view data/hast manipulation is easier when there is no "source formatting information" mixed in with "the data"

That’s part of what this plugin does. This isn’t only about checking “a source”. It’s about transforming to something else.

If you care about “source” vs “data”, there is a better heuristic: nodes without node.position: https://github.com/syntax-tree/unist#generated.

[TRIAEIOU]

…you are stripping that line ending.

You are correct of course, thanks, cognitive malfunction on my side, something like remove(hast, (nd) => {return !nd.position && nd.type === 'text' && nd.value === '\n'}) or remove(hast, (nd) => {return !nd.position && whitespace(nd.value)})

That’s part of what this plugin does. This isn’t only about checking “a source”. It’s about transforming to something else.

FWIW I think I was unclear, when I wrote "source formatting information" I meant the formatting of the "text representation" of the "data model" (or whatever the correct terminology is), i.e. the difference between <html><head></head><body><p>Some text</p></body><html> and

<html>
  <head>
  </head>
  <body>
    <p>Some text</p>
  </body>
<html>

At any rate, I understand the compliance aspect and the intent to avoid adding "extracurricular" code.

Thanks.