From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24138 invoked from network); 24 Jun 1998 07:17:08 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 24 Jun 1998 07:17:08 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id DAA08128; Wed, 24 Jun 1998 03:12:22 -0400 (EDT) Resent-Date: Wed, 24 Jun 1998 03:12:22 -0400 (EDT) Date: Wed, 24 Jun 1998 09:13:33 +0200 (MET DST) Message-Id: <199806240713.JAA12117@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu In-reply-to: "Bart Schaefer"'s message of Tue, 23 Jun 1998 12:04:12 -0700 Subject: Re: Compctl completion tweaking Resent-Message-ID: <"NZ-IJ.0.x-1.LRAar"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4160 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Bart Schaefer wrote: > > On Jun 23, 4:57pm, Johan Sundström wrote: > } Subject: Compctl completion tweaking > } > } (Sure, -g '*.rmp(.)' + -g '*(-/)' does a fair job, but I find it > } irritating that I cant tab my way down into a subdirectory of a > } directory containing *.rpm files this way.) > > I've been meaning to mention that I think menucompletion and listings should > evaluate -all- the alternatives in an alternative completion, not just the > first one that happens to return something non-empty. > I think including them in the listing might be confusing (something like: Hey, it shows this as a possible completion but it doesn't allow me to complete to it). With menucompetion this may make sense, though. With MENU_COMPLETE set this can (almost) obtained by avoiding to use xor'ed compctls. But with AUTO_MENU we would need some special casing in the code. And in this case it may again be confusing: you try completion, it shows you, say, two or three possible completions, so you decide to continue tabbing to start menucompletion instead of typing the charcter neede to make things unambiguous. But instead of cycling through the few matches shown it suddenly uses the other xor-cases and starts cycling through a list of, say, 20 or more completions. Certainly not what I would expect (or like). For me, the only acceptable way to solve this would be a new compctl syntax for something like: xor'ed completion, but if this is used for menucompletion (because of MENU_COMPLETE or AUTO_MENU), use the following options immediatly. If we use `++' for that we would have: compctl -g '*.rpm' ++ -g '*(-/)' ... I haven't tried to implement it, but it doesn't look too difficult. Would that be acceptable for all of you? > I realize that the current behavior permits one to avoid evaluating a very > slow completion until all previous alternatives have returned nothing, but > it's misleading to have the menu or listing omit some possible completions. > Well, the meaning of xor'ed completions is that the other completions *are not* possible completions as long as the first bunch of flags produces matches. (But I think I know what you mean, see above.) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de