Codecov Report

Base: 89.99% // Head: 89.72% // Decreases project coverage by -0.27% ⚠️

Coverage data is based on head (3b10f37) compared to base (84c320b).
Patch coverage: 89.18% of modified lines in pull request are covered.

@@            Coverage Diff             @@
##           master     #695      +/-   ##
==========================================
- Coverage   89.99%   89.72%   -0.27%     
==========================================
  Files          23       22       -1     
  Lines        2589     2658      +69     
==========================================
+ Hits         2330     2385      +55     
- Misses        259      273      +14     

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

cc @choldgraf @rowanc1

See: https://myst-parser--695.org.readthedocs.build/en/695/syntax/syntax.html#customising-external-url-resolution

This is essentially a more extensible version of https://myst-tools.org/docs/mystjs/external-references#wikipedia-links etc

Only looked through the docs and not the code, this looks great. On the face of it very similar to the like transformers we have in mystjs, but allows these to be set as data. The config options look sensible.

There is also very similar functionality in the extlink in sphinx:
https://www.sphinx-doc.org/en/master/usage/extensions/extlinks.html#confval-extlinks

How do you think this compares to extlink, and/or the advantages of this to address similar/same functionality? I like that these are picked up as markdown links, but maybe the config can be closer, or the same as sphinx already has?

How do you think this compares to extlink, and/or the advantages of this to address similar/same functionality?

These allow word functionality, by not simply using the %s, which to some degree is a deprecated aspect of python (replace by f-strings), by allowing the url to be fully decomposed. The dict format also allows future extensibility (for mor keys), rather than the tulple format, and this is already apparent in the ability to add classes to specific schemes.

Note I explicitly don't allow full jinja templating or actual python function manipulation of the string, in order to still allow for a "language-agnostic" configuration. I believe this is a good middle ground, of "full-extensibility" vs cross-language compatibility

Yep makes sense, the tuple format isn't very customizable, and this allows for named parts but stays close to a familiar format (jinja) without the complexity (which isn't necessary for links).

I feel like this is something that we could pick up really easily in mystjs from a config/functionality standpoint so don't see any divergence there!

I like the idea of having some of these turned on by default in jupyterbook in the future, especially the wiki/doi links.