From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21037 invoked from network); 4 Apr 2002 10:07:48 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 4 Apr 2002 10:07:48 -0000 Received: (qmail 26721 invoked by alias); 4 Apr 2002 10:07:29 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 4809 Received: (qmail 26709 invoked from network); 4 Apr 2002 10:07:29 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15532.9672.383882.876427@wischnow.berkom.de> Date: Thu, 4 Apr 2002 12:07:04 +0200 To: zsh-users@sunsite.dk Subject: Re: zsh's answer to the bash completion fm project In-Reply-To: <20020404085836.GB24184@io.com> References: <20020403110500.GA13869@io.com> <20020403122431.GD22084@picard.franken.de> <20020403145840.GB13145@io.com> <15531.6999.630742.919771@wischnow.berkom.de> <20020403155622.GA13834@io.com> <873cyce8uc.fsf@cenderis.demon.co.uk> <20020404085836.GB24184@io.com> X-Mailer: VM 6.95 under 21.5 (patch 3) "asparagus" XEmacs Lucid John Buttery wrote: > ... > > So that changes my original question to: Can/should we have a file for > compctl recipes, and then a directory containing the files for the stuff > made with the new system? About the compctl part: I'd only consider such a list of compctl-commands to be a todo-list of things that should be implemented for the new system. And that may actually be helpful. I'm not sure that there will be many such cases, though, with the new system being as comprehensive as it already is. About the function-directory: the new system uses a hierarchy of directories for classification and easier management. New functions will and should be put into it (and hence will end up in the distribution). For both parts: one of the things to look out for is opinions and suggestions for different ways completion behaves. We recently had someone who user@host completions to be inserted in one go, not with `usho'. Collecting such things would be interesting so that we get a list of things we can try to make possible in the new system. > Oh, and to the people who wrote me privately, pointing out that > compctl is strongly deprecated in favor of the new system, that it > sucks, etc etc...yes, I know this, I wasn't suggesting we advocate using > it. All I meant was that if a recipe exists for compctl and hasn't been > ported to the new system yet, we should still include it unless using > both systems at once is impossible and/or a huge resource hit. I think they can still be combined, at least they should. The overhead for compctl from a user's point of view is basically that there is another module loaded (for systems without dynamic linking it has to be linked into the zsh binary). From my point of view there is quite a bit of legacy code in the completion code that's only needed to support compctl. And I hate that, but don't see a way around it. Bye Sven -- Sven Wischnowsky wischnow@berkom.de