executablebooks / mdformat-myst

Mdformat plugin for MyST compatibility
MIT License
7 stars 2 forks source link

✨ NEW: Add myst_extensions configuration option #9

Open chrisjsewell opened 3 years ago

chrisjsewell commented 3 years ago

Meh, this isn't strictly possible at the moment, because the CLI enforces that all plugins have to be used, and I want to be able to select what ones are activated.

hukkin commented 3 years ago

Yeah there is no easy way to disable other installed plugins. But with dollarmath for example, which is a part of this particular plugin, there should be no problem having this feature.

As discussed in https://github.com/executablebooks/mdformat-myst/issues/5 my take is still that it may be better to just install additional syntax separately, but now after the ownership transfer you no longer have to care what I think :smile:

Btw why does MyST have "optional but on by default" syntax"? To me it would feel intuitive if any syntax that's on by default is "core" MyST syntax. EDIT: this is off topic, I made an issue in myst-parser for this https://github.com/executablebooks/MyST-Parser/issues/399

chrisjsewell commented 3 years ago

it’s just a pain, because it means that every small extension (like dollarmath and substitutions that are like 3 lines of code) has to have its own package. I also think it would be nice if it was easy for users to align the formatting with their myst configuration, without having to worry about setting up loads of extension installs, possibly even just allowing for this extension to read directly from conf.py (or jupyter-book’s config) to decide how to configure the formatter; that would be most user friendly for a sphinx project, and avoid duplication of config

but now after the ownership transfer you no longer have to care what I think 😄

oh no I still expect your input 😜

why does MyST have "optional but on by default" syntax"?

well that’s only dollarmath, which is more of a legacy thing and so a bit of a pain to deprecate. There’s also the balance of wanting it to be easy for users to align with the default Markdown of Jupyter Notebooks.

chrisjsewell commented 3 years ago

Would you consider having some small hook in mdformat, to allow a plugin to decide if another should be activated/deactivated for the CLI?

hukkin commented 3 years ago

Would you consider having some small hook in mdformat, to allow a plugin to decide if another should be activated/deactivated for the CLI?

Perhaps if we can't think of a workaround and if there's a nice and simple enough way to do the hook. I made an issue in mdformat

hukkin commented 3 years ago

Do you think adding a --enabled-syntax (override) or --disabled-syntax to mdformat core would suit your needs? Stuff like dollarmath could then be kept in this repository but in a separate plugin module/class (one repo can have many) and can be disabled on the command line if need be. That would avoid special casing MyST syntax (as it really isn't special, and much of it is used outside MyST context).

I also think it would be nice if it was easy for users to align the formatting with their myst configuration, without having to worry about setting up loads of extension installs, possibly even just allowing for this extension to read directly from conf.py (or jupyter-book’s config) to decide how to configure the formatter; that would be most user friendly for a sphinx project, and avoid duplication of config

I think splitting syntax into separate distributions and using .pre-commit.config.yaml is a pretty good way to do mdformat configuration and delegate the extension installs to a tool that does it well. Then Python env is always clean, and additional_dependencies is configuration like any other. I'm not very excited about reading another tool's configuration. Actually I'm not a very excited about configuration in general :smile:

Btw what's your thoughts on having something like mdformat-myst and mdformat-myst-full (as discussed in https://github.com/executablebooks/mdformat-myst/issues/5). Seems like a simple way to avoid configuration, and I doubt that any extra extensions enabled in mdformat-myst-full would hurt many users.

hukkin commented 3 years ago

Btw one way to force what this PR tries to do is to make mdformat-myst a sort of an evil non-collaborative plugin that vendors mdformat-tables and mdformat-frontmatter dependencies so that it has direct control of all extensions.

Not saying I like the idea, but it definitely is a possibility, and can give you full control over everything, even allowing you to read whatever config files you want.

arwedus commented 2 years ago

@chrisjsewell I would like to follow up on this, because I am interested in getting mdformat running but we use colon-fence a lot. What is the current status? Would this be mergeable?