From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: Pattern matching with _files vs command line
Date: Fri, 9 Sep 2016 19:40:33 -0700 [thread overview]
Message-ID: <160909194033.ZM19936@torch.brasslantern.com> (raw)
In-Reply-To: <75f69404-5bc4-20e5-caf7-3d0a6dd87b59@redhat.com>
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.
next prev parent reply other threads:[~2016-09-10 2:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 5:39 Marko Myllynen
2016-09-10 2:40 ` Bart Schaefer [this message]
[not found] ` <20160911094221.GA18467@fujitsu.shahaf.local2>
2016-09-11 16:18 ` 39093 erases variant with slashes (was: Re: Pattern matching with _files vs command line) Bart Schaefer
2016-09-12 4:30 ` Pattern matching with _files vs command line Marko Myllynen
2016-09-12 15:18 ` Bart Schaefer
2016-09-12 15:34 ` Marko Myllynen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=160909194033.ZM19936@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).