Re: completion grouping

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Nov 4,  2:50pm, Sven Wischnowsky wrote:
} Subject: Re: completion grouping
}
} (I'm beginning to think that maybe everyone should apply 8520 and 8533 
} even though I said otherwise in 8520 -- it's probably easier to
} build/change that than to keep different versions alive.)

Has anybody else been feeling a bit like Dr. Frankenstein lately?

I think everyone should go ahead and apply 8520 and 8533.  However:

} After having a look at the keys as listed in the compsys doc, I'm back 
} again at the idea to combine configuration definitions and tag
} definitions -- but this time the other way round. There are only very
} few config keys for which it is really completely unnecessary to let
} user define them per-command.

To rephrase to be sure I understand:  Much of what's in the compconfig AA
controls behavior that could reasonably be expected to differ depending
on the command or context for which completion is being performed.

Although I don't disagree with this assessment, perhaps it's time to take
a deep breath and look again at the usability of the whole system.  How
many users are going to expend the effort to alter their compconfig even
once, let alone multiple times?  I've certainly made few changes myself.

Didn't we originally set out to make it easier for mere mortals to create
their own completions, on the premise that writing a shell function was
easier than using compctl -x syntax?

Now instead we seem to be attempting to write all the completion functions
in advance, to cover every possible behavior, and provide configuration
keys (which are often every bit as complex as the old -x syntax) to select
among those behaviors.  We've made a huge step forward in power and maybe
expressiveness, but I'm beginning to think we've only gone sideways on
usability.  The main advantage of the new system is that it's more, well,
complete, so that an average user probably no longer needs to define any
new functions at all.

Which is not necessarily a bad thing ... but it means that putting further
effort into detailed adjustments has diminishing returns, as it's going to
be less and less likely that anyone bothers to understand it.

And wouldn't it be nice to have this all stabilize sometime soon, so PWS
can do a non-beta 3.2-or-4.0-or-whatever release?  We're now just 48 days
from the three-year anniversary of zsh-3.1.0!

I'm not trying to discourage any of the stuff that Sven has suggested; but
when answering his questions, let's try to look at it from slightly farther
away, in terms of not just what it's expressing, but how likely it is that
a non-programmer is going to be able to do anything useful with it.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com