RE: change to __path_files and clean up of Functions/Completion needed

["Andrej Borsenkow" <borsenkow.msk@sni.de>]

> >
> > I think, it is unacceptable. It is the same, as if users had to modify C
> > sources to change compctl behaviour.
>
> I don't think so. This is shell code after all.

O.K. I hope it is not too late.

The good old completion has some nice features:

1. It works out-of-the-box. Not setup is needed; immediately after
installing zsh users can start with compctl.

2. it is easy to modify completion on-the-fly. What is important, it is the
same command with the same syntax as used in startup files. It is
invariant - 'compctl $(compctl -L cd) cd' is noop as it should be.

3. it is easy to use. It is not a joke. Using compctl amounts simply to
listing what is considered a match - no shell programming is needed. It can
be used immediately after reading manual. (Please, I know about -K. But most
cases are actually quite simple). What's more important, no shell
porgramming is needed for extended/conditional completion. All is limited to
a single command.

4. (this is of more personal nature) It does not pollute namespace (why
don't we have anonymous functions :) It does not suddenly defines
variables/functions/aliases that a completion user is not interested in at
all (and probably, should not know of as well)

I think, it is time to decide, if we want new style completion be for
wizards only or intended for general user community. If it should be of
general use, it should be at least as easy to use, as compctl. Exactly for
these reasons my first reaction was to stay with compctl as a single entry
point and use new style completion to extend it's ability.

What I suggest, is some framework that IMHO makes new completion almost as
easy to use as compctl.

1. use separate array (cpath?) for a completion stuff. Mixing it with fpath
is probably a bad idea (at least, I suddenly get a bunch of autoloaded
functions that actually dont exist :)

2. automatically install at least run-time for new completion (and probably
the completion for zsh builtins) in standard system-wide location and
initialize cpath to point to this location

3. provide a single command to make life easier (compctl is taken, sigh)
This command would need at least

  init - initialize completion. Traverse cpath loading
         definitions. This would allow users to
         override system-wide completion by adding own
         directories to cpath after system location

  load - load a (single) definition. With options to read
         from stdio, single file or a directory. And may be
         directly as argument. Great for testing :)

  dump - printout of current definition(s) for selected command(s)
         (--default-- etc). This should be directly usable as input
         to load.

4. The run-time for completion stuff should _not_ require modification. Even
more so, because these functions are very close to winners of Obfuscated Zsh
Programming Contest :-)

This command should behave as function (or be implemented as such). This
allows to start with emulate -RL zsh, set all needed options (extendedglob
problem :), define any needed local variables without fear to stomp on
user's environment. Anything, that this function exports, should 'course be
documented.

In this case, all pluses of compctl are retained. Users can start with 'xxx
init' (with additional advantage, that they immediately get standard
completions for builtins), modify a simgle completion with 'xxx load' and
look at what's going on with 'xxx dump'.

I really admire the job, Sven, Peter and others have done to improve this
stuff. Let's give it a final touch ...

regards

/andrej