Support $$ as delimiter for math formula

[tlylt]

Is your request related to a problem?

When trying to import some content that I authored using a markdown editor with mathjax support, I discovered that the $ $ $$ $$ delimiters are not working due to the choice of brackets over dollars as a delimiter in PR #1335.
This was with the consideration that $$ $$ was planned to serve as delimiters for underline. However, in issue #28, !! !! was chosen for underline instead.

Since we have freed up $$$$, perhaps we can allow user to configure the delimiter of their choice for better support for math related content.

Describe the solution you'd like

Allow users to specify the delimiter of their choice in site.json

Describe alternatives you've considered

Since I am not sure the exact proportion of people who use brackets as delimiters for tex, I guess the default delimiter can stay as it is. The alternative is for authors to convert their syntax from dollars to brackets, which as acknowledged in this #28 (comment) ...is not very user friendly.

[damithc]

Thanks for bringing this up @tlylt No strong views from my side, as I don't use math formulae in MarkBind sites. Others are welcome to give inputs.

[jonahtanjz]

@tlylt I think allowing the use of $$ for math notation is a good idea since this is a commonly used delimiter for math related content.

Allow users to specify the delimiter of their choice in site.json

I'm not too sure about this as allowing users to specify their own delimiter can cause some issues in the future when MarkBind introduces new delimiters for new features (e.g the !! for underline). Existing users that have conflicting delimiters will have to choose a new delimiter and update all the usages in their files. In this case I feel that having fixed/reserved delimiters for specific feature can prevent this issue from happening.

[tlylt]

I'm not too sure about this as allowing users to specify their own delimiter can cause some issues in the future when MarkBind introduces new delimiters for new features (e.g the !! for underline). Existing users that have conflicting delimiters will have to choose a new delimiter and update all the usages in their files. In this case I feel that having fixed/reserved delimiters for specific feature can prevent this issue from happening.

Yup agree on this. Based on the delimiters supported by markdown-it-texmath, I am thinking it would be nice if we can support dollars and brackets at the very least....either interchangeably or users can specify one of them in 'site.json'.

[jonahtanjz]

Based on the delimiters supported by markdown-it-texmath, I am thinking it would be nice if we can support dollars and brackets at the very least....either interchangeably or users can specify one of them in 'site.json'.

Ahh I see. I prefer supporting them interchangeably since both the dollars and brackets delimiters will be reserved for this specific function. I don't really see a benefit for users to specify one of them in site.json since they won't be able to use the other for some other purposes? (this also adds an extra step for the user if they want to use the $$ delimiter).

[tlylt]

Hi @jonahtanjz, I am able to support both syntaxes by loading the plugin markdown-it-texmath twice to include the default dollar sign delimiter.

markdownIt.use(require('markdown-it-mark'))
	//...
  .use(require('markdown-it-texmath'), { engine: katex, delimiters: 'brackets' })
  .use(require('markdown-it-texmath'))

On the functionality side, it looks ok but I'm not sure if there's anything to be concerned about for performance or otherwise. Any thoughts? Couldn't really find anything related to loading a plugin twice. If this works then it's probably the least expensive change required.

[jonahtanjz]

On the functionality side, it looks ok but I'm not sure if there's anything to be concerned about for performance or otherwise. Any thoughts?

Seems like including the plugin twice works quite well although it looks a little "hacky" 🤣 Performance wise shouldn't be too much overhead from what I can see (the largest one is probably importing the katex package).

The other alternative is to patch it to allow for delimiters to hold multiple values. The plugin does not seem too complex and does not have very frequent releases so patching is not too bad as well.

[tlylt]

Seems like including the plugin twice works quite well although it looks a little "hacky" 🤣 Performance wise shouldn't be too much overhead from what I can see (the largest one is probably importing the katex package).

Based on this and this, seems like the import statement should not be too problematic as explained below:

Modules are cached after the first time they are loaded.
Provided require.cache is not modified, multiple calls to require('foo') will not cause the module code to be executed multiple times.

[tlylt]

@jonahtanjz I am planning to implement the "hacky" solution as an optional plugin that users can choose to turn on if needed. The reason is that we already support one syntax for math formulae and this is more of customization for anyone who needs it.
Do you think this approach is fine?

[jonahtanjz]

I am planning to implement the "hacky" solution as an optional plugin that users can choose to turn on if needed. The reason is that we already support one syntax for math formulae and this is more of customization for anyone who needs it.
Do you think this approach is fine?

Since the overhead is not too problematic and it is an optional plugin that user can include, then I think this approach is fine.