From: "Jun T." <takimoto-j@kba.biglobe.ne.jp>
To: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: __git_ignore_line positional argument (un)escaping (was: Re: _git-reset doesn't complete newly staged files)
Date: Fri, 11 Mar 2016 17:24:02 +0900 [thread overview]
Message-ID: <EEE2B08D-72CE-49AB-861E-20CC7F6F2F77@kba.biglobe.ne.jp> (raw)
In-Reply-To: <20160310232054.GA10995@tarsus.local2>
On 2016/03/11, at 8:20, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> With just ${(Q)line[...}}, you lose the ability to distinguish «git add
> f\[a-z\]o <TAB>» from «git add f[a-z]o <TAB>».
(snip)
With the following style:
zstyle ':completion:*:*:ls:*' ignore-line true
With the current git HEAD:
[1]% touch foo 'f[a-z]o' '[f]oo'
[2]% ls f\[a-z\]o <TAB> # OK: f\[a-z\]o not offered
[3]% git add f\[a-z\] <TAB> # no: f\[a-z\]o is offered again
[4]% ls f[a-z]o <TAB> # no: foo is offered
[5]% git add f[a-z]o <TAB> # no: foo is offered
With ${(bQ)..} in __git_ignore_line and _description:
[6]% ls f\[a-z\]o <TAB> # no: f\[a-z\]o is offered again
[7]% git add f\[a-z\] <TAB> # OK: f\[a-z\]o is not offered
[8]% ls f[a-z]o <TAB> # OK: foo is not offered
[9]% git add f[a-z]o <TAB> # OK: foo is not offered
I don't know why the behavior is different between ls and git add
in the first two cases ([2][3]/[6][7]), because _description and
__git_ignore_line uses virtually the same escaping method.
> 2. The ignore-line currently uses the following escaping:
> .
> # Completion/Base/Core/_description
> 50 if zstyle -s ":completion:${curcontext}:$1" ignore-line hidden; then
> 51 local -a qwords
> 52 qwords=( ${words//(#m)[\[\]()\\*?#<>~\^\|]/\\$MATCH} )
> .
> Should the ignore-line style use ${(bQ)}?
I've copied the line from _rm about two years ago; see workers/32435.
I don't remember the detail (sorry), but it seems I tried to escape
only the characters which are already escaped on the command line so
that a bare (active, unescaped) * etc can go into _comp_ignore and
% ls f* <TAB>
does not offer foo etc. But I abandoned this method because patterns
with qualifier caused a problem like:
% touch foo # foo does not have execution permission
% ls f*(x) <TAB> # foo is NOT offered
With (bQ), this does't happen, but now (as in [6] above):
% touch 'a[b]c' 'd<e>f' 'g(h)i'
% ls a\[b\]c d\<e\>f g\(h\)i <TAB> # all the files are still offered
This doesn't happen with the current HEAD. I don't know which is
better; maybe patterns like f* are frequently used but strange
file names like 'a[b]c' rarely happen, so using (bQ) is somewhat
better...? And I don't understand why ls and 'git add' behaves
differently.
On 2016/03/10, at 23:35, Mikael Magnusson <mikachu@gmail.com> wrote:
> Why does _git special case this at all, isn't the generic ignore-line
> mechanism for the git-add context good enough?
I have no idea why. I just assumed there was a reason to do that.
It would be better to use generic ignore-line if possible, of course.
If I have
zstyle ':completion:*:*:(^rm):*:*files' ignored-patterns '*?.o' '*?.old'
then '-F _comp_ignore' is passed to compadd, and the '-F ignored' added
by __git_ignroe_line has no effect. Of course I can use
zstyle ':completion:*:*:(^(rm|git*)):*:*files' ...
but ...
Sorry I fear I will not be able to reply for several days or so.
next prev parent reply other threads:[~2016-03-11 8:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 8:08 _git-reset doesn't complete newly staged files Jun T.
2016-03-03 5:07 ` Jun T.
2016-03-07 3:16 ` Jun T.
2016-03-09 13:24 ` Daniel Shahaf
2016-03-09 23:33 ` Daniel Shahaf
2016-03-10 23:15 ` [PATCH] _git: Fix completion of diffs against the index when treeish isn't shell-safe Daniel Shahaf
2016-03-10 12:03 ` _git-reset doesn't complete newly staged files Jun T.
2016-03-10 14:35 ` Mikael Magnusson
2016-03-10 23:20 ` __git_ignore_line positional argument (un)escaping (was: Re: _git-reset doesn't complete newly staged files) Daniel Shahaf
2016-03-11 8:24 ` Jun T. [this message]
2016-03-11 22:13 ` Daniel Shahaf
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=EEE2B08D-72CE-49AB-861E-20CC7F6F2F77@kba.biglobe.ne.jp \
--to=takimoto-j@kba.biglobe.ne.jp \
--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).