Re: Compctl completion tweaking

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Bart Schaefer wrote:

> ...
> 
> Part of the confusion arises because I didn't immediately understand the
> full ramifications of "alternative completion" being an xor.  Consider:
> 
>   compctl -k '(co college collie)' + -k '(command control console)' foo
> 
> If I type "foo co<C-d>" I'll see only "co college collie", but if I then
> add 'n' and C-d again I'll see "control console".  It seemed silly to me
> that the first listing didn't include all six possibilities.  But on
> further study of compctl-examples, I see that most cases of alternative
> completion there's no way to switch from one set of alternatives to the
> next simply by lengthening the prefix; they all begin with a uniqifier.
> 
> So this brought me to the observation that an inclusive-or is missing.
> Menucompletion and listings were part of the trail, but they don't have
> much to do with the destination.
> 

But all flags written directly after one another (without `+') are
or'ed inclusively. The mechanism for xor'ed completion is for the case 
when one doesn't want all of them.

Since your example above uses two `-k' flags I'm tempted to repeat
that I can see some problems when one wants to use multiple
compctl-flags with arguments or combinations of flags and control
flags.

If one writes/edits ones own compctls this shouldn't be that big a
problem since multiple strings can be combined (one way or the other), 
like this:

  - -g '*.c' and -g '*.h' becomes -g '*.c *.h' (or -g '*.(ch)', of course)
  - the same for -s
  - -k ... and -k ... becomes either -k ... or -s ... (when using
    multiple array names)
  - -K is more problematic: one would need a function that joins the
    reply arrays of the original functions

Only for control flags there is no simple solution.

Well, if you wanted to point out this ugliness/deficiency, I again
agree. But for me, xor'ed completion has nothing to do with that.

> ...
> 
> Hrm.  For myself, I'd rarely if ever want possible command flags hidden
> just because there happened to be some files in the current directory
> that didn't require them.  I use completion (and particularly automenu)
> as a memory aid; typically I already know what files are there, but I
> can't remember what flags I might want for a given command.  I might in
> some cases want to affect the *order* in which the completions were
> presented, so that I see all the files first and then the flags; the
> rigid asciibetical sorting that zsh imposes is sometimes frustrating.
> But I probably wouldn't want to hide the options entirely.

About the ordering: as someone else recently pointed out, it would be
nice to have a way to specify that not all matches should be listed
together or mixed when menucompleting.

So, we are in search of a way to specify multiple argument/control
options (or'ed inclusively) together with a way to specify the order
in which options are listed/inserted, right?

For that I would use some new compctl-syntax (like the one I proposed
in one of my previous mails, only applying always), unless enough
people say that they don't want to retain the current meaning of `+'
and nobody syas that (s)he wants to retain it. But since that would be 
a (serious) incompatibility and since it would make it impossible to
specify something like `try this fast one first and only if that
fails, try this slow one' (as you already pointed out), I really
really wouldn't like to change the current behaviour. Also trying to
do this with some shell option isn't the right solution here, I think, 
since one may want to have both.

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)
- a weight (for sorting the matches as the user wishes, see above)
- a flag saying if this is a file name or not, so that mixing `-f' or
  `-g' with other options still uses LIST_TYPES on the files
  (btw: it may be interesting to have a compctl-flag saying `whatever
  options are used here, the resulting words are file names', so that
  we can have the completion list show file types for names generated
  by function or whatever)

Ok. Now it would like to hear opinions about this inclusive-or-thingy:
should the behaviour of `+' be changed, should we do this with some
new shell option or should we use a new compctl-syntax (well, it
wouldn't be a completely new syntax, it would look like xor'ed
completion only with a different separator).

Or, of course, does someone see another nice solution for all this?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de