Re: Compctl completion tweaking

Re: Compctl completion tweaking

[Bart Schaefer]

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

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Compctl completion tweaking

[Sven Wischnowsky]

Bart Schaefer wrote:

> 
> On Jul 1,  8:13am, Sven Wischnowsky wrote:
> > Subject: Re: Compctl completion tweaking
> > 
> > First, I would try to change the behaviour of -P (and -S) so that they 
> > are not inserted straight away, but instead [...], the prefixes
> > are walked through, too [....]
> 
> This sounds to me rather like the behavior of compctl -U.  Perhaps the
> use of inclusive-or should simply imply, or require pairing with, -U ?
> 

No, with -U the stuff on the command line is simply ignored. What I
described is a bahaviour that treats -P/-S sruff a bit more like the
matches. In fact, they are already treated a bit like them: if you
have a compctl with `-P foo' and type `fd<TAB>', the `f' is expanded
to `foo' and the `d' is taken as the prefix for the matches.
The importent difference is, that currently there can be only one such 
-P/-S and we can insert it immediatly. But with inclusively-ored
compctls, we have to make sure, that the right prefix/suffix is
inserted along the matches.
I would certainly not implement some connection/requirement with -U,
since that would mean that we couldn't give a prefix/suffix for the
matches we want to see (-U is the user's way to say to the completion
code: "You don't have a clue what kind of words I want to complete
here, anyway, so simply throw away the current word, and do no
matching at all, I'll give you the whole matching words.").

> > More problematic is the case where
> > we have prefixes like, say `barrr' and `bazzz'. The completion code
> > would insert the `ba' [...]
> > but without completeinword (and without automenu), the user
> > would have to type `rrr' or `zzz' which is a bit ugly.
> 
> That's no worse than what happens without a prefix when completing in
> the middle of a word that happens to match more than one result, is it?

It is very similar, but with a little difference: currently, this can
only happen with matches, but with inclusive-ors, it can also happen
with prefixes/suffixes (it simply might surprise the unaware a bit,
but if you are using all this, you are probably so deep into
compctl-hacking that you know, what you are doing anyway).

> 
> > So, does this seem to make sense?
> 
> Mostly, but as with most completion stuff it's probably necessary to see
> it in action.

Yep. I hope I find some time soon. If I don't find some time soon,
you might have to wait surprisingly long, since the semester is coming 
to its end, we have to hold some examinations, and, most importantly,
our whole institute will move to a new building starting on July, 21th 
and of course we can't be sure, when we will be able to work again
after that.

Bye
 Sven


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

Re: Compctl completion tweaking

[Bart Schaefer]

On Jul 1,  8:13am, Sven Wischnowsky wrote:
> Subject: Re: Compctl completion tweaking
> 
> First, I would try to change the behaviour of -P (and -S) so that they 
> are not inserted straight away, but instead [...], the prefixes
> are walked through, too [....]

This sounds to me rather like the behavior of compctl -U.  Perhaps the
use of inclusive-or should simply imply, or require pairing with, -U ?

> More problematic is the case where
> we have prefixes like, say `barrr' and `bazzz'. The completion code
> would insert the `ba' [...]
> but without completeinword (and without automenu), the user
> would have to type `rrr' or `zzz' which is a bit ugly.

That's no worse than what happens without a prefix when completing in
the middle of a word that happens to match more than one result, is it?

> So, does this seem to make sense?

Mostly, but as with most completion stuff it's probably necessary to see
it in action.

Re: Compctl completion tweaking

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> This brings up a general question, then.  Suppose for the moment that we
> do choose ++ to mean inclusive-or.  Suppose I have:
> 
>     compctl -x 'c[-1,-m]' -P '%' -u ++ -P '+' -f -W ~/Mail -- zmail
> 
> I.e., "user names prefixed with % or files in ~/Mail prefixed with +".  
> What does the list of completions look like before any + or % is present
> on the command line?  If there's both a file and a user named "schaefer",
> which prefix gets inserted?
> 

This is one of the things I am worrying about (and which kept me from
trying to implement it...).

First, I would try to change the behaviour of -P (and -S) so that they 
are not inserted straight away, but instead saved together with the
corresponding matches (one of the reasons to store prefixes and
suffixes with the matches). Then, if we find out that only one prefix
is used for all matches, it becomes easy. Otherwise (the case you
described above), if menucompletion or automenu is used, the prefixes
are walked through, too (note also, that storing prefixes and suffixes 
that have to be inserted into the command line with the matches
inhibits removing matches that merely have the same matching word, so
in your example we would have `schaefer' with `+' and `schaefer' with
`%' in the list of matches). If menucompletion is not used, we could
at least try to insert the unambiguous part (`schaefer'), leaving the
cursor at the place where the ambiguous part began, the user would
have to insert something to make it unambiguous, of course. In your
example where we only had one-character-prefixes, this is pretty
simple (typing either `+' or `%'). More problematic is the case where
we have prefixes like, say `barrr' and `bazzz'. The completion code
would insert the `ba', leaving the cursor after it to let the user
make it unambiuous. With completeinword set, the user could type
either `r' or `z' and then start completion to let zsh insert the
rest, but without completeinword (and without automenu), the user
would have to type `rrr' or `zzz' which is a bit ugly.

So, does this seem to make sense?

Bye
 Sven


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

Re: Compctl completion tweaking

[Bart Schaefer]

On Jun 30,  7:49am, Sven Wischnowsky wrote:
} Subject: Re: Compctl completion tweaking
}
} > } 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)
} > 
} > I'm confused.  You mean make the -W flag accept multiple directories?
} 
} Yes, sorry, little confusion in my internal hash tables...

