Re: problem with _arguments exclusion lists

Re: problem with _arguments exclusion lists

[Oliver Kiddle]

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

> > >   [[ -n "$PREFIX$SUFFIX" ]] 
> 
> In the case you described next: If the word to complete is empty I
> want
> it to both display the message and complete options.  I noticed that
> only when I had implemented (before, we were discussing only two
> cases:
> message *or* options).

But if the word is empty, and the pattern matches, it does offer both
message and options. I think this check should come before the
_message and an empty $PREFIX$SUFFIX should prevent the failed return.
Like this:
[[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1
The completion for vncserver (patch below) could use this so that it
offers display numbers before the initial `:' is typed.

When, in the first message you say `the new behaviour of completing
options if the action returns non-zero', I would have said that the
behaviour was to be not claiming to complete the message when actions
return non-zero so that completing other things, like options isn't
blocked.

> No, -w (now -W since I swapped them), makes it complete options
> regardless of the return value of the action.  What you're seeing
> here
> is the new default behaviour of trying to complete options if the
> action returns non-zero.

Oh. I thought it was going to not complete single letter options
unless it had -W and -s and always complete long options. So how do I
get _pine to work properly (use of _guard for _pine also in the
patch):

valid
pine -cr4 produces an error message

so pine -r<tab> offers other single letter options including -c pine
-c<tab> should offer -conf, -character-set etc but not other single
letter options like -r. It should also offer numbers. I thought the
_arguments -W option was going to allow it to offer single letter
options like -r for any command which allows options between an option
and its argument where they are all in the same word. So -W wouldn't be
used for pine and the -r option wouldn't be offered between -c and its
number argument.

> I was hoping for something short, but still alluding to `matching',
> in
> case we come up with other kinds of tests by which we want to
> `guard'.
> But maybe those could then be integrated into _guard and selected via
> options or something.

It can always be renamed if we think of a better name or change it's
behaviour.

Oliver

Index: Completion/Base/Utility/.distfiles
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/.distfiles,v
retrieving revision 1.1
diff -u -r1.1 .distfiles
--- Completion/Base/Utility/.distfiles	2001/04/02 12:42:44	1.1
+++ Completion/Base/Utility/.distfiles	2001/04/26 13:52:06
@@ -2,7 +2,7 @@
 .distfiles
 _alternative      _call_program     _nothing          _sub_commands
 _arg_compile      _combination      _regex_arguments  _values
-_arguments        _contexts         _retrieve_cache
+_arguments        _contexts         _retrieve_cache   _guard
 _cache_invalid    _describe         _sep_parts
 _call_function    _multi_parts      _store_cache
 '
Index: Completion/Unix/Command/_pine
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Unix/Command/_pine,v
retrieving revision 1.1
diff -u -r1.1 _pine
--- Completion/Unix/Command/_pine	2001/04/13 18:42:15	1.1
+++ Completion/Unix/Command/_pine	2001/04/26 13:52:06
@@ -31,11 +31,11 @@
   "($opts $idx -url)-attach_and_delete[go to composer, attach file, delete when finished]:file:_files" \
   "($opts $idx $send)-url[open the given URL]:url:->url" \
   "($opts $send)-f+[specify mailbox to load]:mailbox: _mailboxes" \
-  "($opts $send)-c+[specify context to apply to -f arg]:number" \
+  "($opts $send)-c+[specify context to apply to -f arg]:number:_guard '[0-9]#'" \
   "($opts $send)-sort[specify sort order of folder]:sort order:(${(j: :)sortorder})" \
   "($opts $send)-i[go directly to index, bypassing main menu]" \
   "($opts $send)-I+[specify initial keystrokes to be executed]:keystrokes" \
-  "($opts $send)-n+[entry in index to begin on]:number" \
+  "($opts $send)-n+[entry in index to begin on]:number:_guard '[0-9]#'" \
   "($opts $send)-o[open first folder read-only]" \
   "(-F -h)-r[restricted - can only send mail to oneself]" \
   "(${opts#-F})-k[force use of function keys]" \
Index: Completion/X/Command/.distfiles
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Command/.distfiles,v
retrieving revision 1.1
diff -u -r1.1 .distfiles
--- Completion/X/Command/.distfiles	2001/04/02 12:43:42	1.1
+++ Completion/X/Command/.distfiles	2001/04/26 13:52:06
@@ -1,5 +1,5 @@
 DISTFILES_SRC='
 .distfiles
 _gv        _netscape  _xauth     _xfig      _xrdb      _xterm     _xwit
-_nedit     _x_utils   _xdvi      _xmodmap   _xset      _xv
+_nedit     _vnc       _x_utils   _xdvi      _xmodmap   _xset      _xv
 '
Index: Completion/X/Command/_vnc
===================================================================
RCS file: _vnc
diff -N _vnc
--- /dev/null	Mon Dec 11 17:26:27 2000
+++ _vnc	Thu Apr 26 06:52:06 2001
@@ -0,0 +1,32 @@
+#compdef vncserver vncviewer
+
+local displays args
+displays=( ~/.vnc/$HOST:?.pid(N:r:t:s/$HOST//) )
+displays=( \\${^displays} ) 
+
+case $service in
+  vncserver)
+    # currently lacking Xvnc arguments
+    _arguments \
+      - start \
+	'-name:desktop name:_x_name' \
+	'-geometry:geometry:(1600x1200 1280x1024 1152x864 1024x768 800x600 640x480)' \
+	'-depth:pixel depth:(8 16 24 32)' \
+	'-pixelformat:pixel format' \
+	'1::display number:_guard ":[0-9]#"' \
+      - kill \
+	"-kill:display number:($displays)" \
+      - help \
+	'-help'
+  ;;
+  vncviewer) 
+    # should allow list for -encodings
+    _xt_arguments -shared -viewonly -fullscreen -bgr233 -owncmap -truecolour \
+      '-encodings:encodings:(copyrect hextile corre rre raw)' \
+      '-depth:depth' \
+      '-passwd:file:_files' \
+      '(1)-listen:display number' \
+      '(-listen)1::display:_x_display'
+  ;;
+esac
+

Re: problem with _arguments exclusion lists

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> But if the word is empty, and the pattern matches, it does offer both
> message and options. I think this check should come before the
> _message and an empty $PREFIX$SUFFIX should prevent the failed return.
> Like this:
> [[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1

If we do that, no options will be completed after, e.g. `pine -c' (with
your patch), because then the action returned zero.

> The completion for vncserver (patch below) could use this so that it
> offers display numbers before the initial `:' is typed.

I admit that I never thought about using this in a normal-argument spec
(non-option-argument).  Isn't that already covered enough by the normal
behaviour of _arguments?  I.e., using some other action for that
argument that displays the message and handles the colon (I don't know
how this argument has to look like...).

> When, in the first message you say `the new behaviour of completing
> options if the action returns non-zero', I would have said that the
> behaviour was to be not claiming to complete the message when actions
> return non-zero so that completing other things, like options isn't
> blocked.

That part of the `behaviour' depends on whatever the action does,
obviously.  And I think that the current behaviour of _guard is at least
a good default.  As I said, we can give it an option to say what should
be done (returned) if the word is the empty string.

> > No, -w (now -W since I swapped them), makes it complete options
> > regardless of the return value of the action.  What you're seeing
> > here
> > is the new default behaviour of trying to complete options if the
> > action returns non-zero.
> 
> Oh. I thought it was going to not complete single letter options
> unless it had -W and -s and always complete long options. So how do I
> get _pine to work properly (use of _guard for _pine also in the
> patch):
> 
> valid
> pine -cr4 produces an error message
> 
> so pine -r<tab> offers other single letter options including -c pine
> -c<tab> should offer -conf, -character-set etc but not other single
> letter options like -r. It should also offer numbers.

[See?  That last one... that's what you get with the current behaviour
of _guard and _arguments.]

> I thought the
> _arguments -W option was going to allow it to offer single letter
> options like -r for any command which allows options between an option
> and its argument where they are all in the same word. So -W wouldn't be
> used for pine and the -r option wouldn't be offered between -c and its
> number argument.

Ah, right.  That makes sense.  Patch below.

Bye
  Sven

Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.4
diff -u -r1.4 _arguments
--- Completion/Base/Utility/_arguments	2001/04/26 12:13:37	1.4
+++ Completion/Base/Utility/_arguments	2001/04/26 14:34:38
@@ -182,7 +182,7 @@
   -R)  rawret=yes; shift;;
   -w)  optarg=yes; shift;;
   -s)  singopt=(-s); shift;;
-  -W)  alwopt=yes; shift;;
+  -W)  alwopt=arg; shift;;
   esac
 done
 
