On Thu, Dec 26, 2013 at 11:19 AM, Edward K. Ream <[email protected]>wrote:
>
> This is a "thinking out loud" post, except that I've had the luxury of
> revising my remarks.
>
A collapse in complexity has happened.
The original design called for an @view-data node, containing all
non-cloned children of view nodes. Instead, suppose all @view nodes are are
contained in an an @views (plural) node, by analogy with @chapters and
@chapter.
To use @view nodes, it would be natural to clone them, and move the clone
out from under the @views nodes to where they will actually be used.
This change in point of view solves a lot of problems:
1. The @view node *itself* becomes the place the store any non-cloned
children. The preferred representative of any child of an @view node
becomes the unl of that node *in the @views tree*.
The user has complete control over the location of the @views node. My
preference would be to put the @views node in the outline outside of any
@file node, but it could be placed in a node such as leoProjects.txt.
2. The view-pack and view-unpack operations become simpler.
The view-pack operation creates unl's for all *cloned* children of the
@view node, and deletes those cloned children. But the view-pack operation
does *not* delete *uncloned* nodes of the @view node. Simple and effective.
Similarly, the view-unpack operation just creates clones of all nodes whose
unl's appear in the @view node.
3. We could imagine a create-view operation that
a) creates an @view node at the present outline location and
b) creates a clone of that node as a child of the @views node.
In that case, the user can delete any @view node *outside* the @views trees
without losing data. This is true whether or not the @view node is packed
or unpacked.
4. The question of what to do with the headline of the @view node
disappears. The headline can have any form whatever, provided it starts
with @view.
The question of what to do with the body text of an @view node remains. It
seems prudent to create a convention that will separate the list of unl's
in packed nodes from existing body text.
5. In the initial post, I guessed that uA's would not be needed. However,
uA's are the natural place for timestamps and other information (such as
whether the node is packed) that we don't want to confuse with headline and
body text.
That's all for now. These new insights likely suffice to begin the
implementation of @views and @view.
As I indicated in a reply to Terry, the details of @auto-view are murky,
but I expect that the organization just presented will work just fine for
@auto-view as well as @view.
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/groups/opt_out.
