Pattern matching with _files vs command line

Pattern matching with _files vs command line

[Marko Myllynen]

Hi,

With the file-patterns style unset and the following compdef:

#compdef foo

local expl ret=1

_wanted files expl file _files -g '*(-FM)' && ret=0

return ret

I see the following difference, is this expected or perhaps a bug?

% find
.
./empty
./full
./full/test.txt
./file.txt
% ls -d *(-FM)
full/
% foo <TAB>
empty   full    full/ 
% foo empty/

Both the double match for full and empty being offered were
unexpected to me.

Thanks,

-- 
Marko Myllynen

Re: Pattern matching with _files vs command line

[Bart Schaefer]

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.

Re: 39093 erases variant with slashes (was: Re: Pattern matching with _files vs command line)

[Bart Schaefer]

On Sep 11,  9:42am, Daniel Shahaf wrote:
} Subject: 39093 erases variant with slashes (was: Re: Pattern matching with
}
} Bart Schaefer wrote on Fri, Sep 09, 2016 at 19:40:33 -0700:
} > 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 /
} > 
} 
} Could you share the reproducer for this please?

Run this anywhere with more than one subdirectory not all of which have
a common prefix; e.g., the zsh source tree:

torch% compinit -D
torch% _f () { _files -g '*(/M)' }
torch% compdef _f f
torch% zstyle \* file-patterns %p:globbed-files
torch% f <TAB>
torch% f /

If the zstyle is omitted, the groups globbed-files and directories contain
identical sets of matches but are for some reason not de-duped against one
another (probably because none of them matches an actual file name) so you
get a listing instead of the unambiguous-insertion behavior.

Re: Pattern matching with _files vs command line

[Marko Myllynen]

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

Re: Pattern matching with _files vs command line

[Bart Schaefer]

On Sep 12,  7:30am, Marko Myllynen wrote:
}
} 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
} > 
} >   # People prefer to have directories shown on first try as default.
} >   # Even if the calling function didn't use -/.
} > 
} >   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.

Yes, that's connected to this:

} > HOWEVER, you've actually broken things with your glob pattern.  Adding
} > the (M) flag means that the generated completions end with a "/"

If you fix the glob pattern to remove the (M) qualifier, then tag-order
works (at least for me).  If you leave the (M) in there, tag-order is
broken.  I don't really understand why this is the case; it seems to
have something to do with whether the string passed to "compadd" really
does match a file name (which it won't when the "/" is appended).

Re: Pattern matching with _files vs command line

[Marko Myllynen]

Hi,

On 2016-09-12 18:18, Bart Schaefer wrote:
> On Sep 12,  7:30am, Marko Myllynen wrote:
> }
> } 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
> } > 
> } >   # People prefer to have directories shown on first try as default.
> } >   # Even if the calling function didn't use -/.
> } > 
> } >   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.
> 
> Yes, that's connected to this:
> 
> } > HOWEVER, you've actually broken things with your glob pattern.  Adding
> } > the (M) flag means that the generated completions end with a "/"
> 
> If you fix the glob pattern to remove the (M) qualifier, then tag-order
> works (at least for me).  If you leave the (M) in there, tag-order is
> broken.

Sorry, should have mentioned that I tested already without (M). Both
with 5.0.2 and latest git master (otherwise I had default zstyle
settings). Since the earlier stanza already solved the issue, not sure
is this worth pursuing further.

Thanks,

-- 
Marko Myllynen