@@ -282,7 +282,7 @@
               eval ws\=\( "${action[3,-3]}" \)
 
               _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" ||
-                  alwopt=yes
+                  alwopt=${alwopt:-yes}
 	      tried=yes
 
             elif [[ "$action" = \(*\) ]]; then
@@ -292,7 +292,7 @@
               eval ws\=\( "${action[2,-2]}" \)
 
               _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws ||
-                  alwopt=yes
+                  alwopt=${alwopt:-yes}
 	      tried=yes
             elif [[ "$action" = \{*\} ]]; then
 
@@ -301,7 +301,7 @@
               while _next_label "$subc" expl "$descr"; do
                 eval "$action[2,-2]" && ret=0
               done
-              (( ret )) && alwopt=yes
+              (( ret )) && alwopt=${alwopt:-yes}
 	      tried=yes
             elif [[ "$action" = \ * ]]; then
 
@@ -311,7 +311,7 @@
               while _next_label "$subc" expl "$descr"; do
                 "$action[@]" && ret=0
               done
-              (( ret )) && alwopt=yes
+              (( ret )) && alwopt=${alwopt:-yes}
 	      tried=yes
             else
 
@@ -321,7 +321,7 @@
               while _next_label "$subc" expl "$descr"; do
                 "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" && ret=0
 	      done
-              (( ret )) && alwopt=yes
+              (( ret )) && alwopt=${alwopt:-yes}
 	      tried=yes
             fi
           fi
@@ -340,7 +340,8 @@
 	PREFIX="$origpre"
 	IPREFIX="$origipre"
 
-        if comparguments -s single; then
+        if [[ -z "$alwopt" || -z "$tried" || "$alwopt" = arg ]] &&
+           comparguments -s single; then
 
           if [[ "$single" = direct ]]; then
             _all_labels options expl option \
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.119
diff -u -r1.119 compsys.yo
--- Doc/Zsh/compsys.yo	2001/04/26 13:03:24	1.119
+++ Doc/Zsh/compsys.yo	2001/04/26 14:34:41
@@ -2938,17 +2938,18 @@
 normally not complete the other option directly after `tt(-a)', but it would
 allow that if given the tt(-w) option.
 
-Similarly, the option tt(-W) may be given to force completion of options
-even after options that get an argument in the same word.  For example,
-if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' needs
-an argument in the same word, directly after the option character,
-tt(_arguments) would normally only execute the action for that argument
-and not offer other options as possible completions.  If given the
-tt(-W) option, it will offer other options as possible completions after
-executing the action for the argument.  Note that, depending on the
-action, this may mean that the other options can't really be completed,
-but at least they will be listed.  For more control, use an utility
-function like tt(_guard) in the argument's action.
+Similarly, the option tt(-W) may be given together with tt(-s) to force
+completion of single-letter options even after options that get an
+argument in the same word.  For example, if a command takes the options
+`tt(a)' and `tt(b)', where `tt(a)' needs an argument in the same word,
+directly after the option character, tt(_arguments) would normally only
+execute the action for that argument and not offer other single-letter
+options as possible completions.  If given the tt(-W) option, it will
+offer other options as possible completions after executing the action
+for the argument.  Note that, depending on the action, this may mean
+that the other options can't really be completed, but at least they will
+be listed.  For more control, use an utility function like tt(_guard) in
+the argument's action.
 
 The forms of var(optspec) are:
 

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

Re: problem with _arguments exclusion lists

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> > [[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1
> 
> If we do that, no options will be completed after, e.g. `pine -c' (with
> your patch), because then the action returned zero.

You're right. I got mixed up. I still don't like that last line in
_guard though. I think that maybe when _guard returns 0, matching
options should still be offered so a -c3nf option could be matched and
options would be offered after pine -c without that last line in _guard.
The important original point was really what happens when _guard returns
1 and that is now right.

Apart from the minor point above, I am now happy that this all works so
thanks Sven. Sorry for being slow about replying to this last e-mail

> I admit that I never thought about using this in a normal-argument spec
> (non-option-argument).  Isn't that already covered enough by the normal
> behaviour of _arguments?  I.e., using some other action for that
> argument that displays the message and handles the colon (I don't know
> how this argument has to look like...).

