Strictly speaking, bug #159 
<https://github.com/leo-editor/leo-editor/issues/159>is invalid.  But I'm 
not in the mood to be strict :-)

In fact, I'm downright happy.  How can that be?  I've spent two long days 
improving the code in leoRst.py when it didn't need to be improved.

Well, yes it did!  The new code is a significant collapse in complexity of 
way-too-complex code.  Formerly, the code that scanned for rst-related 
settings was a nightmare.  Now, it's dead easy.  For the first time the 
code is simple enough to remember:

1. All top-level commands must call rst.initSettings.
2. The code that writes each node must call rst.init_write.

I was expecting that the new code might be slower than the old.  In fact, 
it's half again faster!

When a collapse in complexity happens I look for more simplifications. bug 
#159 <https://github.com/leo-editor/leo-editor/issues/159>is an invitation 
to do just that.  The reason the bug is invalid is that @rst-option nodes 
do work, but only for their descendants! In practice, this is clumsy and 
confusing.

I propose to eliminate the following headline options:

    @rst-option
    @rst-options

These can always be replaced by @ @rst-options in the body pane. If you 
don't want the headline visible just put @rst-no-head in the headline.  
It's a perfect replacement.

    @rst-code
    @rst-doc

These would eliminate Easter Egg: code and doc modes.  Imo, these have been 
an utter failure.  Rather than creating impossible-to-remember modes, it 
would be much better to create mix-and-match switches that can be combined 
to get the result of the modes.

I don't remember exactly what the modes do, but I'm pretty sure that the 
intent of code and doc modes was to be able to format computer code more 
flexibly in documentation.  That's a worthy goal, and it is much closer now 
that the rst3 code is simpler.

As I was think of this for the first time in at least a year, I realized 
there are two parts of the problem:

1. "Gathering" nodes to be documented.
2. Formatting those nodes flexibly *without* having to change the gathered 
nodes.

**Gather nodes**: In the past, I only thought of clones as the way to 
gather nodes.  But that's way too restrictive!  Terry's bookmarks show that 
UNL's work reliably. And they could gather nodes from multiple outlines!

This suggests something like an @rst-gather command.  It would specify a 
list of nodes to gather under the @rst-gather node.  The list would be in 
the body.

**Formatting nodes**: It's not clear what new feature are required.  I just 
looked at the rst3 Command Reference.  Sheesh.  There are lots of hidden 
options.  They exist in LeoDocs.leo but they aren't written to Leo's web 
site.

Most options are only valid in one mode or another.  This seems crazy to 
me: I don't know what I was thinking of.  Now that I've forgotten the old 
ideas it may be possible to see something simpler.

Enough.  This has been way too long.  I'll be playing around with these 
ideas for the next day or so.

Your comments, please.

Edward

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to