Re: problem with _arguments exclusion lists

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote:

> Sven Wischnowsky wrote:
> > 
> > > [[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1
> > 
> > If we do that, no options will be completed after, e.g. `pine -c' (with
> > your patch), because then the action returned zero.
> 
> You're right. I got mixed up. I still don't like that last line in
> _guard though. I think that maybe when _guard returns 0, matching
> options should still be offered so a -c3nf option could be matched and
> options would be offered after pine -c without that last line in _guard.
> The important original point was really what happens when _guard returns
> 1 and that is now right.
> 
> ...
> 
> It can't really be handled by anything else unless there is a specific
> maximum to X display numbers allowing us to add all possibilities.
> _guard is actually particularly valuable in the non-option argument case
> because before the recent changes options would not complete. The
> problem really is that the _guard patterns have to match fully, not
> partially: _vnc can be fixed by using the pattern (|:[0-9]#) which I'll
> commit later if _guard stays as it is.

Well, _guard was just an attempt at helping in what I consider the usual
completion style in most cases (i.e. what most people would expect or
like to see in most cases).  As I said, we could always add an option to
_guard to specify other behaviour (for the return value or pattern
matching or whatnot).  Feel free to add one if you like.


Bye
  Sven


-- 
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx