Re: Pattern matching with _files vs command line

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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'

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

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.

ADDITIONAL ASIDE to -workers:  The weird side-effects that result
here from having the trailing "/" in the completion results seem
to be tangentially related to the thread from 39093 where the whole
current word gets erased.  When all the completions end in "/", it
is the first unambigous character, so

% foo <TAB>
% foo /

with the curson on top of the "/".  But now subsequent attempts to
complete end up looking for files in the root directory, because
the detail that there was an ambiguous prefix has been lost.