[Pkg-zsh-devel] Bug#658198: Autocompletion: 'ls --n<TAB>' first returns 'ls --n-g'.

[Daniel Shahaf]

A. Costa wrote on Tue, Jan 31, 2012 at 18:08:57 -0500:
> Package: zsh
> Version: 4.3.15-1
> Severity: minor
> 
> Dear Maintainer,
> 
> If I do:
> 
>     ls --n<TAB>
> 
> ...the first autocompletion from 'zsh' is:
> 
>     ls --n-g
> 
> Of course 'ls' has no '--n-g' option.
> 

No, but it does have --no-group and --numeric-uid-gid.  It is ambiguous
which one was meant, so zsh completes the unambiguous parts and asks you
to type in the rest: that's why you get «--n<CURSOR>-g» with the cursor
as shown.  At that point can type «o<TAB>» to complete the former option
and either «u<TAB>» or «-<TAB>» to complete the latter.  This is due to
matchspecs, as described under the path-completion style but with
hyphens rather than slashes.  (The gory details are in the manual under
"Completion matching control".)

If anything, the bug here is that «--n<TAB>-g» doesn't offer
--numeric-uid-gid, even though that option's existence was the reason
--no-group wasn't offered immediately.  However, I can't reproduce this
one when I set the «menu» style.

> A second <TAB> returns:
> 
>     ls --no-group
> 
> ...which is a valid 'ls' option.

--no-group is a valid option today.

> I looked in '/usr/share/zsh/functions/Completion/Unix/_ls' for
> clues, but didn't notice anything obviously wrong.  But I'm not
> a 'zsh' expert.

_ls is fine.  The matchspecs are handled elsewhere.  (They're fetched from
a C struct by the «comparguments -M» call in _arguments.)

> Hope this helps...

It does.  Thanks for the report.

Daniel
(Better late than never…)

> 
> 
> PS: This is a spin-off bug from Bug#463507.