From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8724 invoked from network); 30 Apr 1999 07:07:29 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 30 Apr 1999 07:07:29 -0000 Received: (qmail 6023 invoked by alias); 30 Apr 1999 07:07:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6163 Received: (qmail 6016 invoked from network); 30 Apr 1999 07:07:21 -0000 Date: Fri, 30 Apr 1999 09:07:13 +0200 (MET DST) Message-Id: <199904300707.JAA21821@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Thu, 29 Apr 1999 09:42:56 -0700 Subject: Re: completion in vared Bart Schaefer wrote: > If there are more than 32 special completion parameters, I think we've > failed in our goal to make the whole system easier to understand. I'm not so sure about that. There are eight parameters, all the rest is in compstate, not always set, etc. Sure, some of the keys in compstate are powerful enough to be called complicated, but most of them are quite simple, I think. > By the way, if we're reasonably confident that we've now identified all > the compctl-isms that it's useful to put into compadd/gen/etc., I think > we should seriously look at rewriting the option parsing for those new > commands to abandon the compctl syntax. Part of the reason for creating > the new system was because compctl was so hard to comprehend; we've made > the new system a lot more powerful, but made little progress on making > it easy to understand. So far we've mostly taken the confusing compctl > stuff, stick new command names in front of it, and wrap it in confusing > shell-script stuff. I'm always open to suggestions (I hope I made that clear enough from the beginning). But I always thought the problem with compctl was the `-x'-stuff, the `+' stuff, and things like that. This *is* removed in the new completion system (you can't even use `+' or `-x' with compgen), this reduces compgen to just the simple flags of compctl. I /think/ you are referring to an old suggestion to just give a builtin that gets the matches to be added directly (that would be compadd) and let the user generate these matches/words through shell code. The problem is that some of the things compgen can easily generate currently can not be simply generated by the user (or: not as fast and simple). This may change if we have access to more shell interna through special associative arrays or whatever. But still: would this be easier to use or understand? Again, I'd be willing to change many things if anyone gives me a good reason to do this. I wished we had more users testing all this stuff... > Yes, I'm exaggerating a little, but you can't really say the flow of > control is obvious through the current set of completion functions. Hm. Users don't have to worry about this in almost all cases. At least if they are writing completion functions for commands/contexts, and not even when writing completers, I think (which would probably count as being something for advanced users). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de