Re: _files -g <pattern> offers files that don't match the pattern and conversely

[Bart Schaefer <schaefer@brasslantern.com>]

On Sat, Jul 15, 2023 at 6:32 AM Johan Grande <nahoj@crans.org> wrote:
>
> % _f() { _files -g 'c(.)' }; compdef _f f
> % f <tab>
> a  b       # even though 'a' and 'b' don't match the pattern

The only way I can make this happen is if "a" and "b" are directories.
_files will complete local directory names if there are no matching
files.

> % _f() { _path_files -g 'c(.)' }; compdef _f f
> % f <tab>  # nothing

_path_files expects the pattern to match directories too.

> % _f() { _files -g '^(a #)(.)' }; compdef _f f
> % f <tab>  # nothing, even though 'b' matches the pattern

The space in the pattern needs to be quoted, it's being taken as a
word separator.

_f() { _files -g '^(a\ #)(.)' }

I haven't investigated possible fixes.

> % _f() { _path_files -g '^(a #)(.)' }; compdef _f f
> % f <tab>  # becomes
> % f b

Unlike _files, _path_files is applying the pattern directly and
doesn't have a problem with the space.

> Also, and this is the same for _files and _path_files:
>
> % f() { echo $@ }
> % _f() { _files -g 'c' }; compdef _f f
> % f <tab>  # becomes
> % f c      # even though there is no such file

There's only one possible completion, so it's offered.