On Thursday, December 26, 2013 11:19:07 AM UTC-6, Edward K. Ream wrote:
> ===== Summary
>
> The three parts of this post correspond to the three fundamental
> view-related operations: packing @view nodes, unpacking @view nodes and
> rearranging @auto trees using @auto-view nodes. The first two operations
> are straightforward; the third may be complicated, but it has no affect
> whatever on any other part of Leo.
>
I have been working for several days trying to understand @auto-view. Here
are some recent thoughts.
===== What @auto-view does
A crucial Aha: @auto-view should *not* contain url's for all nodes in an
@auto tree. Doing so would make @auto too similar to @shadow: the
structure in the @auto-view node would override the structure created by
the import code. That's not what we want!
This Aha refocuses my attention to the *differences* (deltas) between what
the importer gives us and what we want. There are only two kinds of
deltas: section references and organizer nodes.
Section references: Leo's importers *could* create section definition
nodes, with proper section references, and Leo's @auto write file could
write (without sentinels, of course) the section definitions in the proper
place. However, this cuteness is probably not worth the effort.
Organizer nodes: These are clearly desirable.
======= The organization of @views trees
Now that @auto-view nodes no longer contain all url's, but only the urls
for organizer nodes, it makes sense to re-imagine the structure of @views
tree. Here is the latest picture:
- @views
- @auto-view <url of @auto node>
- @organizers
- @organizer <headline>
- @clones
This organization eliminates the need for explicit "types" of urls. Each
@organizer node contains the url's of the child nodes that the organizer
node should contain.
The @clones node contains the clone links for the @auto node. It contains
a list of url's of nodes (in the outline!) to be linked (if possible!) to
nodes in the imported @auto tree.
===== Creating and updating these nodes.
The user could update these data by hand, but commands such as
create-organizer-node and delete-organizer-node could create @organizer
nodes automatically. Even these commands are a bit clumsy, but I see no
alternatives.
Leo will update all @clones nodes when reading and writing .leo files.
That's all for now. We are closer to a full design.
Still to do: provide a *precise* algorithm for rearranging an imported
@auto tree using @organizer nodes. This should be now easier now that most
nodes will stay where the importer puts them. Otoh, success, while
increasingly likely, is not guaranteed.
Edward
P.S. An earlier draft of this post discussed the reasons why the new
@auto-view algorithm is simpler than the @shadow algorithm. The main idea
is that @shadow is character oriented; the new algorithm is node oriented.
That makes the @auto-view algorithm fundamentally simpler, faster and more
reliable than @shadow. In particular, the contents of imported nodes do
not affect the @auto-view algorithm in any way, a huge simplification
compared to the @shadow algorithm.
EKR
--
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/groups/opt_out.
