PATCH: Re: Backticks and other tricks

PATCH: Re: Backticks and other tricks

[Sven Wischnowsky]

[ moved to -workers ]

I wrote:

> ...
>
>   if (( ! $+_ecasound_opts )); then
>     local filters i

Since the filters array is to be used later it should of course be
before that `if' (or stored in a global _ecasound_filters array).

And I forgot to say that the values can be retrieved with

  ${(M)filters:#<name>:*}

or
  ${filters[(R)<name>:*]}

as in:

  if [[ -n $state ]]; then
    local what=${${(M)filters:#${state}:*}#*:*:} pat
  
    pat="${${what//[^:]##}[2,-1]}"
    pat="${pat//::/*,}"
  
    if [[ $PREFIX = ${~pat}*, ]]; then
      _message 'too many parameters'
    else
      while [[ -n $pat ]] && ! compset -P $pat; do
        pat=$pat[3,-1]
        what=${what%:*:*}
      done
      _message "${${what%:*}##*:} in ${what##*:}"
    fi
  fi

(I guess something like that was what Mario was aiming at).


Anyway, what I really wanted to say (and that's why it's on -workers): 
if you try this with a `&& return 0' after the `_arguments ...' you'll 
notice that competion after, e.g. `-ef1:' yields nothing.  That's a
result of the change that removed the 300-return-value -- it has added 
the option itself and hence `_arguments' returns zero.  Ugly.  Very.

I can't think of a completely satisfying solution now.  Taking the
current option from the arrays of known options isn't good, because
then one wouldn't get offered an option `-foo' if that is already on
the line and there are other options starting with `-foo'.

So for now let's use the patch below.  It adds the options only if
there is no `->state' action to use or if we are not in the same word
after the option.


Bye
 Sven

Index: Completion/Base/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_arguments,v
retrieving revision 1.33
diff -u -r1.33 _arguments
--- Completion/Base/_arguments	2001/03/27 13:03:51	1.33
+++ Completion/Base/_arguments	2001/03/28 09:48:26
@@ -319,7 +319,8 @@
         fi
       done
 
-      if [[ -z "$matched$hasopts" ]] && _requested options &&
+      if [[ -z "$matched$hasopts" && ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
+          _requested options &&
           { ! zstyle -T ":completion:${curcontext}:options" prefix-needed ||
             [[ "$origpre" = [-+]* || -z "$aret$mesg$tried" ]] } ; then
 	local prevpre="$PREFIX" previpre="$IPREFIX"

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

Re: PATCH: Re: Backticks and other tricks

[Oliver Kiddle]

--- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: > 

> Anyway, what I really wanted to say (and that's why it's on
> -workers): 
> if you try this with a `&& return 0' after the `_arguments ...'
> you'll 
> notice that competion after, e.g. `-ef1:' yields nothing.  That's a
> result of the change that removed the 300-return-value -- it has
> added 
> the option itself and hence `_arguments' returns zero.  Ugly.  Very.

I agree that it is a pity this can't be done anymore when you have
state ->actions but I don't think it is as ugly as using
compstate[nmatches] would be. We just have to use `&& ret=0' or similar
and rely on checking of $state. The only other thing I can think of is
modifying _main_complete to use compstate[nmatches] when deciding
whether to move on to the next completer and allowing completion
functions for commands to not bother about their return code. I'm not
sure I like that though.

> So for now let's use the patch below.  It adds the options only if
> there is no `->state' action to use or if we are not in the same word
> after the option.

I don't really understand this but it sounds like you're not going to
be adding options in cases where they should be - options and states
can both add matches together.

Once we have this finalised, I will go through checking the return
codes of functions (and adding -A "-*" and -S options to _arguments)
but I don't have much time over the next two weeks.

Oliver

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

Re: PATCH: Re: Backticks and other tricks

[Bart Schaefer]

On Mar 29,  4:09pm, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} 
} > The only thing that worries me, given this explanation, is clusters of
} > single-letter options, like some of the very specialized cases in _rpm.
} 
} I've been thinking about this all day.  How is this different from the 
} situation I wanted to fix with the change?

Probably it's not different and I was needlessly concerned.  Thanks for
sharing your thought-process.

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Re: Backticks and other tricks

[Sven Wischnowsky]

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@informatik.hu-berlin.de

Re: PATCH: Re: Backticks and other tricks

[Bart Schaefer]

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

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

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: Re: Backticks and other tricks

[Sven Wischnowsky]

Oliver Kiddle wrote:

> --- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote: > 
> 
> > Anyway, what I really wanted to say (and that's why it's on
> > -workers): 
> > if you try this with a `&& return 0' after the `_arguments ...'
> > you'll 
> > notice that competion after, e.g. `-ef1:' yields nothing.  That's a
> > result of the change that removed the 300-return-value -- it has
> > added 
> > the option itself and hence `_arguments' returns zero.  Ugly.  Very.
> 
> I agree that it is a pity this can't be done anymore when you have
> state ->actions but I don't think it is as ugly as using
> compstate[nmatches] would be. We just have to use `&& ret=0' or similar
> and rely on checking of $state. The only other thing I can think of is
> modifying _main_complete to use compstate[nmatches] when deciding
> whether to move on to the next completer and allowing completion
> functions for commands to not bother about their return code. I'm not
> sure I like that though.

I'm sure I don't like it.  It would be quite sensible to write a
completer that adds something but return non-zero -- effectively
offering just some extra matches.

> > So for now let's use the patch below.  It adds the options only if
> > there is no `->state' action to use or if we are not in the same word
> > after the option.
> 
> I don't really understand this but it sounds like you're not going to
> be adding options in cases where they should be - options and states
> can both add matches together.

It not only sounds like that.  But it isn't as bad as it sounds,
actually I quite like it after thinking it over again.  The patch
makes be *not* completed only if 1) a `->state' action was executed
(i.e. prepared) *and* if 2) the matches for the `->state' have to be
completed in the same word after the option.

If the option-argument comes in its own word, options are completed.
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.  And I would guess that in
most or all occurrences of such a situation the possible completions
for the option-argument are simple enough to not require a `->state'
action in which case this should work, too.

> Once we have this finalised, I will go through checking the return
> codes of functions (and adding -A "-*" and -S options to _arguments)
> but I don't have much time over the next two weeks.

I hope the return-value behaviour of _arguments is in the final form.

Bye
 Sven

P.S.: Why does your MUA put your name into =?iso-8859-1?...?= ?

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