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

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

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

Certainly not, we are far from a final version and it is mails like
this one that tells the more development-oriented of us what other
would like to have.

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

It's a shift of means, yes. Instead of a builtin you use functions.

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

There are the `def*comp' functions and defining completion functions
on-the-fly isn't that complicated (and unusual) either (at least I
though that...). We probably should merge the `def*comp' functions
into `compdef' with options for defining pattern/key completion
functions and give it an option to delete definitions, btw.

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

I had the impression that some think `compctl -x' is more complicated
than shell programming. Do not look to much at the things currently
needed, things will improve over time.

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

Not fully to the mark, but: the aliases will almost certainly
disappear in one of the next versions (at least I'm planning to remove 
them when we have the new test-syntax). Also, the global parameters
should probably be changed to `_comps' and `_patcomps', reducing the
probability of name clashes.

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

I'd like to think the other way round: use `compctl' if you like it
and it is enough for you. If yo don't like it or you have a problem
you can't (easily) solve there, use the new completion stuff. And the
Functions/Completion we currently have are *only examples*. You can
easily write a completion widget that does:

  complete() {
    case "$COMMAND" in
    foo) ...complicated stuff for comamnd foo...;;
      ... probably for other commands ...
    *) compcall;;  # use compctl elsewhere
    esac
  }

Something like this will eventually appear as an example in the
manual, I think. The examples we currently have began with my attempt
to show that everything `compctl' does can be done with the stuff I
implemented (actually, I wanted to show that already more is possible, 
`_path_files' for example).

This, btw, is also the reason why I still don't like calling
completion widgets from `compctl'. If once `compctl' isn't enough any
more, use completion widgets. Implementing a simple one is easy and
you can still use your old `compctl's with `compcall' -- no real need
to make this two-way.

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

If you mean: another builtin path parameter I'm against it. I want the 
user to be completely free in what kind of completion code he wants to 
implement and I don't even want to direct his thinking into a certain
direction by such a parameter. If you mean that `cpath' should be used 
only in shell code, I would be for it but I would want to have the
functions autoloaded -- and for this we need `fpath' (again: this
could be solved if `autoload foo=<path>' would work).

> 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

Again, I want the users to decide what kind of completion function
he'd like to use, so we can't pre-install something, especially not
with cpath which the user probably doesn't need.

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

Once we renamed `init' and `dump' to `compinit' and `compdump' (what
Peter probably will do in pws-10 -- at least we already talked about
it) and if we have only one function for defining them (`compdef'), we 
have almost reached the state you described. Putting everything into
one function isn't really needed, is it? Especially since dumping
won't be done that often (but adding a function that calls/sources
`init', `dump', and `compdef' depending on the options it gets would
be easy). But then again: this would be an improvement affecting (and
intersting for) only the the current example.

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

You mean the `-M' problem, right? I moved this into the `_match_*'
functions to make it usable for all functions doing matching. But as a 
side effect this also saves users from the shock they may get when
seeing functions like `_path_files'. We should probably add comments
in `init' pointing to the places where the user might wish to look at
(as Peter did with `dump', hm, so it was only me who forgot to do
this, oops).

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

The examples need global parameters to keep the state that has to live 
longer than the execution of the function. If we had parameter
namespaces, we could cleanly solve this (ksh has them, should we...),
and we could solve it in a way that will not collide with any
parameters used by anyone.
As to the documentation, if been thinking about this -- the question
is: where should we document it? Certainly not in the manual, since
these are only example functions like `zls'.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx