> > This is not the time for complex decision making!

I can live with that - I've been waiting for this for years, so I can
wait for Leo 4.8 or 5.

> > Conflicting clones are rare, and when they do happen they will be an
unwelcome surprise.

Indeed, which is why a user should be able to handle them fairly easy
in most cases (my example above is a specially complicated one to
emphasis the idea).

> I don't agree.  Once a user chooses to put clones in @files that may
> be edited externally, they take on a responsibility to address the
> potential problems that could arise.  The last thing I want is for Leo
> to guess at the appropriate resolution.  Instead, users should be able
> to compare the differences and decide if I should keep them uncloned
> or reclone them with either the old content, the new content, or a
> some combination.  I don't think a user who has already taken on the
> responsibility for managing Leo content (and the use of clones) will
> classify this as "complex decision making".

I'm with TL. I was trying to shortcut the position on clones because
unexpectedly this 4.7 thread suddenly turned into a clone discussion,
but I do think that the subject needs a serious thinking of how to
make the best out of this extremely useful concept.

Furthermore, I recently started working with @shadow (previously I was
working with @file), and the more I think about it, esp. in light of
this thread, I realized that @thin are not meant for VCS. In short the
reasoning is that in some earlier thread we agreed that Leo is a
_personal_ description/meta structure on top of the code. @file embed
this meta information in the source file itself, which can easily
conflict with another developer's point of view. Trying to force a
common meta structure seems to me even more difficult than having a
coding standard. @shadow solves this by keeping the meta information
personal and sharing only the raw code - something that Leo _must_
respect (leading to the clones problem and the responsibility of the
user - with power comes responsibility).

I certainly see the benefit of keeping my @shadow files in a personal
VCS and to ease this I might even suggest having a separate directory
tree, parallel to the source one instead of interleaved for easier VCS
trees separation, but this probably also deserve a discussion of it
own, which can wait after 4.7.

Gil

-- 
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.

Reply via email to