Support for configurable start and finish token

[codylittle]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

We're in the process of migrating an existing internal, proprietary, "markdown-esque" formatting system to a unified & remark based system. As part of this, $ and $$ are already in use. I'm aware that the discussion over at #39 came to the conclusion that the inclusion of other opinionated formats wouldn't be included (n.b. we also cannot use the bracketed format discussed in that thread). But perhaps a configurable regex or start & finish tokens exposed via options would be a good middle ground.

This would mean that by default remark-math would continue to use $ and $$ but allow for the (deliberate) choice to stray away from standards.

Solution

Modify mdast-util-math options to accept an experimental/unsupported start & finish token or regex expression.

Alternatives

Alternative solutions

• Fork of remark-math recommended as per Will \( \) style math formula be supported #39

[wooorm]

Hi there!

Cool!

migrating

If you are migrating, why not change the markup in the source documents?

As you note: you are aware of previous discussions. So here I’d ask the same questions.

As for regexes and arbitrary start/end stuff: markdown is rather complex in how it all works together. You may have heard before how regexes can’t be used to parse HTML. The same is true for markdown. I’m quite wary of trying to do that here too.

This would mean that by default remark-math would continue to use $ and $$ but allow for the (deliberate) choice to stray away from standards.

Without arguments, I am personally not interested in allowing every random government or other organization to come up with their own custom flavors of markdown (easily*, there are always extensions that folks can make and maintain themselves).

I believe that to be bad for markdown.

[codylittle]

Hey @wooorm,

To answer your questions:

If you are migrating, why not change the markup in the source documents?

Unfortunately we are but a small cog in a much larger system of legacy processes and procedures, and not only looking at supporting an existing ~112k documents, but regularly updated/newly created documents too.

For us, \qa denotes opening & closing TeX. - Please don't ask why, I yearn to even understand what q or a have to do with TeX

(noting - $$ is already in use by an existing custom extension for injecting image content)

You may have heard before how regexes can’t be used to parse HTML. The same is true for markdown. I’m quite wary of trying to do that here too.

Yes actually, we have a regex pipeline that >1 min due to lookaheads.

I am personally not interested in allowing every random government or other organization to come up with their own custom flavors of markdown

Good catch regarding govy - We're understanding that overall; this type of request independently does not align with goals of Remark/Unified. However, believe that this would achieve middle ground between maintaining consistency/opinionated syntax but allow for users to take an unopinionated/differentiated approach.

(easily*, there are always extensions that folks can make and maintain themselves)

We have an existing (combined) 7 remark & rehybe extensions which we've written for this project, but when investigating this, found that other users were requesting out-of-scope formatting. And believe that as a result of allowing customization of start/finish tokens would benefit a vocal minority of the community.

Regardless of outcome - awesome work from yourself & team, and as mentioned above, we understand that this doesn't necessarily align with the direction of the project and worst comes to worst, we'll look at implementing this internally.

[wooorm]

Appreciate the kind words and understanding!

I am sorry. I understand that you want this and it would be nice for you. But I don’t want to spend the forseeable future of my life, unpaid, maintaining this code. It’s not my idea of fun to deal with the bugs. And I don’t think it’s good for the world to split markdown in more flavors. I am already way too pressed for time and money.

The problem you have will grow and grow. There will be more and more documents. More and more questions.
The solution I recommend you is to use either a) custom HTML elements, b) MDX, c) directives.

Or, to maintain a fork.