Re: Compctl completion tweaking

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx