The way it's supposed to work is that the node headline will become a title in the final markup unless the body already starts with that exact string. There is a boolean setting, *use_node_headline,* to turn that on or off but it's supposed to be True by default.
I've attached an outline with a 2-node subtree that I use for testing, and also the VR3 rst output using the command *vr3-open-markup-in-editor*. Open the outline, open VR3, and check the *Entire Tree* option. Then highlight the parent (top) node of the tree. The entire tree should render, including the node headlines as headings. You can check that against the .rst file I've attached. Note that This file contains some directives understood by VR3 that get translated into RsT in the output. The rst3 command doesn't understand them, so just ignore that kind of difference. The main point is that when the option is checked, the entire subtree starting at the selected node will be rendered. If that node has no children then only that one node will be rendered. The attached outline also has a second top-level subtree which has the same content as the first, but it's set up to produce an @rst3 file when that command is run. There are other ways you could set it up, but I like doing it this way. If you select the top content node (the first child of the @rst node), VR3 will not think that *@rst VR3 Example* is supposed to be included as a headline. On Wednesday, January 12, 2022 at 2:10:19 PM UTC-5 Rob wrote: > Thanks for that! However, when I try using vr3, I don't get the subtree > headline text marked up, so I'm missing the structure context (VR3 window > as well as external editor). Am I missing something? > > Rob... > > On Wednesday, January 12, 2022 at 1:10:04 PM UTC-5 tbp1...@gmail.com > wrote: > >> For use cases 1 and 2, you could also try rendering with the >> Viewrendered3 plugin, then exporting the HTML to the browser. If you have >> more than one node in the tree, check "Entire Tree" in the VR3 *View >> Options* menu. If you go this route, you don't even need an @rst file >> node nor an external file to manage. VR3 also has a minibuffer command >> *vr3-open-markup-in-editor* that opens the generated RsT markup in your >> editor, similar to the *rst-clipboard* command. If you should ever want >> to insert math symbols or equations into your document, VR3 can be >> configured to render them beautifully via MathJax.. >> >> For use case 3, I did that once myself, to write the first draft of a >> tech note in .odt. I liked writing it in Leo that way better than using >> Libreoffice or Word, because the outlining works so much easier and better >> with Leo. >> >> Otherwise I have mostly used @rst node trees to generate Sphinx >> documents. So much better than if you had to manage all those documents >> separately by hand! >> >> On Wednesday, January 12, 2022 at 11:11:44 AM UTC-5 Rob wrote: >> >>> I find Leo's @rst commands especially useful in a variety of situations >>> and thought other Leonistas might benefit from these use cases and ideas. I >>> suspect these weren't what Edward had in mind when he added support for >>> reStructuredText (rst) to Leo. >>> >>> 1. Use case #1; create `temporary` text files. I am a youth volleyball >>> coach and twice a week I prepare detailed practice plans to share with my >>> assistant coach and `quick print` them for easy reference while on the >>> court (not allowed to use my phone while coaching). Each practice plan is a >>> Leo outline under an @rst node. When complete, I simply invoke the rst3 >>> command and Leo automagically creates the small text file that I need for >>> just that day's practice. I print and share the file, then delete it (it's >>> `temporary`). The outline still exists in my master Leo file for later >>> reference if needed. >>> >>> 2. Use case #2; copy Leo's outline to the clipboard as rst with headline >>> text. Two examples: >>> >>> 1. I teach various classes which use a web application for creating >>> content as well as teacher and student notes. I write each class session in >>> a Leo @rst node. When complete, I use a rst-clipboard command (thanks >>> Edward for the script!) to copy the outline and paste into the web >>> application, complete with headline and body text (headlines marked up as >>> expected in rst). >>> >>> 2. Occasionally I might need a long email to have some rst-type >>> structure (marked up headlines and body text). I write the email in Leo in >>> an @rst node and use the rst-clipboard command, then paste from clipboard >>> into the email. >>> >>> 3. Use case #3; create source files for pandoc conversions >>> <https://pandoc.org>. Some of my clients need support documents in >>> .docx or .odt format (occasionally .html). I prefer to write everything in >>> reStructuredText markdown format. To accommodate my clients, I create the >>> source document in Leo under an @rst node, then the rst3 command creates >>> the source file which pandoc uses to generate the .docx, .odt (or whatever) >>> `external` file the client needs. This workflow has many advantages for me, >>> not the least of which is I can have one `master` Leo file for each client >>> containing all of their support documents regardless of how many >>> individual, discreet documents the client needs. Cloning nodes in also Leo >>> makes it super easy to have common text snippets across multiple `external` >>> documents. >>> >>> @rst nodes are an invaluable tool in my everyday work. I'd love to hear >>> how others might be using @rst in their workflow. >>> >>> Rob... >>> >> -- 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/9a3a3ec7-5957-4e03-b3c4-4f23fc362d32n%40googlegroups.com.
