Open MinchinWeb opened 11 months ago
markdown.extensions.extra
markdown.extensions.meta
def_list
markdown=1
to work?Update todo list.
Also, a footnote plugin: mdit_py_plugins.footnote.footnote_plugin
Can now pull H1 tag if no title
, but it has to be built in to the reader (no plugin provides both the metadata and the content).
Can now use Markdown-IT's front matter plugin to separate front matter from the body of the post. May need to do a lot of metadata wrangling now to get it to work as expected....
There is still an issue where if it pulls out the title, it strings it along with spaces between each letter.
Frontmatter is now processed as YAML; this is built in to the (WIP) Pelican reader.
Wikilinks are now handled by a dedicated plugin --> https://github.com/MinchinWeb/minchin.pelican.plugins.wikilinks
Backlinks can be handled by an existing plugin (by someone else!) --> https://github.com/renyuneyun/pelican-interrefs
https://github.com/MinchinWeb/minchin.pelican.plugins.wikilinks/issues/1
Re Wikilinks: they could be handled as a Markdown-IT plugin, that relies on Pelican to actually render the link targets (as a follow-on processing step). This would likely be better, as it would provide less false positives. To investigate.
Additional icons for checkboxes:
WOW! I was about to embark down on the Markdown-IT integration path for Pelican.
But I am spending time studying Pelican internals and writing up a flowchart on this.
WOW! I was about to embark down on the Markdown-IT integration path for Pelican.
I wrote a (Pelican) plugin to do this -->
https://github.com/MinchinWeb/minchin.pelican.readers.commonmark
I've published this to PyPI; you should be able to use it as is. Please try it out, and let me know if you run into any issues or shortcomings. I use it regularly on my side.
One disappointment I discovered with using Markdown-IT-Py is that very few of the Markdown-IT plugins originally written in JS have been ported to Python yet.
And it WORKS! Nice job.
This is an evaluation mode, not an implementation. But nice job.
I've been thinking for a while that I would like to move to a CommonMark Markdown parser. The goal would be to have consistence performance, backed by a spec that has worked through many of the edge cases. As well, the hope is to make it easier to move Markdown content between applications (like to/from Obsidian).
Also, Pelican has taken to installing a CommonMark parser (
markdown-it-py
) as a sub-dependency of rich, which Pelican has taken to using as a CLI output library. So we already have the parser installed!One complication is that the original Python commonmark.py parser (available on PyPI as
commonmark
) has been deprecated in favour of markdown-it-py (available asmarkdown-it-py[plugins]
).Markdown-it-py does support plugins. This is another complication in that I use several Markdown plugins currently, and not entirely standard Markdown as is.
Another issue is how to deal with front matter; I think Pelican is using it's own standard.
Available, existing Pelican Plugins:
commonmark
package. Available on PyPI. Last updated in Dec 2022.MARKDOWN
setting. c.f. Issue #3commonmark
package. Intended to be available as part of the pelican-plugins repo, but never went beyond PR from 2015.commonmark
package. Available on PyPI. Last updated Jan 2022. I actually have an open issue (from 2016!) here due to the commonmark package changing their API, and this never got updated to match.There doesn't appear to be anything in the pelican-plugins organization.
c.f. https://github.com/getpelican/pelican/issues/2984