* PATCH: Re: Backticks and other tricks
@ 2001-03-28 9:49 Sven Wischnowsky
2001-03-28 15:20 ` Oliver Kiddle
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 2001-03-28 9:49 UTC (permalink / raw)
To: zsh-workers; +Cc: Mario Lang
[ 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Re: Backticks and other tricks
2001-03-28 9:49 PATCH: Re: Backticks and other tricks Sven Wischnowsky
@ 2001-03-28 15:20 ` Oliver Kiddle
0 siblings, 0 replies; 6+ messages in thread
From: Oliver Kiddle @ 2001-03-28 15:20 UTC (permalink / raw)
To: zsh-workers
--- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Re: Backticks and other tricks
@ 2001-03-29 8:14 Sven Wischnowsky
2001-03-29 8:47 ` Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 2001-03-29 8:14 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Re: Backticks and other tricks
2001-03-29 8:14 Sven Wischnowsky
@ 2001-03-29 8:47 ` Bart Schaefer
0 siblings, 0 replies; 6+ messages in thread
From: Bart Schaefer @ 2001-03-29 8:47 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PATCH: Re: Backticks and other tricks
@ 2001-03-29 14:09 Sven Wischnowsky
2001-03-29 16:43 ` Bart Schaefer
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 2001-03-29 14:09 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-03-29 16:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-28 9:49 PATCH: Re: Backticks and other tricks Sven Wischnowsky
2001-03-28 15:20 ` Oliver Kiddle
2001-03-29 8:14 Sven Wischnowsky
2001-03-29 8:47 ` Bart Schaefer
2001-03-29 14:09 Sven Wischnowsky
2001-03-29 16:43 ` Bart Schaefer
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).