Timothée Mazzucotelli e32ab15b1f feature: support autorefs plugin ...

This change brings support for using autorefs without mkdocstrings.

In order to support that, we incorporate Zensical-related code from mkdocstrings within our code base, for better control (and much more elegant logic).

Before, mkdocstrings would expose a Markdown extension as "mkdocstrings", that Zensical would add (as a string) to its configured Markdown extensions list when detecting the plugin. Now, Zensical instantiates the extension itself (which simplifies things a lot since we don't have to synchronize releases -and therefore code!- of Zensical and mkdocstrings).

Instead of having several possible sources for autorefs data (mkdocstrings and autorefs itself), we use a global data store that both autorefs and mkdocstrings reuse to register data. Zensical can simply retrieve this data when ready, with a call_method0 Pyo3 call (like before).

We instantiate the autorefs Markdown extension ourselves too, while mocking the classes used by mkdocstrings (autorefs plugin, MkDocs pages) to provide the same interface. What's nice about this is that we can now set the current page being rendered in autorefs without having to inject a dummy Markdown processor (that would before just act as a data store, for mkdocstrings to retrieve the current page and set it on the autorefs plugin instance). Since we control the (mocked) plugin, we can easily change its current page attribute.

This change effectively decouples Zensical from mkdocstrings, which means users upgrading Zensical don't even have to upgrade mkdocstrings.

Signed-off-by: Timothée Mazzucotelli <dev@pawamoy.fr>

2026-02-10 21:35:20 +01:00

..

zensical

feature: support autorefs plugin

2026-02-10 21:35:20 +01:00