I use cross-file clones. When I do, I consider the Leo file
authoritative, and the external files derivative. It becomes unwise
to edit such derived files outside of Leo because of the likelihood of
introducing inconsistencies. I think this suggest that when a leo
file contains cross-file clones, it should *not* incorporate changes
made to the involved files outside of Leo; and therefore the cross
file clones should be limited to @file generated files, and
unavailable in @thin. That restriction is because with @file, the
full contents of the file can be derived from the Leo file, whereas in
the latter, reconstruction from the derived file is mandatory.
Such a restriction could be adopted in multiple ways.
Simpler: @file now means that cross file clones are allowed, and
changes to files derived from @files outside of leo are ignored;
conversely, @thin now means that cross file clones are forbidden and
changes from outside leo are incorporated. A cross-file clone
encountered in an @thin file throws an exception with a hint about the
offending gnx.
More complex: @files are inspected for cross-file clones; if and only
if there are none, changes from outside of leo are incorporated. That
could be further refined so that it is only within content derived
from cross-file clones that externally introduced changes get
ignored. For @thin files, when encountering a node that is ostensibly
cross-file (because of an identical gnx), Leo automatically de-clones
the node, assigning a new gnx.
Currently, when there are cross-file nodes, the version of the node
last encountered during reads of the leo file and its derived file
wins - and that order is not well defined. I think we should move
away from that.
- Stephen
On Jan 20, 8:58 am, "Edward K. Ream" <[email protected]> wrote:
> On Wed, Jan 20, 2010 at 7:36 AM, Ville M. Vainio <[email protected]> wrote:
>
> > On Wed, Jan 20, 2010 at 2:57 PM, Edward K. Ream <[email protected]> wrote:
>
> >> 1. I am considering removing leoProjects.txt from the repository.
> >> Indeed, it is irritating to have the diffs muddied by the clones in
> >> this file.
>
> > Just change it to leoProjects.leo, or move the stuff itself to the leo file.
>
> Possible. I think the present scheme (local copies) is good enough
> for now. For sure I won't miss the redundant and confusing diffs.
>
> >> 3. I shall consider banning cross-file clones, that is, clones that
> >> appear in multiple *external* files. This would make @view nodes more
> >> urgent. This probably will happen after Leo 4.7 final.
>
> > Before outright banning (there are people who might really need the
> > feature), just produce a loud warning when they are being used.
>
> Don't worry, the ban on cross-file clones won't happen soon, and maybe
> not at all.
>
> Indeed, I am already starting to miss them :-) I've used them for
> years without too much trouble. Banning them is already starting to
> look like an over-reaction. Otoh, *something* caused last night's
> woes, and it is troubling that it happened.
>
> 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.
