Re: PATCH: Re: _arguments questions

Re: PATCH: Re: _arguments questions

[Sven Wischnowsky]

I wrote:

> Alexandre Duret-Lutz wrote:
> 
> > >>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> > 
> > ...
> > 
> >  Sven> Because of that (;-) and because it isn't quite the same (but I
> >  Sven> confess, I had the same idea...). Especially, adding this dummy
> >  Sven> element might be useful to combine with both `::' and `:::'.
> > 
> > An helper function ?
> > 
> >   _with_dummy_arg0 () {  #  I'm not good at finding names...
> >        words=(dummy $words)
> >        (( ++CURRENT ))
> >        $@
> >   }
> > 
> >   _arguments -a -b '-c:*::blah: _with_dummy_arg0 _arguments -c -d -e'
> 
> I thought about that, too. And then thought this could easily be put
> in _arguments, i.e. make it just look for a certain prefix in the
> action -- as if there were a function called. I couldn't find another
> use for this dummy-insertion-function...

This does that: if the action starts with `= ' (a equal sign and a
space), these will be removed from the action and the sub-context
(i.e. something like `-c-1') will be inserted as the new first element 
into $words.

No need to do that in _values and _alternative...

Is the syntax weird enough?

Bye
 Sven

Index: Completion/Base/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/_arguments,v
retrieving revision 1.2
diff -u -r1.2 _arguments
--- Completion/Base/_arguments	2000/04/01 20:43:43	1.2
+++ Completion/Base/_arguments	2000/04/05 12:02:19
@@ -192,6 +192,12 @@
       if [[ -n "$matched" ]] || _requested arguments; then
         _description arguments expl "$descr"
 
+        if [[ "$action" = \=\ * ]]; then
+          action="$action[3,-1]"
+          words=( "$subc" "$words[@]" )
+	  (( CURRENT++ ))
+        fi
+
         if [[ "$action" = -\>* ]]; then
           comparguments -W line opt_args
           state="${${action[3,-1]##[ 	]#}%%[ 	]#}"
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.7
diff -u -r1.7 compsys.yo
--- Doc/Zsh/compsys.yo	2000/04/05 11:07:26	1.7
+++ Doc/Zsh/compsys.yo	2000/04/05 12:02:22
@@ -2497,7 +2497,7 @@
 using tt(_tags) and if the tag is requested, the var(action) is
 executed with the given var(descr) (description). The var(action)s
 supported are those used by the tt(_arguments) function (described
-below), without the `tt(->)var(state)' form.
+below), without the `tt(->)var(state)' and `tt(=)var(...)' forms.
 
 For example, the var(action) may be a simple function call. With that
 one could do:
@@ -2793,6 +2793,23 @@
 are taken from the array parameter tt(expl) which will be set up
 before executing the var(action) and hence may be used in it (normally 
 in an expansion like `tt($expl[@])').
+
+If the var(action) starts with `tt(= )' (a equal sign followed by a
+space), tt(_arguments) will insert the contents of the var(argument)
+field of the current context as the new first element in the tt(words) 
+special array and increments the value of the tt(CURRENT) special
+parameter. In other words, it inserts a dummy element in the tt(words) 
+array and makes tt(CURRENT) still point to the word in that array
+where the cursor is. This is only really useful when used with one of
+the forms that make tt(_arguments) modify the tt(words) array to
+contain only some of the words from the line, i.e. one of the argument 
+description forms where the var(message) is preceded by two or three
+colons. For example, when the function called in the action for such
+an argument itself uses tt(_arguments), the dummy element is needed to 
+make that second call to tt(_arguments) use all words from the
+restricted range for argument parsing. Without the inserted dummy
+element, the first word in the range would be taken (by the second
+tt(_arguments)) to be the command name and hence ignored.
 
 Except for the `tt(->)var(string)' form, the var(action) will be
 executed by calling the tt(_all_labels) function to process all tag labels,

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

Re: PATCH: Re: _arguments questions

[Alexandre Duret-Lutz]

>>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

[...]

 Sven> This does that: if the action starts with `= '
[...]
 Sven> Is the syntax weird enough?

Yes :=)  Thanks.

(seeing this last line I thougt that `=)' may have been funnier,
since it would have looked `...:=)...' and there already 
exists `...:->...')

[...]

This is an use of `= ' :

Index: Completion/User/_prcs
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/User/_prcs,v
retrieving revision 1.1.1.6
diff -u -r1.1.1.6 _prcs
--- Completion/User/_prcs	2000/03/11 00:08:12	1.1.1.6
+++ Completion/User/_prcs	2000/04/05 12:51:14
@@ -136,7 +136,7 @@
       '(--new)-N[compare new files against empty files]' \
       "(-P)--exclude-project-file[don't diff the project file]" \
       "(--exclude-project-file)-P[don't diff the project file]" \
