Re: Compctl completion tweaking

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 24,  9:13am, Sven Wischnowsky wrote:
} Subject: Re: Compctl completion tweaking
}
} 
} Bart Schaefer wrote:
} > 
} > 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).

Maybe this is just a documentation issue:  Don't use alternatives when
they overlap.  Or maybe I don't understand the reasoning behind using an
xor in the first place; why -sometimes- hide some of the completions?

} 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).

That's why I said "... menucompletion and listings should ...".  If you're
going to menu through them all, you have to list them all, and vice-versa.

The whole concept of xor'ing completion lists is potentially confusing;
you're just pointing out different ways that confusion could surface.

} 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.

Ick, no.  I want to increase consistency in completion behavior, not add
yet another case where it's inconsistent.

} 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.

Yes; the confusion occurs when two or more of the "bunches of flags" both
would apply if only both were tried.  Even extended completion performs
an xor (it stops as soon as any pattern matches); how do you accomplish
an -inclusive- or?  Suppose I want to express this:

  If there is a word anywhere on the command line that begins with "co",
  then complete file names.  In addition, if that word begins with "cons",
  then complete directories as well.  Finally, if the word before the
  current word is the name of a directory, then also complete commands.

That is, if I have

  zsh% foo cons /tmp z

and I press C-d, I want to see a list of files, directories, and commands
whose names begin with z, all in the same list.

(Yes, I admit this is a highly contrived example.)