Provide custom image adapter

[lucperkins]

Akin to issues #253 and #267, I like to provide custom image rendering whenever possible. To give an example, I often like to wrap the image in a figure element, display the title as a figcaption, and make the image clickable. Basically turning this...

![My caption)(/img/foo.png)

...as this:

<figure>
  <a href="/img/foo.png" target="_blank">
    <img src="/img/foo.png" />
  </a>

  <figcaption>
    My caption
  </figcaption>
</figure>

One of many possible use cases, of course, but nice to have. As with #257 and #266 I will submit a PR.

[kivikakk]

Sounds good to me — very happy to take such a PR.

I'm starting to think about ways to make the renderer more pluggable/overridable in general, rather than with piecewise plugins that target each node type. Assortment of (incompatible) ideas:

• Define a rendering trait with one method per node type; each method's default implementation corresponds to the spec-compatible output.
• Define a generic node rendering "middleware"-type plugin which is handed each node during render; middleware can handle the render entirely itself, simply defer to the next-in-line (which may just be the base implementation), or wrap the result of next-in-line.
• …?

Ideally we want composability without sacrificing too much in the way of speed. Let me know if you have any thoughts!

[JmPotato]

Sounds good to me — very happy to take such a PR.

I'm starting to think about ways to make the renderer more pluggable/overridable in general, rather than with piecewise plugins that target each node type. Assortment of (incompatible) ideas:

* Define a rendering trait with one method per node type; each method's default implementation corresponds to the spec-compatible output.

* Define a generic node rendering "middleware"-type plugin which is handed each node during render; middleware can handle the render entirely itself, simply defer to the next-in-line (which may just be the base implementation), or wrap the result of next-in-line.

* …?

Ideally we want composability without sacrificing too much in the way of speed. Let me know if you have any thoughts!

I have the same need here. After digging into the relevant code, I found that to achieve the implementation you mentioned, we still have some issues to resolve:

• Since we use an AST here, the "types" of different nodes are represented as different enum variants. It's impossible to attach a trait to them.
• Actually, it is related to the above question. Because we cannot implement generics at the compiler level, it seems that we cannot get rid of the form match NodeValue during rendering and thus cannot introduce this middleware concept.

Directly providing a NodeAdopter like HeadingAdapter seems feasible but may lack a user-friendly interface to eliminate some internal concepts like new_plain to ensure the user can focus on implementing the core rendering logic.

[levkk]

Came here looking for custom plugins as well. My use case is adding support for MkDocs-style !!! example and === Tabs extensions.