Replies: 2 comments 1 reply
-
Hi Rachael!
Is the current input liquid—y old GFM-pre-CommonMark style stuff?
Yeah. The thing is: we parse as CommonMark also, and CommonMark doesn’t support liquid, so we don’t see those variables, we just see text, and underscores, and those underscores could turn into. What complex about liquid variables is that that’s all preprocessed, it’s templating. That means they could generate arbitrary markdown (or HTML). So it’s tough to handle liquid, but there might be some ways around it, depending on your needs (here’s an old discussion: mapbox/retext-mapbox-standard#6), let me know if you want me to delve into that. If liquid isn’t handled, we have to escape stuff, and particularly around
It is configurable but I don’t recommend doing so. asd
1.
qwe asd …and b) only asd
2. qwe asd So the default is to join two constructs with a blank line, but you can configure that behavior with a |
Beta Was this translation helpful? Give feedback.
-
Hi @wooorm thanks for the response.
Yes exactly!
Our Markdown files use frontmatter, which I've already accommodated for using
The example for stripping Liquid in mapbox/retext-mapbox-standard#6 is something I considered, but I don't think that would work in our case because we want to go from Markdown -> AST -> Markdown. If we ignore the Liquid before stringifying, then the updated Markdown file would also be stripped of the Liquid. I couldn't figure out a way to ignore the Liquid but still write it out when stringifying back to a Markdown file. I have considered using retext for prose linting, and in that case we'd modifying the AST to just mark all Liquid as inline code, which is similar to the example above. But, in those cases, we won't be auto-fixing the linting errors and don't need to rewrite the Markdown file, so that would work just fine.
I agree, I prefer the blank lines too. One solution I've entertained is making sure the list marker is not inside the Liquid conditional, but for our content writers, this would introduce a large change in the existing content and how resuables are written going forward, so I don't think that is feasible for us at the moment. I'll take a look at https://github.com/syntax-tree/mdast-util-to-markdown/tree/main#join. Thanks for the help! ✨ |
Beta Was this translation helpful? Give feedback.
-
👋 Hello, I'm evaluating a couple of tools to perform linting and auto-fixing on our Markdown files, one being remark. The remark tools are intriguing to me because we already use them as part of our rendering pipeline when generating HTML from Markdown. It is also a possible avenue to upgrading our Markdown files to be CommonMark compliant by using remark-stringify to write from the AST -> Markdown.
I'm running into two issues and wondering if there are possible solutions.
I'm testing out stringifying some of our Markdown files and I'm finding that these type Liquid statements get escaped:
From:
To:
The value
contact_support
is a variable name inside of a YAML file that we use to pull reusable data into our Markdown file at render time.Is there any way to configure remark-stringify to prevent escaping
_
?remark-stringify prefers spaces before lists and this preference doesn't seem to be configurable. For example:
is stringified to:
While that change renders the same, CommonMark specifies that:
The reason we want to avoid remark-stringify from adding a new line is also related to our use of Liquid. For example, our Liquid may contain the first part of a numbered list:
{% data list-item-reusable %}
Markdown file
Is there a way to prevent this newline?
Beta Was this translation helpful? Give feedback.
All reactions