From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: _arguments problems
Date: Fri, 4 Feb 2000 10:59:39 +0100 (MET) [thread overview]
Message-ID: <200002040959.KAA23014@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Tanaka Akira's message of 04 Feb 2000 04:14:06 +0900
Tanaka Akira wrote:
> Z:akr@is27e1u11% Src/zsh -f
> is27e1u11% bindkey -e; autoload -U compinit; compinit -D; compdef _tst tst
> is27e1u11% _tst () { _arguments "1:desc1:(arg1)" }
> is27e1u11% tst <TAB>
>
> This completes nothing but it should completes `arg1'.
It would have worked in argument number 49. Ouch.
> is27e1u11% _tst () { _arguments '-a' '*::rest:_tst2' }
> is27e1u11% _tst2 () { compadd - '-b' }
> is27e1u11% tst arg -<TAB>
> -b
> -a
>
> This completes `-a' and `-b' but it shouldn't completes `-a'.
Hm. I see why you think it shouldn't and it can be achieved by
applying the first hunk below.
*But* if we do that there wouldn't be a way to get at the options in
cases like this one (ok, it works with longer options but with short
ones like these one would have to type the whole option to complete
it). I'm really not sure if this is a good idea, I could only convince
myself to build that patch because one can always set the
prefix-needed style to false for such commands.
I'd like to hear other opinions: does anyone think that this might
surprise users? Or maybe I'm worrying too much about to special a
case...
Bye
Sven
diff -ru ../z.old/Completion/Base/_arguments Completion/Base/_arguments
--- ../z.old/Completion/Base/_arguments Fri Feb 4 09:54:06 2000
+++ Completion/Base/_arguments Fri Feb 4 10:57:05 2000
@@ -260,8 +260,8 @@
if [[ -z "$matched$mesg" ]] && _requested options &&
{ ! zstyle -t ":completion:${curcontext}:options" prefix-needed ||
- [[ "$origpre" = [-+]* ||
- ( -z "$aret$mesg" && nm -eq compstate[nmatches] ) ]] } ; then
+ [[ ( "$origpre" = [-+]* || -z "$aret$mesg" ) &&
+ nm -eq compstate[nmatches] ]] } ; then
local prevpre="$PREFIX" previpre="$IPREFIX"
PREFIX="$origpre"
diff -ru ../z.old/Src/Zle/computil.c Src/Zle/computil.c
--- ../z.old/Src/Zle/computil.c Fri Feb 4 10:35:15 2000
+++ Src/Zle/computil.c Fri Feb 4 10:47:46 2000
@@ -821,7 +821,7 @@
int num = 0;
while (*p && idigit(*p))
- num = (num * 10) + ((int) *p++);
+ num = (num * 10) + (((int) *p++) - '0');
anum = num + 1;
} else
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-02-04 9:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-04 9:59 Sven Wischnowsky [this message]
2000-02-04 13:16 ` Tanaka Akira
2000-02-04 14:18 ` Sven Wischnowsky
2000-02-04 18:35 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
2000-05-10 7:42 Tanaka Akira
2000-02-07 8:54 Sven Wischnowsky
2000-02-03 19:14 Tanaka Akira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200002040959.KAA23014@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).