Big @shadow questions
Edward K. Ream
This is a complex topic. This post is a "thinking out loud" post
contemplating various approaches. All comments will be welcome.
Let's start with the best solution first. Some people would like
shorter names than @shadow, or @shadow-file or @shadow-thin. This
causes problems, including documentation problems. This morning I saw
that the best solution is to provide a way of aliasing *any* of Leo's
directives. This would be useful for translating Leo into a foreign
language, and it would provide a completely customizable way of
abbreviating directives as desired. So if names like @shadow-file or
@shadow-thin bother you, you can make up your own names...
The big question is, should private (shadow) files use @thin-like
sentinels or @file-like sentinels?
At present, the @shadow code uses file-like sentinels, which implies
that the .leo file contains a copy of all the file's data. The
advantages of this approach:
- The .leo file contains an archive of all the @shadow data.
- It is possible to associate uA's with the vnodes in the outline.
- The sentinels in the private file are simpler than @thin-like
sentinels. However, this is irrelevant because private files aren't
committed to bzr.
However, I definitely want the option of using @thin-like sentinels.
The advantages:
- The .leo file would be much smaller. For example, I could represent
the entire pypy project using @shadow files in a small .leo file.
- The shadow files are a *complete* record of all essential data.
This discussion started with a problem with reverting .leo files
containing @shadow nodes. Reverting .leo files with @file-like
sentinels for @shadow nodes is problematic: there are *three* copies
of the data to reconcile: the data in the .leo file, plus the public
and private derived files. This is at least one copy too many :-)
However, the difference between @file-like and @thin-like sentinels
probably doesn't matter too much: some additional code is needed in
either case to make revert-to-saved work properly.
So some case could be made for either @file-like or @thin-like
sentinels. My instinct is to ignore the advantages of the @file-like
sentinels and just use @thin-like sentinels. @shadow is the *eighth*
way of creating derived files, and I would really like to avoid an
almost-but-not-quite identical ninth way.
Terry would like a way of keeping cleo happy--that is, to associate
uA's with vnodes instead of tnodes. Rather than pollute @shadow with
almost-identical variants, it would be best to solve this problem in a
more general way. However, I don't know how to do that :-)
For now, I am leaning to @thin-like sentinels for @shadow files, with
*no* option to use @file-like sentinels. This will allow me to do one
version of the @shadow read code, and one version of the @shadow
revert code. It simplifies the documentation and generally is the
cleanest way. However, it does seem to require a solution to a so-far-
intractable problem of pinning uA's to vnodes in @thin trees...
Comments please.
Edward
P.S. If Leo does move to using only @thin-like sentinels, it may be
necessary to reconstitute all existing private files. While not
pleasant, this should be acceptable: @shadow hasn't been officially
released yet.
EKR
Edward K. Ream
> Terry would like a way of keeping cleo happy--that is, to associate
> uA's with vnodes instead of tnodes. Rather than pollute @shadow with
> almost-identical variants, it would be best to solve this problem in a
> more general way. However, I don't know how to do that :-)
anonymous, but that doesn't mean they can't be represented!
Furthermore, @shadow trees are *guaranteed* not to change in
structure: the private file will be unchanged even if the public file
changes.
So now is the time to solve this problem, at least for @shadow trees
and probably for @thin trees as well. It shouldn't be too difficult.
We simply represent the tree structure somehow in the @shadow node.
We can use a list of lists (representing nodes structurally) or as a
representation of positions (like 3.4.5.6). Either way represents the
vnode, so we can pin a uA to the node.
So Leo will use @thin-like sentinels for private @shadow files unless
some other objections are raised.
EKR
Edward K. Ream
safely in a matter of a few hours. I'd like to do this in the coming
week.
Edward
Kayvan A. Sylvan
> For now, I am leaning to @thin-like sentinels for @shadow files, with
> *no* option to use @file-like sentinels. This will allow me to do one
> version of the @shadow read code, and one version of the @shadow
> revert code. It simplifies the documentation and generally is the
> cleanest way. However, it does seem to require a solution to a so-far-
> intractable problem of pinning uA's to vnodes in @thin trees...
>
> Comments please.
I agree with your reasoning. I think @thin-like sentinels for shadow
files are the way to go on this one.
Best regards,
---Kayvan
Kent Tenney
>
> Recently there has been discussion about different @shadow options.
> This is a complex topic. This post is a "thinking out loud" post
> contemplating various approaches. All comments will be welcome.
>
> Let's start with the best solution first. Some people would like
> shorter names than @shadow, or @shadow-file or @shadow-thin. This
> causes problems, including documentation problems. This morning I saw
> that the best solution is to provide a way of aliasing *any* of Leo's
> directives.
Cool!
Another step in Leo's journey towards an information management platform.
Another level of configurability which allows Leo to be what the user
wants, not requiring the user to adapt Leo conventions.
> This would be useful for translating Leo into a foreign
> language, and it would provide a completely customizable way of
> abbreviating directives as desired. So if names like @shadow-file or
> @shadow-thin bother you, you can make up your own names...
>
> The big question is, should private (shadow) files use @thin-like
> sentinels or @file-like sentinels?
>
> At present, the @shadow code uses file-like sentinels, which implies
> that the .leo file contains a copy of all the file's data.
So the data is in 3 places right? .leo, primary, shadow
Hmmm.
The
> advantages of this approach:
>
> - The .leo file contains an archive of all the @shadow data.
>
> - It is possible to associate uA's with the vnodes in the outline.
>
> - The sentinels in the private file are simpler than @thin-like
> sentinels. However, this is irrelevant because private files aren't
> committed to bzr.
>
> However, I definitely want the option of using @thin-like sentinels.
> The advantages:
>
> - The .leo file would be much smaller. For example, I could represent
> the entire pypy project using @shadow files in a small .leo file.
Wow. That small Leo file, when opened on my machine, and informed
of the location of the pypy tree on my machine, would offer me structured access
to all the pypy code, interwoven with your comments, explanations, test nodes,
buttons and commands you wrote to exercise and understand pypy.
Truly amazing, a groundbreaking teaching tool.
Terry Brown
Boy, you get one day behind in Leo emails and all sorts of stuff goes
on :-)
I find the "Big @shadow questions" thread a bit surreal. Shadow solved
the uAs in @thin nodes problem - I understand the desire to use @thin
instead of @file for overhead, but it seems tragic to lose the so
recently gained solution to the uA problem.
But then this is followed by the solution to the previously intractable
uA in @thin node problem - argh! :-)
So yes, saving a @thin node's uAs in the @thin node itself sounds like
a great idea. Would you do the save for other non-uA attributes, like
expansion state, markedness, etc.?
And if you do that... then plain @thin nodes will have many of the
advantages of @shadow nodes, but not the
auto-import-public-files-changes part, I guess.
If it can all be done and made solid, seems like win-win-win.
Cheers -Terry
Edward K. Ream
But then this is followed by the solution to the previously intractable
uA in @thin node problem - argh! :-)
So yes, saving a @thin node's uAs in the @thin node itself sounds like
a great idea. Would you do the save for other non-uA attributes, like
expansion state, markedness, etc.?
Yes, I expect so. The details are too complicated to discuss off the top of my head.
And if you do that... then plain @thin nodes will have many of the
advantages of @shadow nodes, but not the auto-import-public-files-changes part, I guess.
I'm not sure I understand this remark. @thin files already can be updated based on changes made outside of Leo.
If it can all be done and made solid, seems like win-win-win.
Everything is already solid. As for uA's, they can never be guaranteed to be completely solid (because of the association between .leo files and derived files), but in normal operation everything will work just fine, and just as things have worked for years.
So the only new things are v.uA's stored in @thin or @shadow nodes. These (root) nodes are the only nodes stored in the .leo outline. As with all other uA's, these will be solid *provided* somebody doesn't do something weird like revert a derived file without reverting the .leo file. That kind of mischief will always cause problems, but that doesn't concern me...
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > And if you do that... then plain @thin nodes will have many of the
> > advantages of @shadow nodes, but not the
> > auto-import-public-files-changes part, I guess.
>
> I'm not sure I understand this remark. @thin files already can be
> updated based on changes made outside of Leo.
But only by editing a file with not for human consumption sentinels?
Actually I'm not sure what my point was - I was a bit dazed to first
have @shadow files combine the advantages of @thin (organizer nodes,
user controlled structure) and @auto nodes (external viewing /
modification, VCS friendly) *plus* a cure for uAs in @thin nodes, and
then all of a sudden uAs in @thin nodes aren't a problem any more...
Leo's improving too fast :-b :-)
Cheers -Terry