On Sun, Jun 20, 2010 at 5:29 PM, Edward K. Ream <[email protected]> wrote:
> On a longish bike ride just now I considered many new schemes for
> gnx's, none of which have the slightest chance of working :-)  To
> state my firm conclusion first: changing the form of gnx's would be a
> very bad idea.
>
> Here are the key ideas:
>
> 1. gnx's create immutable identity.  They are required to make clones
> work reliably. Eliminating gnx's is equivalent to forbidding clones in
> Leo.  That's not going to happen: clones simplify the user experience.
>
> 2. The present form of gnx's is similar to hard links in a file
> system.  They are absolute, immutable links.  In contrast, "relative"
> gnx's, based on tables or "base indices" are an exceedingly bad
> idea.   Relative gnx's will not survive bzr merges.  Many thanks to
> Ville for pointing this out.
>
> Worse, relative gnx's are unreliable. For example, suppose we allocate
> gnx's sequentially as follows.  We put the present max index in the
> second line of .leoID.txt.  My first thought was: why didn't I think
> of this before?  It avoids bzr conflicts because the gnx will be of
> the form id.n, where both come from .leoID.txt.  In effect, .leoID.txt
> becomes a "gnx server".  My second thought was, boy, am I glad I
> didn't think of this before :-) Deleting .leoID.txt would cause chaos.
>
> BTW, not only must gnx's be absolute, the components of each gnx must
> also be absolute.  For example, we want an absolute timestamp.
>
> 3. Imo, "improving" gnx's is a fundamentally trivial problem.  Life is
> too short to be spent improving something that is already good
> enough.  I have no interest in incrementally "compacting" gnx's.  That
> code is guaranteed to be complex.  It's also likely to be dangerous.
> And no, I don't need Kent to remind me that some won't use Leo because
> they don't like gnx's.

And you probably don't need this, but being unnecessary
has never stopped me before.

:-]

In my world gnx's are in Leo files where they belong, they provide useful
metadata (timestamp) and no one need ever know they are there.

My continual whinging is regarding sentinels in _external_ files, which is also
not a problem, since we have @auto. Those interested in extended structure
will figure it out, the rest will use @auto and friends. My feeling is that
newcomers will not be interested in introducing sentinels into their files,
or worry about sharing that extended structure, but that is a moot point.

So again, no problem.

If I were to advocate for the first time Leo user, I'd suggest;

- alias @auto to @file
    the ``auto`` component only makes sense in relation to Leo's heritage of
    assuming sentinels in the external file. A newcomer doesn't know about that.
    Same with ``thin``, ``shadow``, ``nosent`` ... they all describe
the deviation from
    a standard a newcomer doesn't know about.

- clean up edge cases in @auto
  - consistent placement of newlines between code chunks
  - figure out handling of non-def code between defs

Moving a workflow to Leo's @auto is seamless and pain-free.

Newcomers can begin enjoying the benefits Leo offers with
NO commitment to the Leo way. At any point they can add access
to additional features (and sync issues) if they decide to sentinelize
their files.

It's all good.

>
> I am going to reject any scheme for compacting or otherwise altering
> gnx's.  Imo, the way forward is to cloak gnx's by putting them far to
> the right in the simplified sentinels scheme.  This keeps gnx's
> robust, while mollifying gnx-haters.
>
> 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.
>
>

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