Re: zsh's answer to the bash completion fm project

[Sven Wischnowsky <wischnow@xxxxxxxxx>]

John Buttery wrote:

>   I was just reading freshmeat and saw the "bash programmable
> completion" project listed; does anybody have any interest in doing
> something similar for/with zsh?

Actually, we already have that in recent distributions, see below...

> ...
>   Is there perhaps already a project like this that I don't know about?
> If not, I think it would be neat to start one.  Question: if I/we were
> to start one, what's the consensus on whether compinit or zstyle should
> be used?

Both compinit and zstyle ar new -- and they do different things.
Compinit is only a function that has to be called to get the new
(sic!) completion system going.  The real work, i.e. the code to
generate matches is distributed over many (many!) autoloaded function
files that will be loaded and called on demand by the things compinit
sets up.

When the completion system grew and grew we had more and more demand
for configurability and the final solution for that (after some other
attempts) was zstyle.  Its name doesn't start with `comp' because is
can (and has been) used elsewhere, because it is a pretty general
solution for context-dependent configurability.

So, compinit and zstyle play together.  The completion functions use
the zstyle builtin to look up users' settings (preferences) and the
user calls compinit to use the completion system at all and (s)he uses
zstyle to make it behave the way (s)he likes -- as far as the
completion functions allow themselves to be configured, of course, but
that's really very far.  I suggest you read chapter six of Peter's
user friendly user's guide available from www.zsh.org to get a taste
of all the possibilities.


Bye
  Sven

P.S.: The old system use[ds] the `compctl' builtin, which is very ugly
      and not nearly as powerful and flexible as the new system.  In
      some of the interims versions we had a builtin `compgen' which
      just used the internal C-code from `compctl' and added matches
      in a way usable for the new system.  That builtin has long
      vanished, and I mention it only because it was at that time that
      Chet Ramey posted a sneak preview to bash's completion features.
      And if you have a look, you'll see that it still uses a builtin
      called `compgen' and it still looks like a mixture of our old
      `compctl' and the new `compadd' (which is the builtin behind the
      scenes, used in the completion functions of the new system).
      I don't know exactly in which shape bash's `compgen' is
      nowadays, but the last time I looked there were still some
      features missing (i.e. promised but not yet implemented) and it
      wasn't nearly as powerful as our completion code (which isn't a
      surprise, because it is much younger).
      And, of course, they'll have a lot to do to reach the state the
      functions in our completion system -- the works of many people
      on the -workers list (thanks guys!) -- and even if they
      implement as many functions as we have, they probably won't be
      as powerful and configurable, at least at the beginning.
      Plus, we have a real autoloading mechanism (does bash have one
      nowadays?) and we have these digest files that can be used to
      make the whole completion system be mmap()ed, saving memory and
      loading time. I wouldn't want to have to load/define all of our
      334 completion functions at the startup of every shell.

-- 
Sven Wischnowsky                          wischnow@xxxxxxxxx