From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18431 invoked from network); 30 Jun 1998 06:08:05 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 30 Jun 1998 06:08:05 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id BAA20547; Tue, 30 Jun 1998 01:48:03 -0400 (EDT) Resent-Date: Tue, 30 Jun 1998 01:48:03 -0400 (EDT) Date: Tue, 30 Jun 1998 07:49:21 +0200 (MET DST) Message-Id: <199806300549.HAA20725@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu In-reply-to: "Bart Schaefer"'s message of Mon, 29 Jun 1998 08:48:10 -0700 Subject: Re: Compctl completion tweaking Resent-Message-ID: <"FON1X3.0.x05.Im7cr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4188 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Bart Schaefer wrote: > ... > > I do not advocate changing the current meaning of `+'. I don't think > we should use a shell option. I'm not very excited about `++' as the > choice for inclusive-or, though; the compctl syntax is already too > cryptic (which I suppose might be an argument for not worrying about > making it more so, but ...). > > It'd be nice to choose something that currently produces an error, so > as not to co-opt anything from any existing working compctl. (`++' is > now taken as a command name.) > I would like to agree, but the problem is that there are currently only few things that produce an error with compctl and I wouldn't like to use an unused option character for something is behaves more like `+' (separating option lists) than like an option. > } Btw: when implementing this, we also could cleanup the code a bit by > } storing more than just the string to insert for each match, e.g.: > } > } - some kind of prefix/suffix and the whole string > } (this would allow us to make the `-/' flag accept multiple directories) > > I'm confused. You mean make the -W flag accept multiple directories? > Yes, sorry, little confusion in my internal hash tables... > } - a weight (for sorting the matches as the user wishes, see above) > > Hrm. I'd rather just list the matches in the order they're specified > in the compctl command, without re-sorting. And similarly, don't sort > the value of $reply. Just one control flag to say "don't sort" would > be sufficient, I think. > Maybe I should have been more precise here. I didn't meant that the user would have to worry about giving weights to the compctl options (I can't even think of a compctl-syntax for that). What I meant was that the user may say for different option lists (those separated by inclusive-or's) that the results of this lists should be sorted separately. Of course that could be changed to: not sorted at all, and especially not sorted into the whole list. The completion code would derive the weights from this automatically. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de