Thanks for the great library. You are still maintaining earmark_parser, right?

To generate xml/html text from an AST, there are also floki and xml_builder_ex. I wonder if this is a good time to consolidate.

Thanks for all your work on this @RobertDober! This library has been so useful

Absolutely

May I ask from your maintainer’s perspective what you see as the next challenges and goals for the project?

Based on recent context [1] [2], I intuit that ex_doc’s needs have so specialized around its domain as to want to operate on markdown AST directly to generate its own HTML, and so after the split Earmark is mainly meant to be a general-purpose MD → HTML renderer that may or may not use EarmarkParser under the hood. That means that new releases will primarily be supporting 2nd-tier usecases like PhoenixMarkdown et al?

It’s a little hard to glean what a maintainer needs to step up to do next aside from triage, as many of the GH issues and discussions are still very pre-split and parser oriented, and the hex.pm downstream dependencies list is and will likely forever remain populated by every ex_doc consumer. What are your hopes for the project post-handoff?

I completely agree with your conclusion, however I have a different vision of the premesis.

ex_doc is a dream client many of the most bright developers work there, they tweak the AST with great mastery and for their needs, but the parser’s feature set did almost not evolve since I seperated it from Earmark.

The main motivation was removing the dependency to avoid simply problems with old libraries that do not catch up with EarmarkParser versions needed via Earmark and not the version used by ex_doc. There would be an obvious workaround for that, as EarmarkParser cannot use ex_doc itself. One can check the mix.exs file to show how it is done ;). But ex_doc is a hex package and therefore shall be useable as such.

But I am defintely at a point where just concentrating on the parser with just the options ex_doc needs, seems necessary to be capable to maintain the parser for some while

It’s a little hard to glean what a maintainer needs to step up to do next aside from triage, as many of the GH issues and discussions are still very pre-split and parser oriented, and the hex.pm downstream dependencies list is and will likely forever remain populated by every ex_doc consumer. What are your hopes for the project post-handoff?

It might easily be that I am a little bit too close to see the big picture. Maybe I should have be more firm when accepting parser oriented issues, but my feeling is that there are few :shrug:

I was actually hoping that Earmark might become smaller with the time and that many plugins might be created, as AST postprocessors.

A new, motivated maintainer with a younger mind ;), I would hope, might address this issue much better than I did, and create a much better interface for postprocessing the AST before rendering.

I am very happy to announce that Amit has volunteered to maintain Earmark.
Let me thank him for his courage ;).
From now on I will only announce EarmarkParser releases here and Amit will be welcome to announce Earmark releases here if he wishes to do so, but that is completely up to him.

Hopefully this post will get lots of likes as a warm welcome to him