I've issued a PR for VR3, and otherwise it is available from my Git repo on the vr3-asciidoc branch -
https://github.com/tbpassin/leo-editor/tree/vr3-asciidoc/leo The processing for Asciidoc has been upgraded to be on a par with reStructured Text and Markdown. This means that it handles rendering an entire subtree, code blocks only, Python code execution, and honors @/@c and @image directives. Trees and @language blocks need to use the name "asciidoc" in language directives. Not that this is *not* the same as the adoc directive that Leo already has. There are some limitations, and not every Asciidoc construct hast been tested: - an file include instruction inside a code block will not be understood. - Mathjax symbols and equations do not work even though the Asciidoc3 documentation suggests it should. I have found that Asciidoc processing is *much slower* than for RsT and Md. For example, 15k of Rst takes much less than a second to process but 20k of Asciidoc text takes about 10 seconds on my computer, which is pretty fast. So I can't recommend rendering entire subtrees if they are long. It is likely that using the Ruby version of asciidoc would be much faster (they claim a factor of 100), but I have not tested this. VR3 can use two Python versions of Asciidoc processors - the original asciidoc and the fork asciidoc3. There is a setting to prefer one over the other, e.g. - @bool vr3-prefer-asciidoc3 = False VR3 will try to import their code. If that fails, it will fall back to running the processor's executable file external to Leo, if that file can be found. On Windows, this means a file named asciidoc.exe or asciidoc.cmd (or their asciidoc3 counterparts). The processor must be on the system path. There are some installation complications. asciidoc is available as a zipped package and is not available via pip. Unzip it in some convenient location. VR3 has a new setting to tell it where the unzipped asciidoc directory is. For example - @string vr3-asciidoc-path = D:\utility\asciidoc-9.0.2 asciidoc3 is available via pip but needs a post-processing step to complete its setup. On some Windows installations this post-processing step may fail. If so, the asciidoc3 test program will probably fail also, as well as VR3's imported asciidoc3 code. I have proposed fixes for these bugs on the asciidoc3 github site. You can make these fixes yourself if you want. See these threads for details - - https://github.com/asciidoc3/asciidoc3/issues/9 - https://github.com/asciidoc3/asciidoc3/issues/10 The maintainer seems to be interested in fixing the issues, so perhaps soon there will be a new version available. Pending this update, it might be easier to use asciidoc instead. I have not noticed performance difference between the two processors. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/de05010a-4b92-42ac-a465-2f80b8754870o%40googlegroups.com.
