Viewrendered3 Advice and Thoughts Sought

[Thomas Passin]

As I finish up the work on the Viewrendered3 plugin, I'd appreciate some advice on a few points.  One thing I'd like to know is whether it is considered acceptable to place a css style sheet in the plugins directory.  I know that some plugins do put a UI definition file there.

Here's the context for my question.  It's about being able to locate the ReStructured Text (RsT) stylesheet.  My goal is to have the plugin work out of the box without the user having to know or care about any stylesheet. For MD, it's possible to get the MD processor to emit its spreadsheet.  I have a few tweeks I give it to improve the appearance for literal and code blocks.  On startup, if no spreadsheet is specified, and the default one is not found, the plugin creates one and stores it in a specified location. This way, the user doesn't have to fuss with the stylesheet at all unless he wants to.

For RsT (i.e., docutils), though, this tactic isn't available.  The plugin can find the default docutils stylesheet, but it has to be modified to support colorizing and my mods for the literal and code blocks.  The usual way to have a stylesheet with the changes, and have it point to the docutils one.  But that means that I have to write the whole thing such that it includes the pointer to the docutils stylesheet.  I'd rather not clutter the code with a large block of static text that would hardly ever be used except once or twice to create the stylesheet.

I could just copy the docutils stylesheet and the extensions into a single stylesheet.  Docutils doesn't recommend this in case they should change the default one.   In any event, if I go that route, the only place it could reasonably go would be in the plugins directory.  Otherwise the user would have to get the file from somewhere, and put it into the right location, which would be different for Windows and Linux.  That's undesirable, and asking for trouble.

So that's my question - is it OK to put the default RsT stylesheet into the plugins directory?

[Thomas Passin]

On Monday, March 2, 2020 at 10:59:57 PM UTC-5, Thomas Passin wrote:

As I finish up the work on the Viewrendered3 plugin, I'd appreciate some advice on a few points. 

A second question is about docks.  At the moment, I have not got the plugin working with the old, dockless mechanism.  I have been working on the assumption that this would be good enough because the  non-dock configuration would be fading away.  But from some recent discussion threads, I see that this is not the case.  There is still real interest in dockless.

My question here is whether to release the plugin even though it doesn't work dockless, or to delay until I get that sorted out.  My difficulty here is that I don't really understand the whole pane system, especially dockless.  So I have to blindly copy other code, and if it doesn't quite fit how I've done some things, I have a problem.  I don't like being in this position, but there it is.

So advice about this issue will be very gratefully received!

[gar]

Hello Thomas!

VR3 plugin is very desired for me, but choosing btw vr3 and dockless I would choose dockless. And believe that there are many such users who dont want to struggle against strange algo of docks arrangement.

So in my opinion there's no matter would the first version of VR3 support dockless gui or not. But it is crucially important that there in the future appear a version that would.

May be you would release ASAP and then take a time to understand how dockless gui works and how to deal with it? Meanwhile we can test and report bugs :-) which you will take into account in the next release with support of dockless.

[Thomas Passin]

I should probably have started with a summary of what VR3 is all about.  Here it is.

VR3 is a re-implementation of my minor enhancement of viewrendered2 (to be called "VR2+").  This was needed because VR2 was written for QT4 and didn't work with QT5.  Edward (@ekr) updated viewrendered to work with QT5, and I undertook to redo VR2+ for QT5.  Of course, I reused all of the new VR except for the enhancements, which I mostly modeled on VR2+.  I have also added a few more enhancements.

Here's a summary of the enhancements:

1. The RsT enhancements have been applied to MD blocks as well.

2. A node can have any number of @language python blocks mixed in with @language rst/md blocks. (but you can't mix and match - it's either md or rst in any one node).  Code blocks are colorized.

3. The language-specific block designators still work, such as code fences in MD.

4. An entire subtree can be rendered if desired.

5.  Mathjax can be rendered.

6. You can use RsT (or MD) in a docstring and it will be treated as literal text, not Rst.

7. You can display the the code blocks in a node or tree.

8. You can execute the python code in a node or subtree.  Any print() output will be inserted below the rendered node.

9.  You can display a subtree while you are editing a single node of that tree.

10.  You can specify by a menu selection whether RsT, MD, or plain text should be the default.  This does not override an @language directive in  the headline.  It applies when a node doesn't have an @language directive in the headline.

11. You can export the rendering as HTML to the system browser.

12.  Honors @ and @c directives (not @others or <<named sections>>, though).

[Thomas Passin]

