On 11/26/2013 4:45 AM, Edward K. Ream wrote:
And now for a cascade of new thoughts:
3. It is easy to test @shadow everywhere without changing @file to
@shadow. Just create a new switch:
@bool use_at_shadow_everywhere = True.
Very important aha!
So simple. So important.
4. @shadow presently uses an ad-hoc caching mechanism (specially named
private files in .leo_shadow directories).
But Leo already *has* a caching mechanism. Why not use it?!? This
could speed up @shadow dramatically.
Would such a scheme still allow .leo outlines and external files to
exist in a VCS or cloud-synced storage?
Err, rather, I guess I'm *really* asking for pointers to Leo's caching
mechanism. If it's the db, I'd consider this a *very* dangerous
change... in my experience, syncing the db causes Leo to crash, lock
up, or exhibit other strange behaviors. I've settled to having a
per-installation db, unsynced.
It also offers opportunities for cross-file clones. Clones now become
an intrinsic property of the "nearest" cache. In some sense, these
caches define a "scope" in which clones have a unique identity. The
fewer the caches; the wider the scope. It's a fertile idea.
In other words, it may be desirable to "promote" caches into more
general consciousness.
As mentioned above, as long as it's not the db, I'm all for this! I
could definitely use caches for something :)
Oh, another idea: allow 'hidden nodes' that would inform @shadow -- i.e.
they exist in the .leo XML source, but are hidden and un-editable by the
user -- updates to the @file/@shadow/@whatever trees would update the
hidden @shadow nodes.
In general, I think hidden nodes are needed for Leo for other purposes
-- hidden persistent data embedded in the outline, for one... state of
long-running, but interruptable database queries (for those using Leo as
a database, like your brother Speed has, I gather) for another, etc...
5. @shadow will always have trouble placing changed lines that lie
near node boundaries: such lines could go either at the end of one
node or the beginning of the next line.
**Important**: theoretically, this choice does not matter, because the
**result** (public file) will be the same regardless of this choices.
This is the insight that Bernhard Mulder probably understood, but
never mentioned before he died. I understood it only afterwards.
But if we contemplate using @shadow for *all* files, then it does
matter, in practice, whether @shadow can "guess" correctly.
The hidden nodes I mentioned above could solve these issues.
Last night I saw that I've been complacent about this. Simple rules
of thumb, or even some almost-completely-hidden signals in the code,
could allow @shadow to choose correctly.
By "almost-completely-hidden" I mean the kind of convention that
allows Leo to reconstitute whitespace properly in @doc parts. Perhaps
a trailing blank on a line could mean something. Haha. (Whispers) I
shouldn't tell anyone about this. They might start complaining about
how Leo is ruining their sources!
Even without such hidden data, @shadow could do some simple AI to
guess correctly. For example, indented text preceding a Python def
should likely be part of the previous node; text at the same
indentation level of the def should likely be part of the node
containing the def.
Summary
- Leo's sentinels are the biggest barrier to more widespread adoption
of Leo. Not documentation. Not anything else.
- @bool use_at_shadow_everywhere would allow us to test @shadow
everywhere without changing .leo files.
- @shadow could benefit by using Leo's existing caching mechanism.
- Some (relatively simple!) way must be found to allow @shadow to
guess correctly most of the time.
This last point is the key, imo. Only testing will show how much
further invention will be required.
If this will crush a user's organizer nodes, I don't think this is a
viable option... but I could be misinterpreting the intention here.
Thanks, Dave, for stimulating these thoughts.
Oh Bernhard, I'm sorry I waited so long to see the true potential of
your stroke of genius.
Edward
All in all, an exciting insight, but it *definitely* needs a lot of hard
thought.
Keep it up!
-->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/groups/opt_out.
