zsh -<TAB> dose not use menu completion

zsh -<TAB> dose not use menu completion

[Jun T.]

'zsh -<TAB>' does not work as I expect. With this simplest settings:

autoload -Uz compinit
compinit

if I type 'ls -<TAB><TAB>' then it goes into the menu completion. But
for 'zsh -<TAB><TAB>' or 'zsh --a<TAB><TAB>' automenu does not work.

I've tried a few other settings but I couldn't enable menu completion
for 'zsh -<TAB>'. For example, with the following settings,

zmodload zsh/complist
autoload -Uz compinit
compinit
zstyle ':completion:*' menu on select
zstyle ':completion:*' select-prompt ''    # may not be necessary

'ls -<TAB>' directly goes into the menu selection mode, but
'zsh -<TAB>' still just list the options and never goes into the menu
completion (or menu selection).


'zsh -^Xh' (_complete_help) gives

tags in context :completion::complete:zsh::
    all-files           (_files _default _sh) 
    argument-1 options  (_arguments _sh)
tags in context :completion::complete:zsh:argument-1:
    argument-1  (_message _arguments _sh)
tags in context :completion::complete:zsh:options:
    options  (_describe _arguments _sh

It seems
    argument-1 options  (_arguments _sh)
is causing the trouble, and If I specify

zstyle ':completion:*:zsh:*' tag-order options

then 'zsh -<TAB>' works as expected. Is this the only way to make menu
completion work for 'zsh -<TAB>'? If so, I feel it better to make it not
necessary for a user to specify this zstyle, but I don't know how to.


If I replace
	_arguments -S -s -- '*:'	(line 27 of _sh)
by
	_arguments -S -s --
then 'zsh -^Xh' gives
    options    (_arguments _sh)    # i.e., no argument-1
and 'zsh -<TAB>' works as expected without the zstyle above.
But I don't know why '*:' makes this difference.


Jun

Re: zsh -<TAB> dose not use menu completion

[Bart Schaefer]

On Feb 2, 10:56pm, Jun T. wrote:
} Subject: zsh -<TAB> dose not use menu completion
}
} if I type 'ls -<TAB><TAB>' then it goes into the menu completion. But
} for 'zsh -<TAB><TAB>' or 'zsh --a<TAB><TAB>' automenu does not work.

[...]

} If I replace
} 	_arguments -S -s -- '*:'	(line 27 of _sh)
} by
} 	_arguments -S -s --
} then 'zsh -^Xh' gives
}     options    (_arguments _sh)    # i.e., no argument-1
} and 'zsh -<TAB>' works as expected without the zstyle above.
} But I don't know why '*:' makes this difference.

Doc says (last sentence of this paragraph):

     In addition to options, `_arguments --' will try to deduce the
     types of arguments available for options when the form `--OPT=VAL'
     is valid.  It is also possible to provide hints by examining the
     help text of the command and adding HELPSPEC of the form
     `PATTERN:MESSAGE:ACTION'; note that other _arguments SPEC forms
     are not used.  The PATTERN is matched against the help text for an
     option, and if it matches the MESSAGE and ACTION are used as for
     other argument specifiers.  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.

With "zstyle ':completion:*:zsh:*' tag-order options" all the --optname
options are listed *after* all the single-letter options.  So there is
something going on with the sort order that causes the menu not to be
entered when the --optname list comes first.

Re: zsh -<TAB> dose not use menu completion

[Jun T.]

I put the following line (/dev/ttys003 is a tty on which I monitor)

echo '<'$argv'>'  >/dev/ttys003

at line 292 of _arguments. When "_arguments -S -s --" is called,
the initial part of the output to /dev/ttys003 is

<-S> <-s> <--help[show this message, then exit]> ...

while the output from "_arugments -S -s -- '*:'" looks like

<-S> <-s> <--help[show this message, then exit]:> ... <:> ...

i.e., a ':' is added to the end of each element of $argv. I believe
this is not a problem, but there is an element which consists of
a single : alone. I guess this ':' is later interpreted as the
argument-1.

I put a few more echo into _arguments to see where this <:> comes
from, and found that the problem is at line 29 of _arguments:

    typeset -U lopts

This initialize lopts as a scalar (empty string), not as an empty
array. When lopts is later converted to an array by

    lopts+=( new_element )

the original scalar value (empty string) remains as the 1st element.
For example,

$ typeset -U u
$ u+=( one )
$ echo '<'$u'>'
<> <one>

If '*:' is passed to "_arguments --" this empty element becomes ':'
in $argv somewhere.

Replacing -U by -Ua seems to fix the problem (see the patch below),
but: 

2015/02/03 02:15, Bart Schaefer <schaefer@brasslantern.com> wrote:

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

I can't reproduce this behavior.
If the sort style is on (default?) then the options with description
are always listed first, while if the sort style is off then the options
without description are listed first, irrespective of whether '*:' is
passed to "_argument --" or not (by modifying the line 27 of _sh).




diff --git a/Completion/Base/Utility/_arguments b/Completion/Base/Utility/_arguments
index d70c442..1f35e8d 100644
--- a/Completion/Base/Utility/_arguments
+++ b/Completion/Base/Utility/_arguments
@@ -26,7 +26,7 @@ if (( long )); then
 
   if (( ! ${(P)+name} )); then
     local iopts sopts pattern tmpo dir cur cache
-    typeset -U lopts
+    typeset -Ua lopts
 
     cache=()