Imo, the most important of yesterday's work was a new distinction
concerning links. This new distinction has important repercussions
for data management.
The "prototype" for my thinking has been Kent's remarks, made several
years ago, about wanting to "reuse" writing.
It is precisely this situation for which clones are unsuited. The
problems with clones have generated an endless stream of similar
feature requests, none of which get to the heart of the matter. Now
we can see why.
Leo's clones create **identity-based** links. Indeed, the identity of
nodes never change after they are created: the identity is the node's
gnx: global node index.
There are many situations when identity-based links are natural. When
I fix a bug, I clone nodes related to the bug and gather the cloned
nodes in a single place. The gathered nodes have no common attributes
*except* that I selected them. I want *this* node, and *this* node,
but not *that* node. So identity is *all* that matters.
But there are many other situations in which the identity of a node is
much less important than its contents. Yesterday's Aha was:
Don't *link* to nodes, *search* for nodes!
For the most part, when writing, or in this case *assembling*
documents, the identity of the nodes containing text is completely
irrelevant! All we care about is the text itself, and possibly the
**context** in which the text appears.
But in Leo, **context is another form of content.**
Aside: Could this be the true form of the Leo Aha?? It might be!
Therefore, we can imagine a script that creates @rst trees by scanning
one or more .leo files.
Do you see? This script will probably care *nothing* about identity
of nodes: but it will care a lot about headlines, body text, and
(quite possibly) outline structure. The script could even use uA's:
they are another form of content.
Aside: The c.all_unique_positions() iterator uses node identity to
remove duplicate nodes, but that's about the only way identity will
come into the picture.
So the concept of content-based link (that is a search of content)
creates:
1. a whole new class of scripts and, much more importantly,
2. **a whole new way to think about content**.
**Design content for searching**
If a script can *find* for the content, a script can reorganize and
reformat the content in any way. In particular, scripts can create
@rst trees.
Of course, scripts are not going to *produce* new content. But
document-assembling scripts should go a long way toward solving the
problems that Kent has discussed. Imo, we are close to the holy grail
of document production.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
