From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18507 invoked from network); 3 Apr 2002 12:10:18 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 3 Apr 2002 12:10:18 -0000 Received: (qmail 25680 invoked by alias); 3 Apr 2002 12:10:03 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 4800 Received: (qmail 25650 invoked from network); 3 Apr 2002 12:10:02 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15530.61669.379654.662512@wischnow.berkom.de> Date: Wed, 3 Apr 2002 14:09:09 +0200 To: zsh-users@sunsite.dk Subject: Re: zsh's answer to the bash completion fm project In-Reply-To: <20020403110500.GA13869@io.com> References: <20020403110500.GA13869@io.com> X-Mailer: VM 6.95 under 21.5 (patch 3) "asparagus" XEmacs Lucid 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@berkom.de