Pluggable Extensions?

[grom358]

Is there any plans in future to have pluggable extensions (perhaps there is already and I missed it)?

I wish to have more complex tables, eg:

+---------------+---------------+-----------------+
| First Header  | Second Header | Third Header    |
+===============+===============+=================+
| A cell that   | A cell that spans multiple      |
| spans         | columns.                        |
| multiple rows +---------------+-----------------+
|               | One, two cell | Red & blue cell |
+---------------+---------------+-----------------+

Or taking example from mdbook I was writing this is the current markdown:

|Accumulation<br>RPE 7-8|60% x 5 x 10+|65% x 6 x 8+|70% x 6 x 5+|75% x 7 x 3+|
|Intensification<br>RPE 8-9|55% x 5<br>62.5% x 5<br>67.5% x 3 x 10+|60% x 3<br>67.5% x 3<br>72.5% x 3 x 8+|65% x 5<br>72.5% x 5<br>77.5% x 4 x 5+|70% x 1<br>77.5% x 1<br>82.5% x 5 x 3+|
|Realization<br>RPE 10|50% x 5<br>60% x 3<br>70% x 1<br>75% x 1+|50% x 5<br>60% x 3<br>70% x 2<br>75% x 1<br>80% x 1+|50% x 5<br>60% x 3<br>70% x 2<br>75% x 1<br>80% x 1<br>85% x 1+|50% x 5<br>60% x 3<br>70% x 2<br>75% x 1<br>80% x 1<br>85% x 1<br>90% x 1+|
|Deload|40% x 5<br>50% x 5<br>60% x 5|40% x 5<br>50% x 5<br>60% x 5|40% x 5<br>50% x 5<br>60% x 5|40% x 5<br>50% x 5<br>60% x 5|

Using this grid syntax it would be:

+---------------------+-----------------+----------------+----------------+----------------+
| Phase               | 10s             | 8s             | 5s             | 3s             |
+=====================+:===============:+:==============:+:==============:+:==============:+
| Accumulation<br>    | 60% x 5 x 10+   | 65% x 6 x 8+   | 70% x 6 x 5+   | 75% x 7 x 3+   |
| RPE 7-8             |                 |                |                |                |
+---------------------+-----------------+----------------+----------------+----------------+
| Intensification<br> | 55% x 5<br>     | 60% x 3<br>    | 65% x 5<br>    | 70% x 1<br>    |
| RPE 8-9             | 62% x 5<br>     | 67.5% x 3<br>  | 72.5% x 5<br>  | 77.5% x 1<br>  |
|                     | 67.5% x 3 x 10+ | 72.5% x 3 x 8+ | 77.5% x 4 x 5+ | 82.5% x 5 x 3+ |
+---------------------+-----------------+----------------+----------------+----------------+
| Realization<br>     | 50% x 5<br>     | 50% x 5<br>    | 50% x 5<br>    | 50% x 5<br>    |
| RPE 10              | 60% x 3<br>     | 60% x 3<br>    | 60% x 3<br>    | 60% x 3<br>    |
|                     | 70% x 1<br>     | 70% x 2<br>    | 70% x 2<br>    | 70% x 2<br>    |
|                     | 75% x 1+        | 75% x 1<br>    | 75% x 1<br>    | 75% x 1<br>    |
|                     |                 | 80% x 1+       | 80% x 1<br>    | 80% x 1<br>    |
|                     |                 |                | 85% x 1+       | 85% x 1<br>    |
|                     |                 |                |                | 90% x 1+       |
+---------------------+-----------------+----------------+----------------+----------------+
| Deload              | 40% x 5<br>     | 40% x 5<br>    | 40% x 5<br>    | 40% x 5<br>    |
|                     | 50% x 5<br>     | 50% x 5<br>    | 50% x 5<br>    | 50% x 5<br>    |
|                     | 60% x 5         | 60% x 5        | 60% x 5        | 60% x 5        |
+---------------------+-----------------+----------------+----------------+----------------+

[raphlinus]

There are no current plans to have pluggable extensions. It's a little tricky to do because CommonMark really doesn't have a clean grammar, but that's not to say it's impossible. If you want to see this feature, the best thing to do is review extension mechanisms in other Markdown libraries (I haven't really done this) and bring a proposal.

[orowith2os]

@raphlinus have you looked into this since the issue was made? I'd like to implement my own markdown dialect, and this would be nice.

I think the main issue is going to be the static-ness of Rust. It's probably best to implement extensions as a third party library that's loaded in, but Rust doesn't have a stable ABI. It might be best to have a mechanism that seamlessly handles this so one can write their extensions dynamically? I think you can do it if you don't mind a nasty C intermediary.

It's also worth concerning over versioning; being pre-1.0, the extension API can change in breaking ways. So some versioning would be needed.

[Martin1887]

I think the way to go nowadays is WebAssembly, but the main concern I see is the API for extensions and how integrating them in a seamless manner.

Probably the parsing code should be converted into a ruleset with priorities, but it is not clear if this is possible without losing too much performance.

What do you think, @raphlinus? Anyway, this is not a priority in the project and contributions are welcome but efforts will be focused in other more urgent issues and features requests like the 0.10 release and math support.

[rambip]

this would be very valuable for me too: I already extended this crate without forking it, but it's quite hacky:
https://github.com/rambip/pulldown-cmark-wikilink

And indeed, the difficulty seems to keep a good performance while adding arbitrary syntax
That seems quite difficult to do without exposing parts of the parsing logic.

As a first partial solution, the library could support parsing rules for what would be otherwise parsed as text, meaning it can not break the existing parser, just extend it.
I could imagine something like ExtendParser<MyParser> where MyParser implements parse(input: &str) -> Vec<ExtendEvent<Self::Item>>
(ExtendEvent<T> is just Event with a variant Custom(T))

[ssokolow]

I'd just be happy to have a way to hook something in before the smart punctuation and strikethrough extensions interpret the text so I can implement Compose key-style shortcodes like :'e:/:e': → é and :~n:/:n~: → ñ without having to disable them.