-      '--[introduce diff options]:*::diff options: _diff_options ${PRCS_DIFF_COMMAND:-diff}' \
+      '--[introduce diff options]:*::diff options:=  _diff_options ${PRCS_DIFF_COMMAND:-diff}' \
       ':project name:_prcs_projects' \
       '*:file or directory:_files'
     ;;


-- 
Alexandre Duret-Lutz

Re: PATCH: Re: _arguments questions

[Sven Wischnowsky]

Alexandre Duret-Lutz wrote:

> >>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
> ...
> 
>  Sven> Because of that (;-) and because it isn't quite the same (but I
>  Sven> confess, I had the same idea...). Especially, adding this dummy
>  Sven> element might be useful to combine with both `::' and `:::'.
> 
> An helper function ?
> 
>   _with_dummy_arg0 () {  #  I'm not good at finding names...
>        words=(dummy $words)
>        (( ++CURRENT ))
>        $@
>   }
> 
>   _arguments -a -b '-c:*::blah: _with_dummy_arg0 _arguments -c -d -e'

I thought about that, too. And then thought this could easily be put
in _arguments, i.e. make it just look for a certain prefix in the
action -- as if there were a function called. I couldn't find another
use for this dummy-insertion-function...

> Quite ugly, but looks understandable.  But taht way we can't get
> the 'parent' option (-c) for the dummy as you suggested.

We could. _arguments itself would probably use the same it puts into
$curcontext... (which in turn made me think that this wasn't so clever 
an idea anyway).

Bye
 Sven


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

Re: PATCH: Re: _arguments questions

[Sven Wischnowsky]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2636 bytes --]


Alexandre Duret-Lutz wrote:

> >>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
>  Sven> Alexandre Duret-Lutz wrote:
> 
> [...]
> 
>  >> 1) is there a simplier way to nest `_arguments' ?
> 
>  Sven> I don't see any. Sorry. Adding more syntactic sugar to the
>  Sven> _argument specs to support this doesn't seem worth it unless we put 
>  Sven> it into the <action>. Then it's quite simple (making _arguments
>  Sven> insert the dummy, probably using the option name for it).
> 
> Isn't the `*pattern::message' spec quite the same ? 
>                                                        The `*' or
>                      the  pattern  may also be separated from the
>                      message by two or  three  colons.  With  two
>                      colons  the words special array and the CUR­
>                      RENT special parameter are modified to refer
>                      only to the words after the option (with two
>                      colons) 
> 
> What we want here is that `words' and `CURRENT' refer to the
> words after the option, *including the option*.  
> Why not a four colons separator ?
> 
> _arguments -a -b '-c:*::::blah: _arguments -c -d -e'
> 
> Horrible !

Because of that (;-) and because it isn't quite the same (but I
confess, I had the same idea...). Especially, adding this dummy
element might be useful to combine with both `::' and `:::'.

>  Sven> Should we?
> 
> I would find this helpfull, since it prevent from writting intermediate
> functions (and since _argument is *the* easy way to write completion
> functions, it should better nest without requiring the user to dig the
> completion system).

Hm, yes. I guess many people won't use $words and friends directly...

> Another idea: Isn't there a way to make _arguments detect whether it has
> been nested or not ?  (I don't know, maybe when the <argument> part
> of the context is already set ?).  Of course this solve only the 
> _arguments nesting problem, not the more general "words and CURRENT 
> include the current option" behaviour.

This could be easily done by looking at $funcstack. But it would be
wrong to do that, I think, because there may be cases where one
doesn't want this dummy element and if the nested call to _arguments
inserts it automatically one has no way to circumvent it. Unless we
add a option to _aguments, but that would be more obscure than adding
it to the action of the outer _arguments. Also, only in the outer
_arguments can it be decided if we need a dummy element.

Bye
 Sven


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

Re: PATCH: Re: _arguments questions

[Alexandre Duret-Lutz]

>>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

 Sven> Alexandre Duret-Lutz wrote:

[...]

 >> _arguments -a -b '-c:*::::blah: _arguments -c -d -e'
 >> 
 >> Horrible !

 Sven> Because of that (;-) and because it isn't quite the same (but I
 Sven> confess, I had the same idea...). Especially, adding this dummy
 Sven> element might be useful to combine with both `::' and `:::'.

