Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Biglobe-Sender: Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 $1510$) Subject: Re: __git_ignore_line positional argument (un)escaping (was: Re: _git-reset doesn't complete newly staged files) From: "Jun T." In-Reply-To: <20160310232054.GA10995@tarsus.local2> Date: Fri, 11 Mar 2016 17:24:02 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160309132444.GA2428@tarsus.local2> <20160310232054.GA10995@tarsus.local2> To: "zsh-workers@zsh.org" X-Mailer: Apple Mail (2.1510) X-Biglobe-Spnum: 56029 X-Seq: zsh-workers 38131 On 2016/03/11, at 8:20, Daniel Shahaf wrote: >=20 > With just ${(Q)line[...}}, you lose the ability to distinguish =C2=ABgit= add > f\[a-z\]o =C2=BB from =C2=ABgit add f[a-z]o =C2=BB. (snip) With the following style: zstyle ':completion:*:*:ls:*' ignore-line true =20 With the current git HEAD: [1]% touch foo 'f[a-z]o' '[f]oo' [2]% ls f\[a-z\]o # OK: f\[a-z\]o not offered [3]% git add f\[a-z\] # no: f\[a-z\]o is offered again [4]% ls f[a-z]o # no: foo is offered [5]% git add f[a-z]o # no: foo is offered With ${(bQ)..} in __git_ignore_line and _description: [6]% ls f\[a-z\]o # no: f\[a-z\]o is offered again [7]% git add f\[a-z\] # OK: f\[a-z\]o is not offered [8]% ls f[a-z]o # OK: foo is not offered [9]% git add f[a-z]o # 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=3D( ${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* 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) # foo is NOT offered With (bQ), this does't happen, but now (as in [6] above): % touch 'a[b]c' 'df' 'g(h)i' % ls a\[b\]c d\f g$h$i # 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 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.