Re: Pattern matching with _files vs command line

[Marko Myllynen <myllynen@xxxxxxxxxx>]

Hi,

On 2016-09-10 05:40, Bart Schaefer wrote:
> On Sep 9,  8:39am, Marko Myllynen wrote:
> }
> } _wanted files expl file _files -g '*(-FM)' && ret=0
> } 
> } I see the following difference, is this expected or perhaps a bug?
> 
> It's perhaps a documentation shortcoming.
> 
> _files actually creates three groups of completion results:
>   globbed-files
>   directories
>   all-files
> 
> There's a little comment buried in _files:
> 
>   # People prefer to have directories shown on first try as default.
>   # Even if the calling function didn't use -/.
> 
> So what you're seeing is both the globbed-files group and the directories
> group.  The all-files group is empty because the globbed-files group is
> not.
> 
> The way around this is to use either the file-patterns style, or the
> tag-order style.  Either of these is supposed to work:
> 
>   zstyle :completion::complete:foo:: file-patterns '%p:globbed-files'

Thanks, this did the trick!

>   zstyle :completion::complete:foo:: tag-order globbed-files -

This, however, doesn't seem to work: with or without the former this
stops completion for foo altogether.

> HOWEVER, you've actually broken things with your glob pattern.  Adding
> the (M) flag means that the generated completions end with a "/" --
> that is, the "/" is not just shown in the completion listing, it's
> actually required to match against any partial word already on the
> command line, which causes a variety of strange effects (including the
> duplicates in your original listing).  What you really mean is just:
> 
> --- 8< --- snip --- 8< ---
> #compdef foo
> _wanted files expl file _files -g '*(-F)'
> --- 8< --- snip --- 8< ---
> 
> There's no need for the "ret" local if you're only making one call
> to _wanted, you can just use the return value from that directly.

Yeah, it was a copypaste from a larger function which wanted ret.

Thanks,

-- 
Marko Myllynen