Conversation
Several TOML snippets used a separate [project.markdown_extensions...] table header for each sibling extension, mirroring a YAML conversion rather than idiomatic TOML. Collapse these into a single parent table with inline table values, taking advantage of TOML 1.1's newlines in inline tables for the larger multi-key cases. Closes #104
Signed-off-by: alexvoss <alex@corealization.com>
Signed-off-by: alexvoss <alex@corealization.com>
| object = "pymdownx.slugs.slugify" | ||
| kwds = { case = "lower" } | ||
| [project.markdown_extensions] | ||
| pymdownx.tabbed.slugify = { |
There was a problem hiding this comment.
I do wonder if this should be pymdownx.tabbed = { slugify = ...? That would be consistent with the way the superfences one is done (see below)
There was a problem hiding this comment.
Hmmm. Yeah maybe it's better to stay consistent and only keep extension names as keys 🤔
| [project.markdown_extensions] | ||
| attr_list = {} | ||
| md_in_html = {} | ||
| pymdownx.blocks.caption = {} |
There was a problem hiding this comment.
In this case, I would accept the edit as caption is not an option for the blocks extension but an extension in the blocks group of extensions - right?
Signed-off-by: alexvoss <alex@corealization.com>
| ``` toml | ||
| [project.markdown_extensions.zensical.extensions.macros] | ||
| [project.markdown_extensions.zensical.extensions] | ||
| macros = {} |
There was a problem hiding this comment.
To make this consistent with the pymdownx case, we should make this:
[project.markdown_extensions]
zensical.extensions.macros = {}Correct? Anything that speaks against this? Either way, the Zensical extensions would come last in the list.
There was a problem hiding this comment.
Correct. I can't think of anything that speaks against it.
| ``` toml | ||
| [project.markdown_extensions.zensical.extensions.glightbox] | ||
| [project.markdown_extensions.zensical.extensions] | ||
| glightbox = {} |
There was a problem hiding this comment.
To make this consistent with the pymdownx case, we should make this:
[project.markdown_extensions]
zensical.extensions.glightbox = {}Correct? Anything that speaks against this? Either way, the Zensical extensions would come last in the list.
| @@ -46,11 +46,11 @@ Configure mkdocstrings as a plugin: | |||
| [project.plugins.mkdocstrings.handlers.python] | |||
There was a problem hiding this comment.
We only have mkdocstrings under plugins at the moment, right? If so then I would leave the table as it is.
There was a problem hiding this comment.
Two things were merged and released recently:
- support for markdown-exec declared as a plugin (so mkdocstrings is not the only one under
pluginsanymore) - mkdocstrings can now be declared as a Zensical extension, so
zensical.extensions.mkdocstringsunder[project.markdown_extensions]. I wish we could do the same thing for markdown-exec, but markdown-exec is not really an extension, it's just configuration for pymdownx.superfences, so it's not that easy
I think we could move mkdocstrings under Markdown extensions, but it's OK to leave it under plugins for now. No need to rush things.
Signed-off-by: alexvoss <alex@corealization.com>
Signed-off-by: alexvoss <alex@corealization.com>
Signed-off-by: alexvoss <alex@corealization.com>
| sources.exclude = [...] | ||
| targets.include = [...] | ||
| targets.exclude = [...] | ||
| [project.markdown_extensions.zensical.extensions] |
There was a problem hiding this comment.
zensical.extensions.preview to be consistent with pymdownx extensions?
2 participants
Several TOML snippets used separate top-level tables for each sibling extension. This PR changes that, making use of new features of TOML 1.1.
The largest single change is in the default configuration.
We should probably also convert the bootstrap
zensical.toml.Some tidying up for line-length still needed as well as checking that nothing broke. Hence a draft PR for now.