From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1866 invoked from network); 31 Aug 1999 21:05:32 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 Aug 1999 21:05:32 -0000 Received: (qmail 22953 invoked by alias); 31 Aug 1999 21:05:19 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7586 Received: (qmail 22945 invoked from network); 31 Aug 1999 21:05:16 -0000 From: "Bart Schaefer" Message-Id: <990831210509.ZM17261@candle.brasslantern.com> Date: Tue, 31 Aug 1999 21:05:09 +0000 In-Reply-To: <199908310815.KAA27365@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: 6-pws-2" (Aug 31, 10:15am) References: <199908310815.KAA27365@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail Lite (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: 6-pws-2 Cc: pws@ifh.de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 31, 10:15am, Sven Wischnowsky wrote: > Subject: Re: 6-pws-2 > > Peter Stephenson wrote: > > - Personally, I prefer one single completion function for a suite of > > related commands like cvs or pbm, since the accumulated clutter (and > > added time to process completion files the first time) is large. If it > > stays the way it is I will change the default for function installation > > to keep the subdirectories. > > I agree that the increase in processing time is very ugly but I don't > have a problem with the many functions. However, you won't find it > hard to convince to support any attempt to clean this up. The > increasing use of `_arguments' already made me wish to find a better > way to give descriptions to it then by writing lots of functions that > just call `_arguments'. I don't have any ideas about this yet, though. Here's a radical suggestion: Let's convert _arguments back into C code, as a module. It could work rather like getopts (which it resembles in syntax already), it would improve performance, and it would permit us to use arbitrarily complex caching schemes without worrying about nested associative array syntax at the interpreter level. We might also consider looking at any of the functions in Core and Base that are very heavily used, and turn those into C modules as well. If the interfaces were properly documented, anyone who wanted to could still override them with a shell function. After all, part of the reason for breaking completion out into this kind of function interface was to identify useful primitives. As quickly as nearly everything has been converted to using _arguments, it would seem that we've identified at least one. Here's yet another radical suggestion: Let's package the bulk of the completion system separately from the main zsh distribution, and maybe recruit a volunteer (Sven? Tanaka?) to keep track of the completion shell function patches so that Peter can concentrate on the shell proper. Peter can still handle the actual releases, but he won't for example have to hold off making a base release for serious problems like the killjb() bug just because the rest of us are busily creating completers for every program on the planet. The question then would be, what does belong in the main dist ... Core, Base, Builtins, and Commands, perhaps? A few things from User?