It can't really be handled by anything else unless there is a specific
maximum to X display numbers allowing us to add all possibilities.
_guard is actually particularly valuable in the non-option argument case
because before the recent changes options would not complete. The
problem really is that the _guard patterns have to match fully, not
partially: _vnc can be fixed by using the pattern (|:[0-9]#) which I'll
commit later if _guard stays as it is.

Oliver


_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: problem with _arguments exclusion lists

[Sven Wischnowsky]

Oliver Kiddle wrote:

> Sven Wischnowsky wrote:
> > 
> > > [[ -n $PREFIX$SUFFIX && "$PREFIX$SUFFIX" != $~1 ]] && return 1
> > 
> > If we do that, no options will be completed after, e.g. `pine -c' (with
> > your patch), because then the action returned zero.
> 
> You're right. I got mixed up. I still don't like that last line in
> _guard though. I think that maybe when _guard returns 0, matching
> options should still be offered so a -c3nf option could be matched and
> options would be offered after pine -c without that last line in _guard.
> The important original point was really what happens when _guard returns
> 1 and that is now right.
> 
> ...
> 
> It can't really be handled by anything else unless there is a specific
> maximum to X display numbers allowing us to add all possibilities.
> _guard is actually particularly valuable in the non-option argument case
> because before the recent changes options would not complete. The
> problem really is that the _guard patterns have to match fully, not
> partially: _vnc can be fixed by using the pattern (|:[0-9]#) which I'll
> commit later if _guard stays as it is.

Well, _guard was just an attempt at helping in what I consider the usual
completion style in most cases (i.e. what most people would expect or
like to see in most cases).  As I said, we could always add an option to
_guard to specify other behaviour (for the return value or pattern
matching or whatnot).  Feel free to add one if you like.


Bye
  Sven


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

Re: problem with _arguments exclusion lists

[Oliver Kiddle]

Sven Wischnowsky wrote:
\x1a
> > partially: _vnc can be fixed by using the pattern (|:[0-9]#) which I'll
> > commit later if _guard stays as it is.

I'll commit this now.

> 
> Well, _guard was just an attempt at helping in what I consider the usual
> completion style in most cases (i.e. what most people would expect or
> like to see in most cases).  As I said, we could always add an option to
> _guard to specify other behaviour (for the return value or pattern
> matching or whatnot).  Feel free to add one if you like.

Well it is really the _arguments handling of a 0 return code and not
_guard which I believe could be bettered. That is, it should complete
possible options (like the -c3nf example) as well as displaying
`number'.

I'm happy to require _guard patterns to need to match their thing
partially, hence the commit on the _vnc change. I agree though that
_guard's style of pattern matching can always be extended with an option
later if the need arises.

Oliver

Index: Completion/X/Command/_vnc
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Command/_vnc,v
retrieving revision 1.1
diff -u -r1.1 _vnc
--- Completion/X/Command/_vnc   2001/04/26 14:00:45     1.1
+++ Completion/X/Command/_vnc   2001/05/08 11:43:40
@@ -13,7 +13,7 @@
        '-geometry:geometry:(1600x1200 1280x1024 1152x864 1024x768 800x600 640x480)' \
        '-depth:pixel depth:(8 16 24 32)' \
        '-pixelformat:pixel format' \
-       '1::display number:_guard ":[0-9]#"' \
+       '1::display number:_guard "(|:[0-9]#)"' \
       - kill \
        "-kill:display number:($displays)" \
       - help \

Re: problem with _arguments exclusion lists

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> >   [[ -n "$PREFIX$SUFFIX" ]] 
> 
> I'm not sure about this line at the end. It is not a likely option name
> but, using the usual example, this would prevent a -c0nf option being
> completed from -c0<tab>. In what sort of case did you see it as being
> useful?

In the case you described next: If the word to complete is empty I want
it to both display the message and complete options.  I noticed that
only when I had implemented (before, we were discussing only two cases:
message *or* options).

We could make that optional by giving _guard an option, but I'd still
prefer this as the default behaviour.

> > It might be called as in:
> >   _arguments  -s '(-conf)-c+:numeric value:prop "[0-9]#"' '-conf'
> > '-f'
> 
> Testing this, I get what I thought was -w behaviour only: -c<tab>
> offers:
>   numeric value
>   option
>   -conf   -f
> I thought that it was only going to offer -f if _arguments was passed
> the -w option.

No, -w (now -W since I swapped them), makes it complete options
regardless of the return value of the action.  What you're seeing here
is the new default behaviour of trying to complete options if the
action returns non-zero.

> ...
> 
> I didn't have much in mind. The best I can think of is _guard. I'd
> prefer something short because it will be most used in the generally
> long _arguments specs so I'm not too keen on something like
> _messsage_guarded. Other ideas are _block, _pattern, _failpat.

I was hoping for something short, but still alluding to `matching', in
case we come up with other kinds of tests by which we want to `guard'.
But maybe those could then be integrated into _guard and selected via
options or something.


Bye
  Sven

Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.3
diff -u -r1.3 _arguments
--- Completion/Base/Utility/_arguments	2001/04/05 12:12:47	1.3
+++ Completion/Base/Utility/_arguments	2001/04/26 12:10:16
@@ -4,7 +4,7 @@
 # descriptions given as arguments to this function.
 
 local long cmd="$words[1]" descr mesg subopts opt usecc autod
-local oldcontext="$curcontext" hasopts rawret optarg singopt
+local oldcontext="$curcontext" hasopts rawret optarg singopt alwopt
 
 long=$argv[(I)--]
 if (( long )); then
@@ -174,21 +174,22 @@
 
 subopts=()
 singopt=()
-while [[ "$1" = -(O*|[CRWs]) ]]; do
+while [[ "$1" = -(O*|[CRWsw]) ]]; do
   case "$1" in
   -C)  usecc=yes; shift ;;
   -O)  subopts=( "${(@P)2}" ); shift 2 ;;
   -O*) subopts=( "${(@P)1[3,-1]}" ); shift ;;
   -R)  rawret=yes; shift;;
-  -W)  optarg=yes; shift;;
+  -w)  optarg=yes; shift;;
   -s)  singopt=(-s); shift;;
