Support .myst files as an explicit alternative to .md to ease support in multi-formats editors

[lrq3000]

Which area is this feature request for?

Command Line Tools

Describe the feature you'd like to request

Hello,

First off I would like to say I am very pleased to have recently found about the executablebooks endeavor and I am especially excited about the mystjs standard and all the new tooling, great job by the team and @rowanc1 (glad you could continue working on these kinds of frameworks because you are so talented!).

I plan on trying to implement support for MyST in a mobile editor called Markor (on Android), and since it is a multi-formats editor, there will be the issue of how to autodetect the format to apply the MyST parser instead of plain Markdown. I know that MyST is a superset of Markdown, but it is heavier and the Markor devs are unlikely to want users to use MyST by default.

Reading the documentation, it seems there is no way to distinguish MyST from other Markdown files apart from analyzing the syntax, which is computationally costly.

I would like to suggest an alternative: to accept a specific file extension, for example .myst, as an explicit alternative to .md files with MyST formatting inside.

I know I can implement this in Markor by myself without it being a standard, but I propose to make this an official feature of the MyST standard, as for sure other multiformatting editors will face the same issue, and beyond that, it stands to reason that other tooling systems are likely to prefer explicit format specification rather than implicit to save on computational resources or to apply special preprocessing steps.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

[welcome[bot]]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.
If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).
Welcome to the EBP community! :tada:

[rowanc1]

Interesting idea! I certainly see some of the benefits of this, and would need to think through more what the downfalls of this would be (e.g. some of the benefits we get of just being another md in platforms like github, vscode, etc.) where we do want to take advantage of commonmark features.

As an alternative, a quick test would be looking for patterns like ```{ or }`, but that still requires you to read the file.

@choldgraf maybe you have thoughts on this?

[lrq3000]

I certainly see some of the benefits of this, and would need to think through more what the downfalls of this would be (e.g. some of the benefits we get of just being another md in platforms like github, vscode, etc.) where we do want to take advantage of commonmark features.

Oh I understood very well why you kept the .md extension as the default one, and I have no opinion about it, it's indeed nice that Markdown editors/previewers can display most of MyST by default without any change :D And after all MyST is a superset of Markdown.

I'm just suggesting to add another filename specific to MyST, as an option that developers can use :-) I do not suggest it should be the default one, I don't know if this would be a good idea! But a secondary optional extension should not have much side effects :-)

Thank you for your tip, I will try to do this until there is maybe less computation consuming solution.