Nice idea!
Comments mixed in below.
On 4/25/2014 11:13 AM, Edward K. Ream wrote:
For the last several days I have been thinking about the new-@auto
project that I worked on in February while in Florida.
As always, the real problems involve sentinels: It's essential that
Leo's sentinels not be visible in projects that do not use Leo.
The fundamental problem is that operating systems do not support
additional (hidden) data in text files. (Old versions of MacOS did
support such data in the so-called "resource fork").
A new set of thoughts has now appeared. These are quite different
from the thoughts I have explored for the past 20 years.
===== The idea
We want a way of Leo users to share outline structure in a way that is
completely invisible to non-Leo users. This is *not* the same thing
as doing without sentinels! It puts the focus on "back-channel"
communication of sentinels between Leo users as follows:
0. Let's use the same terminology as with @shadow: **private** files
contain sentinels; **public** files do not.
1. Instead of writing sentinels *within* external files, Leo's
file-write logic could easily create separate **sentinel files**.
Sentinel files would contain:
- a header with data such as sha1-hash for the corresponding public
file, and a gnx-like author/timestamp field.
I might be wrong, but the sha1 hash will change when the file content
changes (that being the point of a hashing function). It might be wiser
to just hash the file name along with path information -- but that would
still break if/when directory structure changes. Also it would not be
cross-platform and prevent sharing sentinel data between users.
Perhaps the best solution would be to use the db to establish links
between files in ~/.leo/sentinels and the public files? Just add a
minibuffer command or two to deal with these links, and the scheme would
be golden (even if manual).
- a list of sentinel lines themselves. Each sentinel line would be
preceded by a relative offset of the sentinel within the corresponding
public file. Using relative offsets means that most offsets would not
change if a line were inserted/deleted from the public file.
So, like Sentinel A occurs 1 line before the line 'class Foo(Bar)'? I
assume things like that would have to guard against duplicates... Unless
I'm misunderstanding this bit.
2. Leo's file-read logic for public files would "shuffle" the
sentinels into the public file (using the relative offset of each
sentinel). After the sentinels have been restored, the read logic
would be identical to the present @file read logic.
Genius!
3. We want this scheme to be completely invisible to non-Leonine
users, so sentinel files must be kept *away* from project files, say
in the ~/.leo/sentinels directory. Call this the user's **sentinels
directory**.
The obvious way to associate sentinel files with the corresponding
public file would be with the sha1 hash. The files in the sentinels
directory would have names that are the sha1 hash of the corresponding
public file.
Same comments as above w/r/t hashing.
4. Leo users can *share outline structure* by sharing sentinels files.
At first, this sharing would have to be done "by hand" each time a
public file is committed. Later, perhaps more automatic ways of
sharing sentinels files could be created. Say by using git hooks, for
example.
5. Because sharing sentinels files may not always be automatic (and
might not ever be automatic), Leonine users will need ways of
"recovering" when a public file changes without the corresponding
sentinel files being available. This leads us to...
===== Doing without sentinels files
Suppose Alice has committed the new public file f.py, and suppose
Alice has *not* committed the corresponding sentinel file. Suppose
Bob wants to use the new version of f.py in Leo. Bob has two options:
1. Use @auto to create the outline for f.py.
2. Use the @shadow algorithm as follows. Using git (say) Bob recovers
some previous version V of f.py (without sentinels) for which Bob
*does* have a corresponding sentinel file. Bob (using Leo) recreates
the *private* copy of version V of f.py by shuffling the sentinels
into f.py. Bob then runs the @shadow algorithm on the old private
copy to create the new version of f.py *with* sentinels.
**Important**: the choice between @auto and @shadow would be a
personal preference. I've gone into detail here to show how Leo could
do the recovery for Bob automatically using the @shadow idea.
===== Pros and cons
As with all ways of doing without sentinels, this scheme has plusses
and minuses.
On the plus side:
- It is completely invisible and imposes *zero* cost on non-Leonine
users and projects. Costs accrue only to Leo users.
- When the proper sentinel file is available, Leo uses the simplest
possible algorithm to reconstruct outlines, namely shuffling sentinels
into the public file followed by running the @file read code. This
requires neither parsing (as @auto does) nor any complicated diffing
(as @shadow does). I think of the @file read code as a simple,
deterministic finite automaton.
- When the proper sentinel file is available, Leo will provide all the
advantages of @file nodes, including the conservation of gnx's and all
that implies, especially rock-solid clone links.
- It will be easy to prototype. A simple script will test the **round
trip** criterion. The script will create a sentinel file from a
*private* file and verify that shuffling the sentinels from the
sentinels file back into the corresponding *public* file results in
the original *private* file.
On the minus side:
- Most importantly, no matter how good (or how automatic) the
connection between public files and the corresponding sentinel files,
that connection can *never* be as solid as embedding sentinels in
external files. Thus, the opportunity for problems will always be
greater when using this scheme compared to using files with embedded
sentinels.
- Leo's users will be responsible for sharing sentinels files. This
will be an extra step, even if it is eventually done automatically.
- When the proper sentinel file does not exist for a public file, Leo
users will have to live with either @auto-based recovery or
@shadow-based recovery.
- There is no advantage for a lone Leonine user within a project to
use this scheme: she may as well use @shadow or @auto. Similarly, if
*all* the users of the project use Leo, they may as well just use
@file. So this scheme is only useful if a project contains two or
more Leonine programmers and one or more non-Leonine programmers.
===== Summary
- This scheme puts more emphasis on sharing data *among Leo users*
than on "magically" recreating sentinels.
- This scheme's implementation advantages (using the @file read logic)
is offset (in part) by the inconvenience of having to share and
synchronize sentinels files.
- This scheme is only useful when multiple Leonine programmers work in
a non-Leonine project. Solo Leonine programmers in a non-Leonine
project may as well use @shadow or @auto.
Your comments, please, Amigos.
Edward
--
-->Jake
--
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.
