From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29688 invoked from network); 1 Sep 1999 08:47:10 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Sep 1999 08:47:10 -0000 Received: (qmail 26722 invoked by alias); 1 Sep 1999 08:47:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7593 Received: (qmail 26715 invoked from network); 1 Sep 1999 08:47:01 -0000 Date: Wed, 1 Sep 1999 10:46:59 +0200 (MET DST) Message-Id: <199909010846.KAA32020@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Tue, 31 Aug 1999 21:05:09 +0000 Subject: Re: 6-pws-2 Bart Schaefer wrote: > 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. This sounds like a idea I can easily start to like ;-) I think I would prefer to put it all into one module, though. And we don't necessarily have to work only on the shell function level. Maybe we can find constructs that are used (or useful) in several functions and add builtins for those (or all the other things modules can do now or in the future). We could also hack something to help `compinit' do its job. > 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. Right. > 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. Since I like working with completion shell functions very much, I would even volunteer for that. But of course, I would need support from people know those commands which I know nothing or only very little of. This could also be one more step towards something I like thinking about: some sort of very light-weight package system: completion would be one package with some sub-packages and we would change/replace compinit/dump and friends with a somewhat more generalised package control system (this sounds big, but currently I'm only thinking about one function plus package-supplied init/dump/install code). > The question then would be, what does belong in the main dist ... Core, > Base, Builtins, and Commands, perhaps? A few things from User? I think it'll be hard to decide which ones from User if we don't use them all (current state, without things like `cvs' and `pbm'). Some of them probably simplified to `standard' versions (e.g. `_find') and then put special version in the package (or whatever we want to call it). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de