Zsh Mailing List Archive
Messages sorted by:
Re: Compctl completion tweaking
- X-seq: zsh-workers 4186
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: Compctl completion tweaking
- Date: Mon, 29 Jun 1998 10:40:00 +0200 (MET DST)
- In-reply-to: "Bart Schaefer"'s message of Fri, 26 Jun 1998 11:59:08 -0700
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
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),
- -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?
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: