Implement a Mallard Reader. #2700
Conversation
See http://projectmallard.org for more information, mallard is basically a dumbed down docbook with the added notion of http://projectmallard.org/1.0/mal_links , which usefulness is very debatable. The documentation maintainers of developer.gnome.org might consider migrating to CommonMark, that's why I wrote this reader, which is basically a copy pasted and trimmed down version of the docbook one. See https://github.com/GNOME/gnome-devel-docs for a decent corpus of mallard pages. The coverage is not total for this reader, but it's already useful as is and I'll certainly get back to it pretty soon.
|
I'd rather avoid code duplication. If mallard really is That's how we handle the difference between html and html5, +++ Mathieu Duponchelle [Feb 06 16 12:13 ]:
|
|
Well the thing is that it isn't really a subset, for example where docbook has para / informalpara / formalpara, mallard has p, if you look at the list of block elements here -> https://github.com/jgm/pandoc/pull/2700/files#diff-3765f376fcbd39161286f22a5375facfR129 you'll see that it's similar but not identical, there are also some tiny differences in parsing certain things, and these differences piling up make factorization of the code less obvious than it could be. Also please note that it's my second time writing haskell, and everything still seems a bit mysterious to me (<$> oO) . I think what we should do is have you pay a closer look at the differences between both readers, decide what's worth sharing and I'll be happy to do that, cause I'm fairly sure the solutions I'll come up with will not be exactly the cleanest ones. I don't mind waiting, as there's obviously no risk of conflicts here, up to you :) |
|
Also do you hang out on some irc channels ? I've got a lot of silly questions to ask you about cmark, I'm digging into the code right now to find the "parsing extensions should go there" sign :) |
|
+++ Mathieu Duponchelle [Feb 06 16 14:11 ]:
I don't, no. Email is the best way for me. |
|
+++ Mathieu Duponchelle [Feb 06 16 14:07 ]:
I think what we should do is have you pay a closer look at the
differences between both readers, decide what's worth sharing and I'll
be happy to do that, cause I'm fairly sure the solutions I'll come up
with will not be exactly the cleanest ones. I don't mind waiting, as
there's obviously no risk of conflicts here, up to you :)
OK, I'll have a look when I have a chance (might be a while
though!).
|
|
Cool thanks, however I've given this a bit more thought and an alternate approach could also be to just merge this and take the time to review / improve it when there's time as :
Note that I don't really need this upstream, as I only need it at "porting-time", but I wouldn't like it to just get forgotten. I can't promise I'll stick around for doing the factorization work, but that's quite likely :) Your call anyway ! |
Correction, it's not, but the "code-path dependencies" it introduces are purely in the Reader -> Pandoc direction, not sure how to best express that but the net result is that removing it or updating it will not require any changes elswehere, and it would even nearly be possible to revert the patch without conflicts at any point in Pandoc's future history (nearly because the cabal file and the import of Mallard might conflict, but that's really a non-issue) |
|
I've merged this into my mallard branch. |
|
Heh, that's nice :) Pretty much forgot about that request, regarding tables for example, indeed, my target was commonmark which has no syntax for them at the moment. Did you think about code sharing between this reader and the docbook reader? Do you think it is practical ? |
|
The CommonMark writer will output raw HTML for tables (currently). Code sharing: yes, there's too much duplication for my tastes. I think the way to do this well would be to make the mallard reader a "variant" of the docbook reader. That is, the DocBook module could provide a function |
|
This seems to have stalled out. I assume that the branch would require a lot of work to bring it up to date. Should we keep this issue open, close it, or maybe reopen as a new issue to give it a clean slate? Mallard/Ducktype is stable now, with v1.1 published some years ago. Further development appears to have faded, judging from the GitHub repo and mailing list, but the gnome project continues to actively use it. |
See http://projectmallard.org for more information, mallard is
basically a simplified docbook with the added notion of
http://projectmallard.org/1.0/mal_links.
The documentation maintainers of developer.gnome.org
might consider migrating to CommonMark, that's why I wrote this
reader, which is basically a copy pasted and trimmed down version
of the docbook one.
See https://github.com/GNOME/gnome-devel-docs for a decent corpus
of mallard pages.
The coverage is not total for this reader, but it's already useful
as is and I'll certainly get back to it pretty soon.
I'm really not sure about the handling of the
<links>node, I'll be interested in other ideas.Thanks again for that awesome piece of software :)