This brings up a general question, then.  Suppose for the moment that we
do choose ++ to mean inclusive-or.  Suppose I have:

    compctl -x 'c[-1,-m]' -P '%' -u ++ -P '+' -f -W ~/Mail -- zmail

I.e., "user names prefixed with % or files in ~/Mail prefixed with +".  
What does the list of completions look like before any + or % is present
on the command line?  If there's both a file and a user named "schaefer",
which prefix gets inserted?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Compctl completion tweaking

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> I do not advocate changing the current meaning of `+'.  I don't think
> we should use a shell option.  I'm not very excited about `++' as the
> choice for inclusive-or, though; the compctl syntax is already too
> cryptic (which I suppose might be an argument for not worrying about
> making it more so, but ...).
> 
> It'd be nice to choose something that currently produces an error, so
> as not to co-opt anything from any existing working compctl.  (`++' is
> now taken as a command name.)
> 

I would like to agree, but the problem is that there are currently
only few things that produce an error with compctl and I wouldn't like 
to use an unused option character for something is behaves more like
`+' (separating option lists) than like an option.

> } 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)
> 
> I'm confused.  You mean make the -W flag accept multiple directories?
> 

Yes, sorry, little confusion in my internal hash tables...

> } - a weight (for sorting the matches as the user wishes, see above)
> 
> Hrm.  I'd rather just list the matches in the order they're specified
> in the compctl command, without re-sorting.  And similarly, don't sort
> the value of $reply.  Just one control flag to say "don't sort" would
> be sufficient, I think.
> 

Maybe I should have been more precise here. I didn't meant that the
user would have to worry about giving weights to the compctl options
(I can't even think of a compctl-syntax for that). What I meant was
that the user may say for different option lists (those separated by
inclusive-or's) that the results of this lists should be sorted
separately. Of course that could be changed to: not sorted at all, and 
especially not sorted into the whole list.
The completion code would derive the weights from this automatically.


Bye
 Sven


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

Re: Compctl completion tweaking

[Bart Schaefer]

On Jun 29, 10:40am, Sven Wischnowsky wrote:
} Subject: Re: Compctl completion tweaking
}
} Bart Schaefer wrote:
} > So this brought me to the observation that an inclusive-or is missing.
} 
} 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.

Yes, I understand.  As I suggested before, it's probably partly a doc
issue, though in this case I don't immediately have a suggestion for
improving it.

} Only for control flags there is no simple solution.

I wouldn't call it "simple" to have to repeat overlapping patterns in an
extended completion.  But I agree that only for control flags is there
really no usable solution at all.

} 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 `+'

I do not advocate changing the current meaning of `+'.  I don't think
we should use a shell option.  I'm not very excited about `++' as the
choice for inclusive-or, though; the compctl syntax is already too
cryptic (which I suppose might be an argument for not worrying about
making it more so, but ...).

