VR3 Supports @pdf Nodes

[Thomas Passin]

I have added support for @pdf nodes to VR3.  It's similar to the same support in the viewrendered plugin that was added recently.

A node whose headline starts with @pdf and whose headline or body contains a path to a .pdf file on the same computer will display the rendered PDF in the vr3 pane. The path can be either absolute or relative to the path in effect at the node.  It must use "/" for path separators, and must NOT start with file:

If the path is in the body, it must be the first line of the the body.  You can have any other text after that first line, so you can include comments about the file. This feature is one of the differences in the way that VR and VR3 process @pdf nodes.

If both the headline and the body contain a valid path, the one in the headline will be used.

I forgot to update the plugin's docstring, and I'll submit a PR for that soon.

I'm not planning to add support for @mathjax nodes because VR3 already supports mathjax embedded within RsT, MD, and Asciidoc nodes, and does it more flexibly in that mathjax, ordinary text, and images can be included in any of those nodes. 

[lewis]

These enhancements to VR3 are much appreciated. Some observations you already may be aware of...

I noticed that with Node headline @pdf
Body text is N:/leo/example.pdf

With vr3-show command given, when I select node the pdf shows in vr3 pane.

Where the Node headline does not exactly match the Body text e.g. :

Node headline @pdf N:/leo
Body text is N:/leo/example.pdf
When I select node it displays a file manager view of the N:/leo/ folder. This is quite useful to preview graphic files with VR3. Select a file and it shows in VR3 pane.

When the file manager appears this message shows in log pane:
js: crbug/1173575, non-JS module files deprecated.

[Thomas Passin]

Yes, what you report is what is intended.  It's  not exactly whether the head and body paths match.  It's that the headline takes priority.  The algorithm goes like this:

check headline for @pdf.

if yes:

    check headline for valid path. # Valid paths can be either absolute or relative.

    if valid:

        render path

    else:

       check body 1st line for valid path

       if valid:

         render path

       else:

         display "can't find" message.

The directory listing behavior is a function of the Chrome component that underlies a QWebEngineView. I can't control it. When I check if a path is valid, I don't distinguish between a file and a directory, and Chrome shows the directory listing for the latter.  The message, which I get too, suggests the directory listings may go away at some point.