Thank you, Gar!  I sure understand about wanting to stay with dockless.  In fact, I delayed upgrading from V5.9 for a long time because I thought that it required docks.  (Well, that and I knew that VR2+ wouldn't work). But I'd have to say that I've made my peace with the docks, even with their odd quirks.

I guess that I'll agonize over this a bit more, and hope for more opinions.

[Edward K. Ream]

On Mon, Mar 2, 2020 at 10:00 PM Thomas Passin <tbp1...@gmail.com> wrote:

> ...is considered acceptable to place a css style sheet in the plugins directory.

Yes. Plugins can even create sub-directories in the plugins directory.

Edward

[Edward K. Ream]

On Mon, Mar 2, 2020 at 10:08 PM Thomas Passin <tbp1...@gmail.com> wrote:

My question here is whether to release the plugin even though it doesn't work dockless.

It's fine to do that. Not all plugins work in all environments.

Edward

[Edward K. Ream]

On Mon, Mar 2, 2020 at 10:26 PM Thomas Passin <tbp1...@gmail.com> wrote:

I should probably have started with a summary of what VR3 is all about.

Thanks for this.

Edward

[Thomas Passin]

Thank you, Edward.

[Thomas Passin]

Thanks, Gar and Edward. I have combined the two stylesheets into one and placed it into a directory in the plugins directory.  They won't be automatically be updated when docutils updates theirs, but I think that's a small price to pay for simplicity.

You can still specify your own stylesheet, but if you don't or it doesn't exist at that location, VR3 will use its default one.  And it works that way for the MD stylesheet, too.

The one thing for me to fix up before I release the docks-only beta is to get it working right for documentation rendering, such as the plugin docstrings.  For some reason, they don't get routed properly to theVR3 plugin.

BTW, VR3 has its own commands, which begin with "vr3-" instead of "vr-".  Edward, does Leo use "vr-" commands for docstring displays in viewrendered?

On Tuesday, March 3, 2020 at 4:34:22 AM UTC-5, Edward K. Ream wrote:

[gar]

Good news!

Thomas, can the then later use vr3 for say doxygen or javadocs docstings preview?

Leo is very good as a code documenter.

ср, 4 мар. 2020 г. в 06:41, Thomas Passin <tbp1...@gmail.com>:

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/3e4a8205-5cc7-471c-a3ff-056391e81edd%40googlegroups.com.

[Thomas Passin]

On Wednesday, March 4, 2020 at 12:08:15 AM UTC-5, gar wrote:

Good news!

Thomas, can the then later use vr3 for say doxygen or javadocs docstings preview?

Currently it can do anything that viewrendered can do, plus the enhancements for RsT and MD.  In the future, I hope to have it render for any of the languages that @language knows about.  Execution of code blocks in these languages is very questionable, and I don't know if I will try to execution working for anything but Python.

For this first release, any @language besides RsT, MD, and Python will be rendered as plain text (not literal text).

Now, javadocs is something else, if you want to render as anything besides plain text.  If a renderer in Python already exists, I'd say that the chances are good.  Otherwise, I'm not sure that I want to get into writing one myself.  But I might if it wouldn't be too time-consuming.

Maybe pandocs will render javadocs.  If it will, then it should be feasible.  The main thing would then be to know how to identify the docstring so it could be sent to pandocs.

After VR3 is in good working order, then I could look into that.  The good news is that I process MD nodes with a (very) rudimentary state machine, so I would think that states could be written for javascript blocks.

 

Leo is very good as a code documenter.

It surely is, as long as you are using Leo itself.  One reason VR3 can display just the code blocks is so that you could export to a browser, then copy the browser window and paste it into a file. That lets you quickly work something up in a Leo node or tree, include non-code discussion as RsT or MD, and still get the code out. A bit clumsy, and I may improve the process later, but I've done it more than once.

40googlegroups.com.

[Edward K. Ream]

On Tue, Mar 3, 2020 at 9:41 PM Thomas Passin <tbp1...@gmail.com> wrote:

BTW, VR3 has its own commands, which begin with "vr3-" instead of "vr-".  Edward, does Leo use "vr-" commands for docstring displays in viewrendered?

I don't remember.

The answer should be apparent in the vr plugin. See if you can discover it for yourself. If you get stuck, I'll be glad to help.

Edward

[Thomas Passin]

All right, VR3 is now displaying the docstrings and "help-for-command" is working.  It only works for RsT strings, but since that seems to be all that gets sent to it, I guess that's OK for now.

I found one or two changes needed in other Leo code to fully accommodate VR3, and they will be in the pull request too.  I'm ready to do a little cleanup of the code, and then I'll send it up the line.

TomP

[Edward K. Ream]

On Wed, Mar 4, 2020 at 5:24 PM Thomas Passin <tbp1...@gmail.com> wrote:

On Wednesday, March 4, 2020 at 6:12:51 AM UTC-5, Edward K. Ream wrote:

 

All right, VR3 is now displaying the docstrings and "help-for-command" is working.  It only works for RsT strings, but since that seems to be all that gets sent to it, I guess that's OK for now.

Excellent.

I found one or two changes needed in other Leo code to fully accommodate VR3, and they will be in the pull request too.  I'm ready to do a little cleanup of the code, and then I'll send it up the line.

Many thanks for this work. There may be some overlap between your work and my work with Qt docks. In vr.create_pane, this line has been commented out.

dw.leo_docks.append(dock)

If this line exists in your code, please comment it out. In any case, I'll handle any merge conflicts.

Edward

[Thomas Passin]

On Thursday, March 5, 2020 at 4:51:19 AM UTC-5, Edward K. Ream wrote:

Many thanks for this work. There may be some overlap between your work and my work with Qt docks. In vr.create_pane, this line has been commented out.

dw.leo_docks.append(dock)

If this line exists in your code, please comment it out. In any case, I'll handle any merge conflicts.

Done, thanks.

[Thomas Passin]

On Wednesday, March 4, 2020 at 12:32:01 AM UTC-5, Thomas Passin wrote:

On Wednesday, March 4, 2020 at 12:08:15 AM UTC-5, gar wrote:

For this first release, any @language besides RsT, MD, and Python will be rendered as plain text (not literal text).

Now it will render javascript and java in colorized code blocks, for both RsT and Markdown.   It doesn't know about javadocs, though.  And of course, it can't execute any language except Python.  Maybe later ...