+  -W)  alwopt=yes; shift;;
   esac
 done
 
 zstyle -s ":completion:${curcontext}:options" auto-description autod
 
 if (( $# )) && comparguments -i "$autod" "$singopt[@]" "$@"; then
-  local action noargs aret expl local tried
+  local action noargs aret expl local tried ret=1
   local next direct odirect equal single matcher matched ws tmp1 tmp2 tmp3
   local opts subc tc prefix suffix descrs actions subcs anum
   local origpre="$PREFIX" origipre="$IPREFIX" nm="$compstate[nmatches]"
@@ -280,7 +281,8 @@
 
               eval ws\=\( "${action[3,-3]}" \)
 
-              _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]"
+              _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" ||
+                  alwopt=yes
 	      tried=yes
 
             elif [[ "$action" = \(*\) ]]; then
@@ -289,15 +291,17 @@
 
               eval ws\=\( "${action[2,-2]}" \)
 
-              _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws
+              _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws ||
+                  alwopt=yes
 	      tried=yes
             elif [[ "$action" = \{*\} ]]; then
 
               # A string in braces is evaluated.
 
               while _next_label "$subc" expl "$descr"; do
-                eval "$action[2,-2]"
+                eval "$action[2,-2]" && ret=0
               done
+              (( ret )) && alwopt=yes
 	      tried=yes
             elif [[ "$action" = \ * ]]; then
 
@@ -305,8 +309,9 @@
 
 	      eval "action=( $action )"
               while _next_label "$subc" expl "$descr"; do
-                "$action[@]"
+                "$action[@]" && ret=0
               done
+              (( ret )) && alwopt=yes
 	      tried=yes
             else
 
@@ -314,15 +319,17 @@
 
 	      eval "action=( $action )"
               while _next_label "$subc" expl "$descr"; do
-                "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}"
+                "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" && ret=0
 	      done
+              (( ret )) && alwopt=yes
 	      tried=yes
             fi
           fi
         fi
       done
-
-      if [[ -z "$matched$hasopts" && ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
+      if [[ -z "$hasopts" &&
+            ( -z "$matched" || -n "$alwopt" ) &&
+            ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
           _requested options &&
           { ! zstyle -T ":completion:${curcontext}:options" prefix-needed ||
             [[ "$origpre" = [-+]* || -z "$aret$mesg$tried" ]] } ; then
@@ -378,9 +385,10 @@
 	PREFIX="$prevpre"
 	IPREFIX="$previpre"
       fi
-      [[ -n "$tried" && "$PREFIX" != [-+]* ]] && break
+      [[ -n "$tried" && "${${alwopt:+$origpre}:-$PREFIX}" != [-+]* ]] && break
     done
-    if [[ -n "$opts" && -z "$aret$matched$mesg" &&
+    if [[ -n "$opts" && -z "$aret" &&
+          ( -z "$matched$mesg" || -n "$alwopt" ) &&
           nm -eq compstate[nmatches] ]]; then
 
       PREFIX="$origpre"
Index: Completion/Base/Utility/_guard
===================================================================
RCS file: _guard
diff -N _guard
--- /dev/null	Mon Dec 11 17:26:27 2000
+++ _guard	Thu Apr 26 05:10:16 2001
@@ -0,0 +1,17 @@
+#autoload
+
+local mesg pat garbage
+
+mesg=()
+zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:=mesg 
+
+[[ "$PREFIX$SUFFIX" != $~1 ]] && return 1
+
+if [[ $# -gt 1 || $#mesg -eq 0 ]]; then
+  shift
+  _message "$*"
+else
+  _message -r "$mesg[2]"
+fi
+
+[[ -n "$PREFIX$SUFFIX" ]]
Index: Completion/X/Utility/_x_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_x_arguments,v
retrieving revision 1.2
diff -u -r1.2 _x_arguments
--- Completion/X/Utility/_x_arguments	2001/04/04 11:29:22	1.2
+++ Completion/X/Utility/_x_arguments	2001/04/26 12:10:16
@@ -17,7 +17,7 @@
 fi
 
 opts=()
-while [[ $1 = -(O*|[CRWs]) ]]; do
+while [[ $1 = -(O*|[CRWsw]) ]]; do
   opts=($opts $1)
   [[ $1 = -R ]] && rawret=yes
   shift
Index: Completion/X/Utility/_xt_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_xt_arguments,v
retrieving revision 1.2
diff -u -r1.2 _xt_arguments
--- Completion/X/Utility/_xt_arguments	2001/04/04 11:29:22	1.2
+++ Completion/X/Utility/_xt_arguments	2001/04/26 12:10:16
@@ -53,7 +53,7 @@
 fi
 
 opts=()
-while [[ $1 = -(O*|[CRWs]) ]]; do
+while [[ $1 = -(O*|[CRWsw]) ]]; do
   opts=($opts $1)
   [[ $1 = -R ]] && rawret=yes
   shift
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.117
diff -u -r1.117 compsys.yo
--- Doc/Zsh/compsys.yo	2001/04/04 11:29:22	1.117
+++ Doc/Zsh/compsys.yo	2001/04/26 12:10:21
@@ -2930,13 +2930,25 @@
 one option name.  This allows the use of the `tt(-s)' option to describe
 single-letter options together with such long option names.
 
-The tt(-s) option may be combined with the option tt(-W) to say that more
+The tt(-s) option may be combined with the option tt(-w) to say that more
 option characters are to be expected even after an option that takes an
 argument.  For example, if a command takes the options `tt(a)' and `tt(b)',
 where `tt(a)' takes an argument in the next word, tt(_arguments) would
 normally not complete the other option directly after `tt(-a)', but it would
-allow that if given the tt(-W) option.
+allow that if given the tt(-w) option.
 
+Similarly, the option tt(-W) may be given to force completion of options
+even after options that get an argument in the same word.  For example,
+if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' needs
+an argument in the same word, directly after the option character,
+tt(_arguments) would normally only execute the action for that argument
+and not offer other options as possible completions.  If given the
+tt(-W) option, it will offer other options as possible completions after
+executing the action for the argument.  Note that, depending on the
+action, this may mean that the other options can't really be completed,
+but at least they will be listed.  For more control, use an utility
+function like tt(_guard) in the argument's action.
+
 The forms of var(optspec) are:
 
 startitem()
@@ -3498,6 +3510,38 @@
 from the called function is stored in it.
 The return value of tt(_call_function) itself is zero if the function
 var(name) exists and was called and non-zero otherwise.
+)
+findex(_guard)
+item(tt(_guard) [ var(options) ] var(pattern) [ var(descr) ])(
+This function is intended to be used in an action of functions like
+tt(_arguments).  It returns immediately with a non-zero return value if
+the string to be completed does not match the var(pattern).  If the
+pattern matches, the var(descr) is displayed and the function returns
+zero if the word to complete is not empty and non-zero otherwise.
+
+The var(pattern) may be preceded by those options understood by
+tt(compadd) that are passed down from tt(_description), namely tt(-M),
+tt(-J), tt(-V), tt(-1), tt(-2), tt(-n), tt(-F) and tt(-X).  All of these
+options, except tt(-X), will be ignored.  If the tt(-X) option appears,
+the description following it will be used as the string to display if
+the var(pattern) matches, unless the option var(descr) is given to
+tt(_guard) itself, which will then take precedence.
+
+As an example, consider a command taking the options tt(-n) and
+tt(-none), where tt(-n) has to be followed by a numeric value in the
+same word.  By using either of:
+
+example(_argument '-n-:numeric value:_guard "[0-9]#"' '-none')
+
+or
+
+example(_argument '-n-: :_guard "[0-9]#" "numeric value"' '-none')
+
+tt(_arguments) can be made to both display the message `tt(numeric
+value)' and complete options after `tt(-n<TAB>)'.  If the `tt(-n)' is
+already followed by one or more digits (matching the pattern given to
+tt(_guard)), only the message will be displayed and if the `tt(-n)' is
+followed by another character, only options are completed.
 )
 findex(_message)
 item(tt(_message) [ -r ] var(descr))(
Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.49
diff -u -r1.49 computil.c
--- Src/Zle/computil.c	2001/04/25 09:05:12	1.49
+++ Src/Zle/computil.c	2001/04/26 12:10:27
@@ -1941,7 +1941,12 @@
     case 's':
 	for (; lstate; lstate = lstate->snext)
 	    if (lstate->d->single && lstate->singles &&
-		lstate->actopts && lstate->opt) {
+		lstate->actopts
+#if 0
+                /* let's try without, for the -W option of _arguments */
+                && lstate->opt
+#endif
+                ) {
 		setsparam(args[1],
 			  ztrdup((lstate->ddef && lstate->dopt) ?
 				 (lstate->dopt->type == CAO_DIRECT ?

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

Re: problem with _arguments exclusion lists

[Oliver Kiddle]

--- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote:
> Ok, here's my suggestion.  The option's name is `-w', dunno if we
> should
> exchange the meaning of -W and -w (-w is the stronger one, so to
> say).

Yes, we probably should swap them.

> Then I suggest to use the following as the pattern-match utility

Looks good. I thought the description might be more complicated than
just using -X.

>   [[ -n "$PREFIX$SUFFIX" ]] 

I'm not sure about this line at the end. It is not a likely option name
but, using the usual example, this would prevent a -c0nf option being
completed from -c0<tab>. In what sort of case did you see it as being
useful?

> It might be called as in:
>   _arguments  -s '(-conf)-c+:numeric value:prop "[0-9]#"' '-conf'
> '-f'

Testing this, I get what I thought was -w behaviour only: -c<tab>
offers:
  numeric value
  option
  -conf   -f
I thought that it was only going to offer -f if _arguments was passed
the -w option.

> That feels quite satisfying.

It's great. Thanks Sven.

> So, if anyway can tell me a good name for that utility function, I'm
> going to commit it.  I really don't have the faintest idea.  Oliver?

I didn't have much in mind. The best I can think of is _guard. I'd
prefer something short because it will be most used in the generally
long _arguments specs so I'm not too keen on something like
_messsage_guarded. Other ideas are _block, _pattern, _failpat.

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: problem with _arguments exclusion lists

[Sven Wischnowsky]

I only just noticed that the mail I sent for this yesterday never made
it to the list (or at least: back to me).  Apologies if you get this
twice.


This adds the `-w' option to _arguments, a stronger form of -W, that
makes it complete options even directly after options that get arguments
in the same word.

It also makes _arguments try to complete options in such places even
without the -w option if the action for the argument returns a non-zero
value.

Then I suggest using the following as the pattern-matching function were
discussed:

  local mesg pat garbage

  mesg=()
  zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:=mesg 

  [[ "$PREFIX$SUFFIX" != $~1 ]] && return 1

  if [[ $# -gt 1 || $#mesg -eq 0 ]]; then
    shift
    _message "$*"
  else
    _message -r "$mesg[2]"
  fi

  [[ -n "$PREFIX$SUFFIX" ]] 

It ignores the compadd-options that might be passed down from
_description and the like, but is able to extract the description from
the -X option.  The message to display can also be given as the
second-to-last argument.  The first argument (after any compadd-options)
is the pattern to match.

So, this can be used as in:

  _arguments  -s '(-conf)-c+:numeric value:prop "[0-9]#"' '-conf' '-f'

or:

  _arguments  -s '(-conf)-c+: :prop "[0-9]#" numeric value' '-conf' '-f'

and completes options (and displays the message) directly after `-c<TAB>',
it only displays the message after `-c<digits><TAB>' and it only
completes options after `-c<non-digits><TAB>'.

This isn't committed yet, because I don't know how to call that utility
function.  Can someone please help me there?  Oliver?


Bye
  Sven

Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.3
diff -u -r1.3 _arguments
--- Completion/Base/Utility/_arguments	2001/04/05 12:12:47	1.3
+++ Completion/Base/Utility/_arguments	2001/04/25 07:03:13
@@ -4,7 +4,7 @@
 # descriptions given as arguments to this function.
 
 local long cmd="$words[1]" descr mesg subopts opt usecc autod
-local oldcontext="$curcontext" hasopts rawret optarg singopt
+local oldcontext="$curcontext" hasopts rawret optarg singopt alwopt
 
 long=$argv[(I)--]
 if (( long )); then
@@ -174,7 +174,7 @@
 
 subopts=()
 singopt=()
-while [[ "$1" = -(O*|[CRWs]) ]]; do
+while [[ "$1" = -(O*|[CRWsw]) ]]; do
   case "$1" in
   -C)  usecc=yes; shift ;;
   -O)  subopts=( "${(@P)2}" ); shift 2 ;;
@@ -182,13 +182,14 @@
   -R)  rawret=yes; shift;;
   -W)  optarg=yes; shift;;
   -s)  singopt=(-s); shift;;
+  -w)  alwopt=yes; shift;;
   esac
 done
 
 zstyle -s ":completion:${curcontext}:options" auto-description autod
 
 if (( $# )) && comparguments -i "$autod" "$singopt[@]" "$@"; then
-  local action noargs aret expl local tried
+  local action noargs aret expl local tried ret=1
   local next direct odirect equal single matcher matched ws tmp1 tmp2 tmp3
   local opts subc tc prefix suffix descrs actions subcs anum
   local origpre="$PREFIX" origipre="$IPREFIX" nm="$compstate[nmatches]"
@@ -280,7 +281,8 @@
 
               eval ws\=\( "${action[3,-3]}" \)
 
-              _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]"
+              _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" ||
+                  alwopt=yes
 	      tried=yes
 
             elif [[ "$action" = \(*\) ]]; then
@@ -289,15 +291,17 @@
 
               eval ws\=\( "${action[2,-2]}" \)
 
-              _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws
+              _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws ||
+                  alwopt=yes
 	      tried=yes
             elif [[ "$action" = \{*\} ]]; then
 
               # A string in braces is evaluated.
 
               while _next_label "$subc" expl "$descr"; do
-                eval "$action[2,-2]"
+                eval "$action[2,-2]" && ret=0
               done
+              (( ret )) && alwopt=yes
 	      tried=yes
             elif [[ "$action" = \ * ]]; then
 
@@ -305,8 +309,9 @@
 
 	      eval "action=( $action )"
               while _next_label "$subc" expl "$descr"; do
-                "$action[@]"
+                "$action[@]" && ret=0
               done
+              (( ret )) && alwopt=yes
 	      tried=yes
             else
 
@@ -314,15 +319,17 @@
 
 	      eval "action=( $action )"
               while _next_label "$subc" expl "$descr"; do
-                "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}"
+                "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" && ret=0
 	      done
+              (( ret )) && alwopt=yes
 	      tried=yes
             fi
           fi
         fi
       done
-
-      if [[ -z "$matched$hasopts" && ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
+      if [[ -z "$hasopts" &&
+            ( -z "$matched" || -n "$alwopt" ) &&
+            ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
           _requested options &&
           { ! zstyle -T ":completion:${curcontext}:options" prefix-needed ||
             [[ "$origpre" = [-+]* || -z "$aret$mesg$tried" ]] } ; then
@@ -378,9 +385,10 @@
 	PREFIX="$prevpre"
 	IPREFIX="$previpre"
       fi
-      [[ -n "$tried" && "$PREFIX" != [-+]* ]] && break
+      [[ -n "$tried" && "${${alwopt:+$origpre}:-$PREFIX}" != [-+]* ]] && break
     done
-    if [[ -n "$opts" && -z "$aret$matched$mesg" &&
+    if [[ -n "$opts" && -z "$aret" &&
+          ( -z "$matched$mesg" || -n "$alwopt" ) &&
           nm -eq compstate[nmatches] ]]; then
 
       PREFIX="$origpre"
Index: Completion/X/Utility/_x_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_x_arguments,v
retrieving revision 1.2
diff -u -r1.2 _x_arguments
--- Completion/X/Utility/_x_arguments	2001/04/04 11:29:22	1.2
+++ Completion/X/Utility/_x_arguments	2001/04/25 07:03:14
@@ -17,7 +17,7 @@
 fi
 
 opts=()
-while [[ $1 = -(O*|[CRWs]) ]]; do
+while [[ $1 = -(O*|[CRWsw]) ]]; do
   opts=($opts $1)
   [[ $1 = -R ]] && rawret=yes
   shift
Index: Completion/X/Utility/_xt_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_xt_arguments,v
retrieving revision 1.2
diff -u -r1.2 _xt_arguments
--- Completion/X/Utility/_xt_arguments	2001/04/04 11:29:22	1.2
+++ Completion/X/Utility/_xt_arguments	2001/04/25 07:03:14
@@ -53,7 +53,7 @@
 fi
 
 opts=()
-while [[ $1 = -(O*|[CRWs]) ]]; do
+while [[ $1 = -(O*|[CRWsw]) ]]; do
   opts=($opts $1)
   [[ $1 = -R ]] && rawret=yes
   shift
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.117
diff -u -r1.117 compsys.yo
--- Doc/Zsh/compsys.yo	2001/04/04 11:29:22	1.117
+++ Doc/Zsh/compsys.yo	2001/04/25 07:03:16
@@ -2937,6 +2937,18 @@
 normally not complete the other option directly after `tt(-a)', but it would
 allow that if given the tt(-W) option.
 
+Similarly, the option tt(-w) may be given to force completion of options
+even after options that get an argument in the same word.  For example,
+if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' needs
+an argument in the same word, directly after the option character,
+tt(_arguments) would normally only execute the action for that argument
+and not offer other options as possible completions.  If given the
+tt(-w) option, it will offer other options as possible completions after
+executing the action for the argument.  Note that, depending on the
+action, this may mean that the other options can't really be completed,
+but at least they will be listed.  For more control, use an utility
+function like tt(_XXX) in the argument's action.
+
 The forms of var(optspec) are:
 
 startitem()
Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.48
diff -u -r1.48 computil.c
--- Src/Zle/computil.c	2001/04/17 09:52:32	1.48
+++ Src/Zle/computil.c	2001/04/25 07:03:17
@@ -1941,7 +1941,12 @@
     case 's':
 	for (; lstate; lstate = lstate->snext)
 	    if (lstate->d->single && lstate->singles &&
-		lstate->actopts && lstate->opt) {
+		lstate->actopts
+#if 0
+                /* let's try without, for the -w option of _arguments */
+                && lstate->opt
+#endif
+                ) {
 		setsparam(args[1],
 			  ztrdup((lstate->ddef && lstate->dopt) ?
 				 (lstate->dopt->type == CAO_DIRECT ?

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

Re: problem with _arguments exclusion lists

[Sven Wischnowsky]

Ok, here's my suggestion.  The option's name is `-w', dunno if we should
exchange the meaning of -W and -w (-w is the stronger one, so to say).

Then I suggest to use the following as the pattern-match utility function:

  local mesg pat garbage

  mesg=()
  zparseopts -K -D -a garbage M: J: V: 1 2 n F: X:=mesg 

  [[ "$PREFIX$SUFFIX" != $~1 ]] && return 1

  if [[ $# -gt 1 || $#mesg -eq 0 ]]; then
    shift
    _message "$*"
  else
    _message -r "$mesg[2]"
  fi

  [[ -n "$PREFIX$SUFFIX" ]] 

It ignores the compadd-options that might be passed from the completion
system internals to called function and can extract a given explanation
string from that (e.g. when called from _arguments or _alternative).

The first real argument is the pattern to test for and if more arguments
are given, those are used as the description to display (overriding the
string from -X, if any).

It might be called as in:

  _arguments  -s '(-conf)-c+:numeric value:prop "[0-9]#"' '-conf' '-f'

or:

  _arguments  -s '(-conf)-c+: :prop "[0-9]#" numeric value' '-conf' '-f'

and makes that complete options and display the message after `-c<TAB>'.
After `-c<digits><TAB>' only the message will be displayed and after
`-c<non-digits><TAB>' only options will be completed.  All that due to
the new behaviour of completing options if the action returns non-zero.

That feels quite satisfying.

So, if anyway can tell me a good name for that utility function, I'm
going to commit it.  I really don't have the faintest idea.  Oliver?

Bye
  Sven

Index: Completion/Base/Utility/_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Base/Utility/_arguments,v
retrieving revision 1.3
diff -u -r1.3 _arguments
--- Completion/Base/Utility/_arguments	2001/04/05 12:12:47	1.3
+++ Completion/Base/Utility/_arguments	2001/04/24 09:59:46
@@ -4,7 +4,7 @@
 # descriptions given as arguments to this function.
 
 local long cmd="$words[1]" descr mesg subopts opt usecc autod
-local oldcontext="$curcontext" hasopts rawret optarg singopt
+local oldcontext="$curcontext" hasopts rawret optarg singopt alwopt
 
 long=$argv[(I)--]
 if (( long )); then
@@ -174,7 +174,7 @@
 
 subopts=()
 singopt=()
-while [[ "$1" = -(O*|[CRWs]) ]]; do
+while [[ "$1" = -(O*|[CRWsw]) ]]; do
   case "$1" in
   -C)  usecc=yes; shift ;;
   -O)  subopts=( "${(@P)2}" ); shift 2 ;;
@@ -182,13 +182,14 @@
   -R)  rawret=yes; shift;;
   -W)  optarg=yes; shift;;
   -s)  singopt=(-s); shift;;
+  -w)  alwopt=yes; shift;;
   esac
 done
 
 zstyle -s ":completion:${curcontext}:options" auto-description autod
 
 if (( $# )) && comparguments -i "$autod" "$singopt[@]" "$@"; then
-  local action noargs aret expl local tried
+  local action noargs aret expl local tried ret=1
   local next direct odirect equal single matcher matched ws tmp1 tmp2 tmp3
   local opts subc tc prefix suffix descrs actions subcs anum
   local origpre="$PREFIX" origipre="$IPREFIX" nm="$compstate[nmatches]"
@@ -280,7 +281,8 @@
 
               eval ws\=\( "${action[3,-3]}" \)
 
-              _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]"
+              _describe -t "$subc" "$descr" ws -M "$matcher" "$subopts[@]" ||
+                  alwopt=yes
 	      tried=yes
 
             elif [[ "$action" = \(*\) ]]; then
@@ -289,15 +291,17 @@
 
               eval ws\=\( "${action[2,-2]}" \)
 
-              _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws
+              _all_labels "$subc" expl "$descr" compadd "$subopts[@]" -a - ws ||
+                  alwopt=yes
 	      tried=yes
             elif [[ "$action" = \{*\} ]]; then
 
               # A string in braces is evaluated.
 
               while _next_label "$subc" expl "$descr"; do
-                eval "$action[2,-2]"
+                eval "$action[2,-2]" && ret=0
               done
+              (( ret )) && alwopt=yes
 	      tried=yes
             elif [[ "$action" = \ * ]]; then
 
@@ -305,8 +309,9 @@
 
 	      eval "action=( $action )"
               while _next_label "$subc" expl "$descr"; do
-                "$action[@]"
+                "$action[@]" && ret=0
               done
+              (( ret )) && alwopt=yes
 	      tried=yes
             else
 
@@ -314,15 +319,17 @@
 
 	      eval "action=( $action )"
               while _next_label "$subc" expl "$descr"; do
-                "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}"
+                "$action[1]" "$subopts[@]" "$expl[@]" "${(@)action[2,-1]}" && ret=0
 	      done
+              (( ret )) && alwopt=yes
 	      tried=yes
             fi
           fi
         fi
       done
-
-      if [[ -z "$matched$hasopts" && ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
+      if [[ -z "$hasopts" &&
+            ( -z "$matched" || -n "$alwopt" ) &&
+            ( -z "$aret" || "$PREFIX" = "$origpre" ) ]] &&
           _requested options &&
           { ! zstyle -T ":completion:${curcontext}:options" prefix-needed ||
             [[ "$origpre" = [-+]* || -z "$aret$mesg$tried" ]] } ; then
@@ -378,9 +385,10 @@
 	PREFIX="$prevpre"
 	IPREFIX="$previpre"
       fi
-      [[ -n "$tried" && "$PREFIX" != [-+]* ]] && break
+      [[ -n "$tried" && "${${alwopt:+$origpre}:-$PREFIX}" != [-+]* ]] && break
     done
-    if [[ -n "$opts" && -z "$aret$matched$mesg" &&
+    if [[ -n "$opts" && -z "$aret" &&
+          ( -z "$matched$mesg" || -n "$alwopt" ) &&
           nm -eq compstate[nmatches] ]]; then
 
       PREFIX="$origpre"
Index: Completion/X/Utility/_x_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_x_arguments,v
retrieving revision 1.2
diff -u -r1.2 _x_arguments
--- Completion/X/Utility/_x_arguments	2001/04/04 11:29:22	1.2
+++ Completion/X/Utility/_x_arguments	2001/04/24 09:59:47
@@ -17,7 +17,7 @@
 fi
 
 opts=()
-while [[ $1 = -(O*|[CRWs]) ]]; do
+while [[ $1 = -(O*|[CRWsw]) ]]; do
   opts=($opts $1)
   [[ $1 = -R ]] && rawret=yes
   shift
Index: Completion/X/Utility/_xt_arguments
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/X/Utility/_xt_arguments,v
retrieving revision 1.2
diff -u -r1.2 _xt_arguments
--- Completion/X/Utility/_xt_arguments	2001/04/04 11:29:22	1.2
+++ Completion/X/Utility/_xt_arguments	2001/04/24 09:59:47
@@ -53,7 +53,7 @@
 fi
 
 opts=()
-while [[ $1 = -(O*|[CRWs]) ]]; do
+while [[ $1 = -(O*|[CRWsw]) ]]; do
   opts=($opts $1)
   [[ $1 = -R ]] && rawret=yes
   shift
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.117
diff -u -r1.117 compsys.yo
--- Doc/Zsh/compsys.yo	2001/04/04 11:29:22	1.117
+++ Doc/Zsh/compsys.yo	2001/04/24 09:59:50
@@ -2937,6 +2937,18 @@
 normally not complete the other option directly after `tt(-a)', but it would
 allow that if given the tt(-W) option.
 
+Similarly, the option tt(-w) may be given to force completion of options
+even after options that get an argument in the same word.  For example,
+if a command takes the options `tt(a)' and `tt(b)', where `tt(a)' needs
+an argument in the same word, directly after the option character,
+tt(_arguments) would normally only execute the action for that argument
+and not offer other options as possible completions.  If given the
+tt(-w) option, it will offer other options as possible completions after
+executing the action for the argument.  Note that, depending on the
+action, this may mean that the other options can't really be completed,
+but at least they will be listed.  For more control, use an utility
+function like tt(_XXX) in the argument's action.
+
 The forms of var(optspec) are:
 
 startitem()
Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.48
diff -u -r1.48 computil.c
--- Src/Zle/computil.c	2001/04/17 09:52:32	1.48
+++ Src/Zle/computil.c	2001/04/24 09:59:51
@@ -1941,7 +1941,12 @@
     case 's':
 	for (; lstate; lstate = lstate->snext)
 	    if (lstate->d->single && lstate->singles &&
-		lstate->actopts && lstate->opt) {
+		lstate->actopts
+#if 0
+                /* let's try without, for the -o option of _arguments */
+                && lstate->opt
+#endif
+                ) {
 		setsparam(args[1],
 			  ztrdup((lstate->ddef && lstate->dopt) ?
 				 (lstate->dopt->type == CAO_DIRECT ?

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

Re: problem with _arguments exclusion lists

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> 1) Add an option to _arguments, that says that it should always try to
>    complete options after options specified with `-x-:...' or `-x+:...'.
> 2) Also, make it try completing options in those places even if the new
>    _arguments-option is not given but the action for the argument
>    returns non-null.

I'm happy with that.

>    The `returns non-null' is, of course, problematic again if the option-
>    argument has to be completed with a `->state' action.  But I think if

That's a bit of a pity.

>    And add a small utility function that can be put into an argument-
>    action and tests if the string typed so far matches some pattern.

Agreed.

>    For simplicity I would make it use the description given in the
>    _arguments-spec.

I'll be interested to see how you do that. I think the function will
have wider uses than just from _arguments such as from _alternative so
it would be good if it can cope with that.

>  And if a simple pattern match is enough for most
>    cases, this makes it sound as if we should just add a new action-
>    syntax, avoiding the need for an extra function consisting of only

I prefer the extra two-line function to extending _arguments' action
spec syntax. The function is a more general method which may be more
widely useful and it keeps things more in zsh shell syntax than in
_arguments syntax. Also, I can't see that guards on _arguments specs
would be particularly useful when matches are generated.

> Ok, would this be enough for now?  Later we can, as suggested by Oliver,
> add a way to change the behaviour on a per-option basis, using the
> option from 1) as the default.  If we ever meet a command that needs
> that much control.

Agreed.

Oliver

Re: problem with _arguments exclusion lists

[Sven Wischnowsky]

Let me try to summarise:


1) Add an option to _arguments, that says that it should always try to
   complete options after options specified with `-x-:...' or `-x+:...'.

   This makes it a stronger form of -W: -W makes it complete options
   after options that get an argument in the next word.  The new option
   says that other options are to be completed even if the argument
   has to or may be given in the same word.


2) Also, make it try completing options in those places even if the new
   _arguments-option is not given but the action for the argument
   returns non-null.

   The `returns non-null' is, of course, problematic again if the option-
   argument has to be completed with a `->state' action.  But I think if
   a command is complicated enough to require that, it should use the
   option from 1) anyway.

   And add a small utility function that can be put into an argument-
   action and tests if the string typed so far matches some pattern.
   For simplicity I would make it use the description given in the
   _arguments-spec.  And if a simple pattern match is enough for most
   cases, this makes it sound as if we should just add a new action-
   syntax, avoiding the need for an extra function consisting of only
   two lines.  More complicated tests can still be implemented with
   additional functions, of course.
   I don't remember exactly, but I think we were talking about pattern
   matching in _arguments-actions some time ago.  If we decide to put
   the simple matching-case into _arguments itself, we could also go
   another way: instead of making it a new type of action, we make it be
   some kind of `guard' that can be prefixed to any of the action-types
   _arguments supports now.  If it is given before an empty option, it
   only says if a message should be displayed or not.
   I think I like this even better.


Ok, would this be enough for now?  Later we can, as suggested by Oliver,
add a way to change the behaviour on a per-option basis, using the
option from 1) as the default.  If we ever meet a command that needs
that much control.


Bye
  Sven


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

Re: problem with _arguments exclusion lists

[Oliver Kiddle]

Sven Wischnowsky wrote:
> 
> ;-) I understood you, really.  But I'm pretty sure there are programs
> that allow other (single letter) options after that `-c', meaning that
> either `-c's argument is the empty string or that it comes in the next
> word.  Or something.  So I still think we need a way to tell _arguments
> that either:
> 
> 1) after all `-x-:...' or `-x+:...' options other options may be
>    completed, or

I suppose this option would involve another option to _arguments like
-W and it would only be useful with -s.

> 2) that after some of those options other options may be completed, or

And, I suppose this would handle commands which are inconsistent in the
way they behave for different options. For the _arguments syntax, I
can't think of much better than some additional random character before
the colon.

I suppose that of these (2) covers more possible situations so is the
most complete but we could have both where the option (as per (1))
specifies a default and the syntax for (2) overrides it. Keeping this in
mind, if (1) is implemented, (2) could be added later if we find
inconsistent commands for which it is needed.

> All that is independent of what we choose to use as the default.  I.e.,
> if we leave the current behaviour the default or if we make completing
> options there the default (unless otherwise specified).

I would probably vote for the current behaviour being the default - that
is not completing other options in this case because it is probably more
common for commands to parse arguments that way and it keeps the number
of matches down.

> Or maybe I'm thinking way to complicated again and we should just make
> it try completing options in such places, too.  If the user has already

Possibly, but I would err on the side of making it not try completing
options in such places. When I type commands, I tend to specify them in
a clear sensible way rather than the most minimal way that command
happens to allow.

> started typing the argument of the option, other option names won't
> match anyway.

True. And if other option names do match, the user might be trying to
complete the option name so it is important that it is added as a
match.

> Leaves only the slight ugliness that `-c<TAB>' would
> offer other single-letter options as possible completions (if _arguments
> was given the -s options), even if the command doesn't allow that after
> options that get an argument.

That is really quite ugly and backs up my feeling that this should not be
the default.

> 3) (what you described) that the argument of option `-x+:...' has to
>    match a certain pattern and if it doesn't match, other options are to
>    be completed there.

I think it is a good idea to maybe complete options only if we fail to
complete the option argument because it avoids the ugliness mentioned
above. Would it be possible to use a tag-order style to put the options
last here?

I wouldn't want to put the pattern in _arguments though. What follows is
a separate issue really so is a bit of a divergence.

As a test, I created an _number like this:
[[ $PREFIX$SUFFIX = [0-9]# ]] || return 1
_message 'number' && return 0
And then used this _arguments:
_arguments -s '-c+:number:_number' '-conf'

Now, if I complete after -co, I get the message:
	No matches for: `number' or `corrections'
What _arguments should do in this case is see the return code from
_number and from it conclude that we are not completing a parameter to
-c because it failed. For (3), it could then complete other single
letter options (it should be adding -conf as a match regardless). This may
be more complicated but is how I think we should be specifying patterns
if we use option (3).

Incidentally, with this when completing after just -c, the message
`number' is displayed to indicate that what is expected is a number. It
does not look up the format style with the descriptions tag and display
it in bold (with my style settings). I think it should because `number'
is a group of matches the same as other things we complete (option,
user etc), it is just that we haven't generated as matches all possible
numbers.

We could have a general function which is called like _message to
say we are completing such and such sort of thing but are not adding the
actual matches because it doesn't make sense to. It could take an option
for specifying a pattern to compare against $PREFIX/$SUFFIX to allow it
to fail when appropriate.

Oliver

Re: problem with _arguments exclusion lists

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> What I was basically getting at there is something along the lines of
> [[ $PREFIX$SUFFIX = [0-9]* ]] && _message 'number'
> so that after -co, it could see that the `o' doesn't match [0-9]* and
> would only complete further options (such as -conf).

;-) I understood you, really.  But I'm pretty sure there are programs
that allow other (single letter) options after that `-c', meaning that
either `-c's argument is the empty string or that it comes in the next
word.  Or something.  So I still think we need a way to tell _arguments
that either:

1) after all `-x-:...' or `-x+:...' options other options may be
   completed, or 
2) that after some of those options other options may be completed, or
3) (what you described) that the argument of option `-x+:...' has to
   match a certain pattern and if it doesn't match, other options are to
   be completed there.

All that is independent of what we choose to use as the default.  I.e.,
if we leave the current behaviour the default or if we make completing
options there the default (unless otherwise specified).


Or maybe I'm thinking way to complicated again and we should just make
it try completing options in such places, too.  If the user has already
started typing the argument of the option, other option names won't
match anyway.  Leaves only the slight ugliness that `-c<TAB>' would
offer other single-letter options as possible completions (if _arguments
was given the -s options), even if the command doesn't allow that after
options that get an argument.


Bye
  Sven


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

Re: problem with _arguments exclusion lists

[Oliver Kiddle]

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

> >   _arguments -s '(-conf)-c+:val' '-conf' '-f'
> > after -c, it completes with the 'val' message so even after -co, it
> > can't complete -conf. I found these problems with _pine which
> > completes a number after -c.
 
> Yes, i was aware of that.  The problem is that some programs would
> not
> continue parsing `-c...' as a possible option, while some would.  I
> think I would call such programs `well-behaved'.

I think you've misunderstood me here. Are you thinking of the case
where, for the _arguments example above some programs maybe allow the
`f' option after -c as `-cf3' to mean the same as `-c3 -f'?

In a case such as _pine, after `-c', there can either be a number which
is an argument to the -c option or it could go on to complete an option
with a longer name such as -conf, -character-set etc. At the moment, it
fails to complete the latter and it should do. This was the intended
gist of my last message.

> > Maybe there would be a use here for a basic
> > completion for numbers so that it can know that -co can not be -c
> with
> > a parameter.

What I was basically getting at there is something along the lines of
[[ $PREFIX$SUFFIX = [0-9]* ]] && _message 'number'
so that after -co, it could see that the `o' doesn't match [0-9]* and
would only complete further options (such as -conf).

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: problem with _arguments exclusion lists

[Sven Wischnowsky]

Oliver Kiddle wrote:

> --- Sven Wischnowsky <wischnow@informatik.hu-berlin.de> wrote:
> 
> > Hrmpf. Yes. This was a bit more complicated to fix because the option
> > should still keep itself from being offered as a possible completion
> > a
> > second time unless it may be given more than once.
> 
> I suspected that it mightn't be too easy when I posted the first
> message. The patch seems to fix it but the following still doesn't
> work:
>   _arguments -s '(-conf)-c+:val' '-conf' '-f'
> after -c, it completes with the 'val' message so even after -co, it
> can't complete -conf. I found these problems with _pine which completes
> a number after -c. Maybe there would be a use here for a basic
> completion for numbers so that it can know that -co can not be -c with
> a parameter.

Yes, i was aware of that.  The problem is that some programs would not
continue parsing `-c...' as a possible option, while some would.  I
think I would call such programs `well-behaved'.

I also seem to remember that we discussed this many months ago, but
don't know what we said about all this then.

It seems doable to add another option to _arguments telling it that even
after such an option other options should be completed.  Would that have
to include options described as `-c-:...'?  Or do we even have to allow
specifying that on a per-option basis, i.e. add yet another special
character that may be given after the option name to say that there is
an argument to be completed directly after the option, but other options
might come, too?

Bye
  Sven


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

Re: problem with _arguments exclusion lists

[Oliver Kiddle]

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

> Hrmpf. Yes. This was a bit more complicated to fix because the option
> should still keep itself from being offered as a possible completion
> a
> second time unless it may be given more than once.

I suspected that it mightn't be too easy when I posted the first
message. The patch seems to fix it but the following still doesn't
work:
  _arguments -s '(-conf)-c+:val' '-conf' '-f'
after -c, it completes with the 'val' message so even after -co, it
can't complete -conf. I found these problems with _pine which completes
a number after -c. Maybe there would be a use here for a basic
completion for numbers so that it can know that -co can not be -c with
a parameter.

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: problem with _arguments exclusion lists

[Sven Wischnowsky]

Oliver Kiddle wrote:

> The following doesn't work too well:
>   _arguments -s '(-conf)-c' '-conf' '-f'
> when you try to complete directly after `-c'. It should still allow the
> -conf option because the c could be the c from conf and not the -c
> option. This means that completing the -conf option isn't possible.

Hrmpf. Yes. This was a bit more complicated to fix because the option
should still keep itself from being offered as a possible completion a
second time unless it may be given more than once.

Bye
  Sven

Index: Src/Zle/computil.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/computil.c,v
retrieving revision 1.47
diff -u -r1.47 computil.c
--- Src/Zle/computil.c	2001/04/02 09:05:50	1.47
+++ Src/Zle/computil.c	2001/04/17 09:49:17
@@ -1145,7 +1145,7 @@
 static LinkList ca_xor;
 
 static int
-ca_inactive(Cadef d, char **xor, int cur, int opts)
+ca_inactive(Cadef d, char **xor, int cur, int opts, char *optname)
 {
     if ((xor || opts) && cur <= compcurrent) {
 	Caopt opt;
@@ -1153,6 +1153,8 @@
 	int sl = (d->set ? strlen(d->set) : -1), set = 0;
 
 	for (; (x = (opts ? "-" : *xor)); xor++) {
+            if (optname && strcmp(optname, x))
+                continue;
 	    if (ca_xor)
 		addlinknode(ca_xor, x);
 	    set = 0;
@@ -1315,9 +1317,9 @@
 	dopt = NULL;
 	doff = state.singles = arglast = 0;
 
-	if (ca_inactive(d, argxor, cur, 0) ||
+	if (ca_inactive(d, argxor, cur, 0, NULL) ||
 	    ((d->flags & CDF_SEP) && cur != compcurrent && !strcmp(line, "--"))) {
-	    if (ca_inactive(d, NULL, cur, 1))
+	    if (ca_inactive(d, NULL, cur, 1, NULL))
 		return 1;
 	    continue;
 	}
@@ -1391,7 +1393,7 @@
 	    if (!state.oargs[state.curopt->num])
 		state.oargs[state.curopt->num] = znewlinklist();
 
-	    if (ca_inactive(d, state.curopt->xor, cur, 0))
+	    if (ca_inactive(d, state.curopt->xor, cur, 0, state.curopt->name))
 		return 1;
 
 	    /* Collect the argument strings. Maybe. */
@@ -1444,7 +1446,7 @@
 		    if (!state.oargs[tmpopt->num])
 			state.oargs[tmpopt->num] = znewlinklist();
 
-		    if (ca_inactive(d, tmpopt->xor, cur, 0))
+		    if (ca_inactive(d, tmpopt->xor, cur, 0, tmpopt->name))
 			return 1;
 		}
 	    }
@@ -1476,7 +1478,7 @@
 	    return 1;
 	else if (state.arg && (!napat || !pattry(napat, line))) {
 	    /* Otherwise it's a normal argument. */
-	    if (napat && ca_inactive(d, NULL, cur + 1, 1))
+	    if (napat && ca_inactive(d, NULL, cur + 1, 1, NULL))
 		return 1;
 
 	    arglast = 1;
@@ -1791,7 +1793,7 @@
 			for (node = firstnode(nx); node; incnode(node)) {
 			    xor[0] = (char *) getdata(node);
 			    if (!strcmp(xor[0], def->sname) ||
-				ca_inactive(def, xor, compcurrent, 0))
+				ca_inactive(def, xor, compcurrent, 0, NULL))
 				break;
 			}
 			if (!node)

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

problem with _arguments exclusion lists

[Oliver Kiddle]

The following doesn't work too well:
  _arguments -s '(-conf)-c' '-conf' '-f'
when you try to complete directly after `-c'. It should still allow the
-conf option because the c could be the c from conf and not the -c
option. This means that completing the -conf option isn't possible.

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