On 17/03/2024 13.25, Igor Mironchik wrote: > > On 17.03.2024 10:33, Benson Muite wrote: >> On 15/03/2024 16.20, Igor Mironchik wrote: >>> On 15.03.2024 16:01, Benson Muite wrote: >>>> Is there a roadmap? Might it be possible to integrate other markup >>>> formats, for example AsciiDoc >>> >>> Do we have any C/C++ Open Source Parser for AsciiDoc? Fully-featured, >>> tested... >>> >> Not at present unfortunately. Main implementation is Ruby, which can be >> compiled to Javascript or a Java library. There is also a Python >> implementation and ongoing work to produce Haskell and Rust >> implementations. > > > Well, by mistake I wrote md4qt. I know what this work is (parse Markup > languages). It's not so trivial task, and it needs a lot of time to > write and test such things. But I didn't say no. If I have md4qt, where > I have Document for a tree representation, I can have a look at AsciiDoc > and write something like asciidoc4qt, that will use the same structures > for parsed document. In this case we can use absolutely the same > converter to PDF. > > I can start such thing. Ok. Does AsciiDoc have well documented format? Yes. > Does it have a set of tests? > > I don't know how complicated AsciiDoc format is, maybe it's simpler of > Markdown? > It is more complicated than Markdown as it is more complete and allows for some self-consistent extensibility. > Markdown, despite its apparent simplicity, is a little complicated in > implementation. I've made 356 commits to implement and test it, and > spent some time for it, but it worth it. > > In case of markdown-tools, if it will support CommonMark 0.31.2 with > major GFM and latest AsciiDoc, will you accept my project? > Cannot answer whether the project will be accepted, am not a sponsor. It seems you are following the review process.
There is a lack of tools for AsciiDoc, but would not make that the primary concern. If it can be done, it would be nice, but it seems challenging.
