Zsh Mailing List Archive
Messages sorted by:
Re: zsh's answer to the bash completion fm project
- X-seq: zsh-users 4800
- From: Sven Wischnowsky <wischnow@xxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: zsh's answer to the bash completion fm project
- Date: Wed, 3 Apr 2002 14:09:09 +0200
- In-reply-to: <20020403110500.GA13869@xxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20020403110500.GA13869@xxxxxx>
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
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.
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
Messages sorted by: