Re: PATCH: Re: Backticks and other tricks

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On Mar 29, 10:14am, Sven Wischnowsky wrote:
> }
> } The only case where the patch would cause trouble is that there are
> } two (or more) options, one being a prefix of the other and the
> } prefixish one gets an argument that has to come directly after the
> } option.  A *very* seldom case I would say.
> 
> The only thing that worries me, given this explanation, is clusters of
> single-letter options, like some of the very specialized cases in _rpm.
> A whole lot of work went into making those cluster in just about every
> ordering that might make sense to rpm, and some of them are pretty odd;
> for example, -i means something different when it's the first option on
> the line than it does when it follows -q, so `rpm -iq...' completes
> differently from `rpm -qi...'.

I've been thinking about this all day.  How is this different from the 
situation I wanted to fix with the change?  The problem there was that 
after a ->state action for an argument in the same word as the option
was used, the option itself was added as a possible completion.

In functions like _rpm, where we have to handle multiple single-letter 
options in the same word and probably `nested' calls to _arguments the 
situation is the same.  If _arguments has found out that we are after
an option whose argument has to come exactly at the point where the
cursor is, in the same word (I seem to be repeating this a lot, but
that's the whole point), then we are in a place where no other option
can be needed anyway (from the program for which we are completing).

And if we are after a single-letter option after which options of some 
sub-command have to be completed this is exactly the same as if there
were an option with a argument (and it's written like that in
functions like _rpm).  And note that the action will still be taken
(i.e. reported to the calling function), it's just that no more
options of the upper-level call to _arguments will be completed at
that position.  And that should be logically correct, because after
the sub-command-like-option only the options for the sub-command are
to be completed which will be handled by the action.

Or maybe I'm just getting blind...

> It doesn't *appear* that anything has gone wrong with it, but there are
> so many possible combinations to try ...

Yes.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx