Library for rendering markdown

I need library for rendering markdown which allows me to get access to its data and pre/postprocess it. Earmark doesn’t allow this, it merely renders html from markdown. Is there any library which does?

Given markdown, how can I, for instance, say to earmark “give me all the images and their ‘src’ values” as a list or dictionary. I want to change their src values a bit before it renders as html"? that is, I want to dynamically append “” to each “src” of an image. whereas in a database it must remain the same – without “”

will I have to parse and create it myself via regexp? then it’s not what I’m looking for.

There is Earmark.parse/2, which will return an AST of the markdown. You can traverse and alter it as you like, before passing it to Earmark.HtmlRenderer.render/2.

I have to admit, that isn’t documented very well, and you have to figure out yourself how the AST looks like. Even worse, since there is no documentation, we have to assume the AST is an opauqe type which internal structure may change with updates.

But postprocessing the AST seems a reasonable demand, can you do a feature request?


This is not probably exactly what do you, and this library is still in a very alpha stage, but it is highly customizable and provides what you need out of the box. I am biased, though, since I am the author.

This library provides callbacks on literally everything, it supports custom markdown syntax, collectors and, even better to suit your needs, it allows you to declare your own handler for any markdown entity declared (including images, of course.)

It’s written on pure binary pattern matching and supports streaming markdown input as well.


ну щас заценим.

Can you please answer in english that everyone is able to undertand?

FIY google translates the sentence as:

Well now we’ll check it out.

1 Like

I think some pieces should be added here.

There is an open issue that hopefully will expose an AST. Right now using the exposed AST and modifying it and
rendering it seems like a really bad idea for the complexity of the task and the simple fact that the AST has to be considered internal, meaning that we might change it between patch versions for bugfixes or refactoring reasons.

Exposing the markdown as an AST seems a great idea, not many if any at all, markdown converters do that and I am excited about it.

I also feel that the exact format of the AST and the tools to manipulate them especially the renderer(s) are still open to discussion and the aforementioned issue is the place to go if you want to participate in that process.

However (my) allocable time is the issue here and this will take some time.


Yes indeed it is not documented at all, the reason being that it shall not be exposed. I elaborate on this a bit more above. Maybe we need to be much clearer about this in the generated hex docs.