From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29146 invoked from network); 3 May 1999 08:16:33 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 3 May 1999 08:16:33 -0000 Received: (qmail 11537 invoked by alias); 3 May 1999 08:16:16 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6192 Received: (qmail 11492 invoked from network); 3 May 1999 08:15:08 -0000 Date: Mon, 3 May 1999 10:14:29 +0200 (MET DST) Message-Id: <199905030814.KAA28717@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Fri, 30 Apr 1999 11:40:57 -0700 Subject: Re: completion in vared Bart Schaefer wrote: > No, I'm mostly thinking of the compctl options that have poor mnemonics, > and particularly of -J and -V (which are begging for a bracketed-looking > syntax). Are you meaning something like: start-group, ..., end-group? In the beginning we had -[JV] set the group permanently (until the next -[JV]) which was nearer to this but then I decided against it because in more complex compctl's (or now: completion functions) you would always have to use it to make sure that you know which group you are using. And with such a pair you would have to remember to reset it. Also, to make this usable we would have to implement a kind of stack, so that the end-group resets it to the previous group again. > There is some advantage to having the options of the new commands be the > same as those of compctl, but I'm not sure if it's enough to outweigh the > opportunity to clean it up a bit. Right, we might think about this. For me, the most important advantage of the current implementation is that it can easily share all the parsing code with compctl. I might be convinced to change it, though. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de