New Version of Viewrendered3 Updates Asciidoc Handling.

[Thomas Passin]

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.  Note that this is not the same as the adoc directive that Leo already has.

There are some limitations, and not every Asciidoc construct has 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.

[k-hen]

This is really excellent - and a very big help - thank you Tom :-)

Kevin

On Tuesday, September 1, 2020 at 11:16:24 AM UTC-4 tbp1...@gmail.com wrote:

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.  Note 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:

[Thomas Passin]

On Tuesday, September 1, 2020 at 11:16:24 AM UTC-4, Thomas Passin wrote:

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

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.

I just installed Ruby and the asciidoctor gem that it runs.  It did convert that 20k asciidoc file in a twinkling.  I will get VR3 to use it too, and see how that works out.

[percepti...@gmail.com]

Nice!

--
You received this message because you are subscribed to a topic in the Google Groups "leo-editor" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/leo-editor/EJxEEFWSkRM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/eba583db-6dfe-4d10-9084-9d6869b8fdd0o%40googlegroups.com.

[Thomas Passin]

I've just submitted a pull request for viewsarendered3 v3.0b14 adding the ruby asciidoctor as an external rendering engine.  This has only been tested in Windows, so if anyone is interested, please try it out on Linux.  See the help message for information on installing asciidoctor and on the setting needed to tell VR3 to use it.

On my system, asciidoctor prints an odd error message to the console:

Invalid switch - "Users".

This is nothing that VR3 sets up, so I speculate that it is something incorrect in an asciidoctor configuration file.  I'll try to track it down if no one knows about it.

On Wed, 2020-09-02 at 12:37 -0700, Thomas Passin wrote:

On Tuesday, September 1, 2020 at 11:16:24 AM UTC-4, Thomas Passin wrote:

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

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.

I just installed Ruby and the asciidoctor gem that it runs.  It did convert that 20k asciidoc file in a twinkling.  I will get VR3 to use it too, and see how that works out.

--
You received this message because you are subscribed to a topic in the Google Groups "leo-editor" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/leo-editor/EJxEEFWSkRM/unsubscribe.

To unsubscribe from this group and all its topics, send an email to leo-e...@googlegroups.com.

[Edward K. Ream]

On Wednesday, September 2, 2020 at 10:30:08 PM UTC-5, Thomas Passin wrote:

I've just submitted a pull request for viewsarendered3 v3.0b14

I've merged the PR. pylint gives this complaint:

************* Module leo.plugins.viewrendered3
leo\plugins\viewrendered3.py:1803:23: E0602: Undefined variable 'AsciiDocError' (undefined-variable)

Do you get the same complaint? If so, please attempt to remove it.  Thanks.

Edward

[Thomas Passin]

Actually, I knew about it.  I'm not sure if it's real or something that pylint doesn't understand (I think it's this).  I'll be looking at it.  If it's real, it will happen when the asciidoc3 processor raises that type of error, which I have seen but not very often.

[Edward K. Ream]

On Thu, Sep 3, 2020 at 7:30 AM Thomas Passin <tbp1...@gmail.com> wrote:

pylint gives this complaint:

************* Module leo.plugins.viewrendered3
leo\plugins\viewrendered3.py:1803:23: E0602: Undefined variable 'AsciiDocError' (undefined-variable)

Do you get the same complaint? If so, please attempt to remove it.  Thanks.

Actually, I knew about it.  I'm not sure if it's real or something that pylint doesn't understand (I think it's this). 

If it's a pylint mistake, please disable the message.

Edward

[Thomas Passin]

On Thursday, September 3, 2020 at 10:59:41 AM UTC-4, Edward K. Ream wrote:

Actually, I knew about it.  I'm not sure if it's real or something that pylint doesn't understand (I think it's this). 

If it's a pylint mistake, please disable the message.

 I will once I'm sure.  I purposely have not disabled the message until I'm convinced it's spurious.

[Thomas Passin]

The pylint message about an undefined variable was mistaken because that variable can only be used after the condition has been met.  Tested to confirm.

I have created a PR for this updated version.

Unless someone reports anything seriously wrong or trivial to fix in the next few days, I will release it as a non-beta release.  In the meantime, this version is V3.0b15.