It'd be nice to choose something that currently produces an error, so
as not to co-opt anything from any existing working compctl.  (`++' is
now taken as a command name.)

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

I'm confused.  You mean make the -W flag accept multiple directories?

} - a weight (for sorting the matches as the user wishes, see above)

Hrm.  I'd rather just list the matches in the order they're specified
in the compctl command, without re-sorting.  And similarly, don't sort
the value of $reply.  Just one control flag to say "don't sort" would
be sufficient, I think.

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

I've no opinion on this, as I never use LIST_TYPES.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Compctl completion tweaking

[Sven Wischnowsky]

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

Re: Compctl completion tweaking

[Bart Schaefer]

On Jun 26,  7:44am, Sven Wischnowsky wrote:
} Subject: Re: Compctl completion tweaking
}
} >   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.
} 
} Currently the only way would be to use one `-x'-pattern for all three
} of them, one for two of them, and one for the `co' alone (in this order).
} 
} So, if I understand you correctly, you really only want an an
} inclusive or and that only with menucompletion and listing? Do you
} want that to apply when automenu is used, too?

No, not quite.  The "and that only with ..." part is extraneous.  It
happens that the only time it makes very much difference is with menus
and listings, because those are the only opportunities to see the entire
list of possibilities.  But it ought to behave consistently no matter
what kind of completion is being performed, automenu or otherwise.

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.

} About the exclusively or'ed flags: my first example when I implemented
} this (which is also what made me think of it and the example mentioned 
} in the intro file) is the compctl for things like `latex'. Normally I
} want `*.tex' files, but if there are none, I want something else (say
} `-f' or whatever). But *if* there are any `*.tex' files I don't want
} the completion code to use the xor'ed flags, I don't want to see them, 
} I don't want to know about them (and thus, the completion code should
} not even bother to look at them). Maybe the experience for people
} using menucompletion is different here (I use only automenu), I would
} like to know about 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.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Compctl completion tweaking

[Sven Wischnowsky]

"Bart Schaefer" wrote:

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

Currently the only way would be to use one `-x'-pattern for all three
of them, one for two of them, and one for the `co' alone (in this order).

So, if I understand you correctly, you really only want an an
inclusive or and that only with menucompletion and listing? Do you
want that to apply when automenu is used, too?

That last one is important for me. My examples played with the
difference between normal and menucompletion behaviour when automenu
is set. More precisely: I don't want it to suddenly switch from one
type of behaviour to the other.

A simple inclusive or is (of course) achieved by putting the flags
together without any `+', but that doesn't allow us to, e.g. define
multiple `-K' options or multiple combinations of flags with some of
the control-flags. If you wanted to point out this deficiency, I have
to agree, this is quite ugly. And of course the problem to write
down or'ed `-x'-patterns you mentioned sometimes makes compctls very
big and clumsy (i.e. there should be a way to...).

About the exclusively or'ed flags: my first example when I implemented
this (which is also what made me think of it and the example mentioned 
in the intro file) is the compctl for things like `latex'. Normally I
want `*.tex' files, but if there are none, I want something else (say
`-f' or whatever). But *if* there are any `*.tex' files I don't want
the completion code to use the xor'ed flags, I don't want to see them, 
I don't want to know about them (and thus, the completion code should
not even bother to look at them). Maybe the experience for people
using menucompletion is different here (I use only automenu), I would
like to know about that.


Bye
 Sven


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

Re: Compctl completion tweaking

[Bart Schaefer]

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

Re: Compctl completion tweaking

[Andrej Borsenkow]

-----Original Message-----
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: <zsh-workers@math.gatech.edu>


>
>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 '*(-/)' ...
>

Which reminds me of the suggestion I made long long ago ... What about the
way to *reject* current list? That is, if I find current list unaceptable, I
simply say "hey, go on next alternative". I find it better than to simply
splash out all possible choices.

/andrej

Re: Compctl completion tweaking

[Sven Wischnowsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]


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

Re: Compctl completion tweaking

[Sven Wischnowsky]

johan_sundstrom@bigfoot.com wrote:

> 
> I've been trying for some time to limit completion behaviour for some
> commands in an intelligent manner. What I am trying to do is mask out
> files not matching a given pattern, keeping directories intact, or,
> better still, matching files according to some pattern and directories
> according to some other pattern. Shouldn't that be possible using
> something like -g '(*.rpm(.))|(*(-/))'? I tried for a while with some
> print -m magic, but didn't quite manage to get it to work.
> 
> (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.)
> 

The string for the `-g' option may contain multiple pattern separated
by blanks:

  compctl -g '*.rpm *(-/)' ...

I hope you meant that.

Bye
 Sven


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