This may have more practical significance than today's Eurekas. Or
not.
A frequently requested feature is the ability to put @ignore trees in
@<file> trees. In the past, I have always responded that this is not
possible: each external file must contain all information in the files
@<file> tree.
But this is not so. Indeed, it would be easy to do. (See below for a
possible gotcha). Let us define a new sentinel, say::
#@include <gnx>
This would tell Leo's read code to find (somewhere!) the node with the
given gnx, and insert it in the @<file> tree.
I saw this when I was, once again, wanting to put @test nodes as a
child of the node being tested. Including @test nodes is possible to
do at present, but clumsy: we must ensure that Python does not execute
the @test node when importing the module (external file) containing
it.
These problems would go away if Leo didn't write the @test node to the
external file, but instead wrote it somewhere else.
===== Making it happen
When *reading* a file, where shall Leo find the nodes given in
#@include sentinels? This question is equivalent to the question,
when *writing* a file, where shall Leo write the nodes (and their
descendants) that will generate #@include sentinels?
Suppose we define a new directive: @tag-file <tag> <tag file name>
Each tag would name a class of nodes: @ignore, @test, whatever.
We could put this directive in its own headline, or as a directive in
the root of some @<file> node. The first would cause *all* writes of
the given tag to go to the given tag file, the second would cause
writes within the @<file> tree to go to the given tag file. The
differences between "global" and "local" tag files would be minor.
===== Discussion
There is a similarity between tags and "colored" links. In fact, I
thought about tags first. Both create, in some sense, new dimensions
in outlines.
Colored links create new *link* dimensions.
Tags create new *usage* dimensions.
For example, not writing @test nodes to an outline means that the user
is free to write *any* information to @test nodes, free from any
constraints that would otherwise be imposed by writing the data to
a .py file.
Presumably, people have always wanted to put @ignore trees in @<file>
trees because they have wanted the extra *usage* dimension that the
data in @ignore trees could provide.
So rather than focusing on @ignore, it would be clearer to focus on
@my-dimension.
One typical dimension would be @documentation.
===== The synchronization problem
There is a potentially fatal problem with this scheme. Any time *any*
data is composed from multiple sources, the question arises,
what happens if the two sources get out of synch?
For example, what happens if I commit an external file, but not the
file containing the associated @test nodes? Later, when somebody else
reads the external file into Leo, at least two problems can occur:
1. The node referenced in the #@include sentinel will not be found at
all.
2. The node will be found, but will be out of date.
Leo can detect the first problem because #@include sentinels give a
gnx.
Leo could detect the second problem it the #@include sentinel
contained a time stamp.
It's not clear, however, that merely detecting the problem is enough.
This might be an example of a beautiful theory being killed by an ugly
fact. However, I'm not ready to give up on tag files just yet ;-)
===== Summary
1. "Composing" @<file> trees from multiple sources is easy, modulo the
synchronization problem. The #@include sentinel is all that is needed.
It would be straightforward to implement #@include and the associated
read/write code.
2. Separating content of @<file> trees from the content of the
external file creates a new design space, one in which nodes exist in
multiple dimensions.
3. @ignore is simply a stand-in for more specific usage dimensions,
such as @test, @doc, etc.
4. As usual, keeping data in sync poses a significant, perhaps fatal,
problem.
Your comments, please.
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.
