_arguments problems

_arguments problems

[Tanaka Akira]

I re-read the item of _arguments in zshcompsys(1) and found some
problems.  (and wrote BNF for a personal reference.)

Z(4):akr@serein% Src/zsh -f
serein% bindkey -e; autoload -U compinit; compinit -D; compdef _tst tst

(1)
serein% _tst () { _arguments '-o:*a:a:(a)' ':A:(A)' ':B:(B)' }
serein% tst A -o a <TAB>
->
serein% tst A -o a 
_tags:comptags:83: no tags registered
serein% tst A -o a
_tags:comptags:83: no tags registered
serein% tst A -o a

(2)
serein% _tst () { _arguments '-e:*last:::b:{compadd "${(j:,:)words}"}' }
serein% tst -e <TAB> last xxx
serein% tst -e ,last,xxx  last xxx

$words shouldn't have `xxx'.

(3)
The explanation of the example `(-foo):...' is wrong.

  ... in the  second
  example the argument described by the specification will
  not be offered if the option -foo is on  the  line. 

I think it's reverted.

(4)
serein% _tst () { _arguments '(*)-x' ':a:(a)' }
serein% tst -x <TAB>
->
serein% tst -x a 

Hm.  What's excluded by `*'?

(5)
serein% _tst () { _arguments '*-z:o:(o)' ':a:{compadd $opt_args[-z]}' }
serein% tst -z a -z b <TAB>
->
serein% tst -z a -z b b                

It should be `a:b'

(6)
serein% _tst () { _arguments '*-o:1:(1):*:rest:{compadd $curcontext}' }
serein% tst -o 1 <TAB><TAB>
serein% tst -o 1 :complete:tst:option-o-2 :complete:tst:option-o-2 

This is the behaviour which is described in zshcompsys(1).  But I
think it should be :complete:tst:option-o-rest

(7)
serein% _tst () { _arguments '*-o:1:(1):*:rest:{compadd $context}' }
serein% tst -o 1 <TAB>

It completes nothing.  context parameter is not set?
-- 
Tanaka Akira

Re: _arguments problems

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Feb 4, 10:59am, Sven Wischnowsky wrote (in 9559):
> } Subject: Re: _arguments problems
> }
> } *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...
> 
> On Feb 4,  3:18pm, Sven Wischnowsky wrote (in 9568):
> } Subject: Re: _arguments problems
> }
> } That's a completely different problem. And since the option-rest specs 
> } do that I agree that normal rest specs should do the same.
> 
> So ... should we *not* apply 9559 ?

[ It's 9560 ]

Personally, I'd prefer to not use the first hunk of 9560. But the
second one is needed in any case.

Bye
 Sven


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

Re: _arguments problems

[Bart Schaefer]

On Feb 4, 10:59am, Sven Wischnowsky wrote (in 9559):
} Subject: Re: _arguments problems
}
} *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...

On Feb 4,  3:18pm, Sven Wischnowsky wrote (in 9568):
} Subject: Re: _arguments problems
}
} That's a completely different problem. And since the option-rest specs 
} do that I agree that normal rest specs should do the same.

So ... should we *not* apply 9559 ?

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

Re: _arguments problems

[Sven Wischnowsky]

Tanaka Akira wrote:

> So, I think following behaviour is also problem.
> 
> is27e1u11% _tst () { _arguments '-a' '*::rest:(rest)' }
> is27e1u11% tst arg -<TAB>
> ->
> is27e1u11% tst arg -a
> 
> Because I think _arguments shouldn't completes options after an
> argument handled by `*::message:action'.

That's a completely different problem. And since the option-rest specs 
do that I agree that normal rest specs should do the same.

Bye
 Sven

diff -ru ../z.old/Src/Zle/computil.c Src/Zle/computil.c
--- ../z.old/Src/Zle/computil.c	Fri Feb  4 13:32:02 2000
+++ Src/Zle/computil.c	Fri Feb  4 15:12:22 2000
@@ -1039,7 +1039,7 @@
 
 	zfree(ca_laststate.oargs, ca_laststate.d->nopts * sizeof(LinkList));
     }
-    /* MArk everything as active. */
+    /* Mark everything as active. */
 
     for (ptr = d->opts; ptr; ptr = ptr->next)
 	ptr->active = 1;
@@ -1406,8 +1406,10 @@
 	    return 1;
 	}
     case 'O':
-	if (ca_laststate.opt || (ca_laststate.doff && ca_laststate.def) ||
-	    (ca_laststate.def && ca_laststate.def->type == CAA_OPT)) {
+	if ((ca_laststate.opt || (ca_laststate.doff && ca_laststate.def) ||
+	     (ca_laststate.def && ca_laststate.def->type == CAA_OPT)) &&
+	    (!ca_laststate.def || ca_laststate.def->type < CAA_RARGS ||
+	     compcurrent == 1)) {
 	    LinkList next = newlinklist();
 	    LinkList direct = newlinklist();
 	    LinkList odirect = newlinklist();

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

Re: _arguments problems

[Tanaka Akira]

In article <200002040959.KAA23014@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

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

I intended to use that for _cvs.  Since valid options are quite
different before and after non-option first argument, it is trouble
that _arguments in _tst1 and _cvs completes options over non-option
first argument.  If _arguments behaves so, _cvs completes global
options for subcommands as:

Z(2):akr@is27e1u11% cvs add -<TAB>
option
--allow-root      --help-options    -H   -a   -e   -l   -q   -t   -x 
--help            --help-synonyms   -Q   -b   -f   -m   -r   -v   -z 
--help-commands   --version         -T   -d   -k   -n   -s   -w      

Options except `-k' and `-m' are global options and they are only
valid between `cvs' and `add'.

So, I think following behaviour is also problem.

is27e1u11% _tst () { _arguments '-a' '*::rest:(rest)' }
is27e1u11% tst arg -<TAB>
->
is27e1u11% tst arg -a

Because I think _arguments shouldn't completes options after an
argument handled by `*::message:action'.
-- 
Tanaka Akira

Re: _arguments problems

[Sven Wischnowsky]

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

_arguments problems

[Tanaka Akira]

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

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