[PATCH] complete two or more options for zsh

[PATCH] complete two or more options for zsh

[Jun T.]

% zsh -<TAB>

This offers zsh's options, but the following does not work:

% zsh -v -<TAB>

Here, -v can be any other option.

The reason seems to be that all the optspecs generated by
  _argument -- '*:'   (_sh: line 24)
look like
  -v[equivalent to --verbose]:   --aliases:   etc.
i.e., a ':' is appended to their ends (so the option requires
an argument).

This ':' is added by
  cache+=( "${(@)^tmp}${descr}" )   (_arguments: line 282)
where $descr is equal to ':', which comes from the helpspec '*:'
passed to _arguments. 

Not specifying a helpspec at all seems to fix the problem.
Or using '*' or '*: :  ' as a helpspec seems to work as well.

BTW, the description of _arguments in zshcompsys manpage says:

  The special
  case of `*:' means both message and action are empty, which  has
  the  effect of causing options having no description in the help
  output to be ordered in listings ahead of options  that  have  a
  description.

But even with '*:' options without description are listed after
those with description (and it has a side effect that ':' is appended
to the generated optspecs). Are there any ways to control the order
of listing?


diff --git a/Completion/Unix/Command/_sh b/Completion/Unix/Command/_sh
index 21ebfc3..1b51122 100644
--- a/Completion/Unix/Command/_sh
+++ b/Completion/Unix/Command/_sh
@@ -24,6 +24,6 @@ fi
 
 local ret=$?
 
-[[ $service == zsh ]] && _arguments -S -s -- '*:' && ret=0
+[[ $service == zsh ]] && _arguments -S -s -- && ret=0
 
 return ret

Re: [PATCH] complete two or more options for zsh

[Bart Schaefer]

On Sep 20,  4:27am, Jun T. wrote:
} Subject: [PATCH] complete two or more options for zsh
}
} % zsh -<TAB>
} 
} This offers zsh's options, but the following does not work:
} 
} % zsh -v -<TAB>
} 
} Here, -v can be any other option.

There's another problem, which is made worse by your change:  The
default thing to complete for "zsh <TAB>" is options rather than
script names.  Prior to your change, a side-effect was that script
names began to be completed as they should have been all along,
which is probably why nobody noticed before.  After your change,
script names are never offered unless you first type at least one
character that is not "-".

} The reason seems to be that all the optspecs generated by
}   _argument -- '*:'   (_sh: line 24)
} look like
}   -v[equivalent to --verbose]:   --aliases:   etc.
} i.e., a ':' is appended to their ends (so the option requires
} an argument).
} 
} This ':' is added by
}   cache+=( "${(@)^tmp}${descr}" )   (_arguments: line 282)
} where $descr is equal to ':', which comes from the helpspec '*:'
} passed to _arguments. 

Hm.  Is this a bug in _arguments rather than in the way that _sh
called _arguments?  That is, should descr ever be a single ":"?

(That _sh calls _arguments the way it does is already somewhat a
problem; _arguments doesn't behave well when it's not driving the
whole show.)

Re: [PATCH] complete two or more options for zsh

[Jun T.]

2015/09/23 14:39, Bart Schaefer <schaefer@brasslantern.com> wrote:

> After your change,
> script names are never offered unless you first type at least one
> character that is not "-".

If you type

% zsh <TAB>

then script names (or any file names) *are* offered, but they are
at the end of the long list of options without description (and before
the options with description), so they may be not easy to find.
The real problem is that options are offered even if no '-' is
typed yet. I think this was so even before my patch.

I was using

zstyle ':completion:*' group-name ''

and then the file names were listed before the options (under the
group name 'file').

Anyway, yes, it's better to do all the completion by _arguments alone.
How about the patch below?
(or is it better to create _zsh to do the completion for zsh only?).

> Hm.  Is this a bug in _arguments rather than in the way that _sh
> called _arguments?  That is, should descr ever be a single ":"?


If there is ever an intended effect of specifying '*:' as a helpspec,
then it would better to fix _arguments to do the intended job.

2015/09/20 04:27, I wrote:
> But even with '*:' options without description are listed after
> those with description

This was wrong; I was testing with lots of my own zstyles.
With only 'autoload _Uz compinit; compint', then options with
description are listed after options without description irrespective
of whether I use '*:' or not.

So anyway '*:' seems to have no effect on how the options are ordered.
What is the intended effect of '*:' as a help spec?


diff --git a/Completion/Unix/Command/_sh b/Completion/Unix/Command/_sh
index 1b51122..1b80bd7 100644
--- a/Completion/Unix/Command/_sh
+++ b/Completion/Unix/Command/_sh
@@ -1,12 +1,14 @@
 #compdef sh ksh bash zsh csh tcsh rc
 
 if [[ $service == zsh ]]; then
-  # try a bit harder
-  if [[ ${words[CURRENT-1]} == -o ]]; then
-    _options
-    # no other possibilities
-    return
-  fi
+  _arguments -S -s : \
+    '*-o+[set named option]:option:_options' \
+    '*+o+[unset named option]:option:_options' \
+    '(1 -)-c[run a command]:command:_cmdstring' \
+    '(-)1:script file:_files' \
+    '*:command arguments' \
+    -- && return 0
+  return 1
 fi
 
 if (( CURRENT == ${words[(i)-c]} + 1 )); then
@@ -21,9 +23,3 @@ else
   fi
   _default
 fi
-
-local ret=$?
-
-[[ $service == zsh ]] && _arguments -S -s -- && ret=0
-
-return ret

Re: [PATCH] complete two or more options for zsh

[Bart Schaefer]

On Sep 26,  1:04am, Jun T. wrote:
}
} Anyway, yes, it's better to do all the completion by _arguments alone.
} How about the patch below?
} (or is it better to create _zsh to do the completion for zsh only?).

If the zsh case is never going to use any of the common code for other
shells, then it would probably be better to create an _zsh.  I'm
trying to think of ways that might fail to be backward-compatible with
existing compdef configs, but not coming up with anything.

} > Hm.  Is this a bug in _arguments rather than in the way that _sh
} > called _arguments?  That is, should descr ever be a single ":"?
} 
} If there is ever an intended effect of specifying '*:' as a helpspec,
} then it would better to fix _arguments to do the intended job.
} 
} So anyway '*:' seems to have no effect on how the options are ordered.
} What is the intended effect of '*:' as a help spec?

The person who could definitively answer that hasn't read this list in
at least a decade.  Maybe someone else remembers, but I don't.

Re: [PATCH] complete two or more options for zsh

[Jun T.]

A few additions to _zsh:
support -s and -b, and offer files for script args.


diff --git a/Completion/Unix/Command/_zsh b/Completion/Unix/Command/_zsh
index 3b6d7ad..d432aa9 100644
--- a/Completion/Unix/Command/_zsh
+++ b/Completion/Unix/Command/_zsh
@@ -3,6 +3,8 @@
 _arguments -S -s : \
   '*-o+[set named option]:option:_options' \
   '*+o+[unset named option]:option:_options' \
+  '(1 -s --shinstdin)'{-s,--shinstdin}'[read commands from standard input]' \
+  '(-)-b[end of option processing, like --]' \
   '(1 -)-c[run a command]:command:_cmdstring' \
   '(-)1:script file:_files' \
-  '*:command arguments' --
+  '*:script arguments:_files' --

Re: [PATCH] complete two or more options for zsh

[Bart Schaefer]

On Oct 1,  1:03am, Jun T. wrote:
} Subject: Re: [PATCH] complete two or more options for zsh
}
} A few additions to _zsh:
} support -s and -b, and offer files for script args.

Probably the ideal way to complete script args is to use "compset -n"
to simulate the script name appearing in command position, and then
call _normal.  This may require use of a ->state action so that it
can be handled after _arguments returns.

Re: [PATCH] complete two or more options for zsh

[Jun T.]

On 2015/10/01, at 1:19, Bart Schaefer <schaefer@brasslantern.com> wrote:

> Probably the ideal way to complete script args is to use "compset -n"
> to simulate the script name appearing in command position, and then
> call _normal.


Before sending the previous patch I tried

*::script argumets:_normal

and the following worked (IF script had its own compdef):

% zsh script <TAB>    # or -<TAB>

But then I thought there would be not much chance that the user had
defined compdef for the script; otherwise it would just complete files.
(Or are there any difference even if there is no compdef for the script?)
And it caused 'zsh -s <TAB>' to complete executables instead of arguments.
So I thought it would just be enough to call _files.

But, yes, maybe calling _normal would be useful for some users.
How about the following? (includes my previous patch)


diff --git a/Completion/Unix/Command/_zsh b/Completion/Unix/Command/_zsh
index 3b6d7ad..a541467 100644
--- a/Completion/Unix/Command/_zsh
+++ b/Completion/Unix/Command/_zsh
@@ -1,8 +1,23 @@
 #compdef zsh
 
+local curcontext=$curcontext state state_descr line expl
+typeset -A opt_args
+
 _arguments -S -s : \
   '*-o+[set named option]:option:_options' \
   '*+o+[unset named option]:option:_options' \
+  '(1 -s --shinstdin)'{-s,--shinstdin}'[read commands from standard input]' \
+  '(-)-b[end of option processing, like --]' \
   '(1 -)-c[run a command]:command:_cmdstring' \
   '(-)1:script file:_files' \
-  '*:command arguments' --
+  '*::script arguments:->args' -- && return 0
+
+case $state in
+  (args)
+    if [[ -n ${opt_args[(I)-c|-s|--shinstdin]} ]]; then
+      _files
+    else
+      _normal
+    fi
+    ;;
+esac