An helper function ?

  _with_dummy_arg0 () {  #  I'm not good at finding names...
       words=(dummy $words)
       (( ++CURRENT ))
       $@
  }

  _arguments -a -b '-c:*::blah: _with_dummy_arg0 _arguments -c -d -e'

Quite ugly, but looks understandable.  But taht way we can't get
the 'parent' option (-c) for the dummy as you suggested.

[...]

-- 
Alexandre Duret-Lutz

PATCH: Re: _arguments questions

[Sven Wischnowsky]

Alexandre Duret-Lutz wrote:

> ...
> 
> I have some troubles with nested `_arguments'...
> 
>   _foo () { 
>     _arguments -c -d -e
>   }
> 
>   _test () {
>     _arguments -a -b '-c:*::blah: _foo'
>   }
> 
> The wanted behaviour is that any arguments given after the first `-c' shall
> complete to `-c', `-d', or `-e'.  Unfortunately:
> 
>   phobos% compdef _test test
>   phobos% test -c -<TAB>
>   -a   -b
> 
> Strange. Tracing trough the code, I found that the call to `_arguments' in
> `_foo' returned 1 because `compargument -i' ensures that CURRENT > 1.

It has to do that because it has to parse a whole command line -- and
skip the command.

> Indeed, if I add a dummy option after the first `-c' it completes right :
> 
>   phobos% test -c -dummy -<TAB>
>   -c   -d   -e
> 
> Then, I can try to add this dummy word automatically :
> 
>   _bar () {
>     words=(dummy $words)
>     (( ++CURRENT ))
>     _foo
>   }
> 
>   _test () {
>     _arguments -a -b '-c:*::blah: _bar'
>   }
> 
> But the behaviour is now
> 
>   phobos% test -c -<TAB>
>   -a   -b   -c   -d   -e
> 
> with unwanted `-a' and `-b'. 

This is a bug. Result of 9621. Fixed by the patch below.

> ...
> 
> So questions are
>  1) is there a simplier way to nest `_arguments' ?

I don't see any. Sorry. Adding more syntactic sugar to the
_argument specs to support this doesn't seem worth it unless we put 
it into the <action>. Then it's quite simple (making _arguments
insert the dummy, probably using the option name for it).

Should we?


Bye
 Sven

Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.3
diff -u -r1.3 computil.c
--- Src/Zle/computil.c	2000/04/03 15:27:15	1.3
+++ Src/Zle/computil.c	2000/04/04 12:47:54
@@ -1427,7 +1427,8 @@
 	if ((ca_laststate.opt || (ca_laststate.doff && ca_laststate.def) ||
 	     (ca_laststate.def &&
 	      (ca_laststate.def->type == CAA_OPT ||
-	       ca_laststate.def->type >= CAA_RARGS))) &&
+	       (ca_laststate.def->type >= CAA_RARGS &&
+		ca_laststate.def->num < 0)))) &&
 	    (!ca_laststate.def || ca_laststate.def->type < CAA_RARGS ||
 	     (ca_laststate.def->type == CAA_RARGS ?
 	      (ca_laststate.curpos == ca_laststate.argbeg + 1) :

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

Re: PATCH: Re: _arguments questions

[Alexandre Duret-Lutz]

>>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

 Sven> Alexandre Duret-Lutz wrote:

[...]

 >> 1) is there a simplier way to nest `_arguments' ?

 Sven> I don't see any. Sorry. Adding more syntactic sugar to the
 Sven> _argument specs to support this doesn't seem worth it unless we put 
 Sven> it into the <action>. Then it's quite simple (making _arguments
 Sven> insert the dummy, probably using the option name for it).

Isn't the `*pattern::message' spec quite the same ? 
                                                       The `*' or
                     the  pattern  may also be separated from the
                     message by two or  three  colons.  With  two
                     colons  the words special array and the CUR­
                     RENT special parameter are modified to refer
                     only to the words after the option (with two
                     colons) 

What we want here is that `words' and `CURRENT' refer to the
words after the option, *including the option*.  
Why not a four colons separator ?

_arguments -a -b '-c:*::::blah: _arguments -c -d -e'

Horrible !

 Sven> Should we?

I would find this helpfull, since it prevent from writting intermediate
functions (and since _argument is *the* easy way to write completion
functions, it should better nest without requiring the user to dig the
completion system).

Another idea: Isn't there a way to make _arguments detect whether it has
been nested or not ?  (I don't know, maybe when the <argument> part
of the context is already set ?).  Of course this solve only the 
_arguments nesting problem, not the more general "words and CURRENT 
include the current option" behaviour.

[...]

-- 
Alexandre Duret-Lutz