zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: "Jun T." <takimoto-j@kba.biglobe.ne.jp>
Cc: 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 22:13:35 +0000	[thread overview]
Message-ID: <20160311221335.GA6922@tarsus.local2> (raw)
In-Reply-To: <EEE2B08D-72CE-49AB-861E-20CC7F6F2F77@kba.biglobe.ne.jp>

Jun T. wrote on Fri, Mar 11, 2016 at 17:24:02 +0900:
> 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.
> 

I don't understand the difference either, and I'm afraid I don't have
the brainwidth to look into the 'ls'/_description issue at the moment.
However, since using (bQ) in _git seems to have no adverse effect, I'll
go ahead and commit 38129.  (We can always back it out if we find it
introduces a regression.)

> 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_ignore_line has no effect. Of course I can use
> zstyle ':completion:*:*:(^(rm|git*)):*:*files' ...
> but ...

Seems like the easy fix would be to make compadd take multiple -F
options, so «compadd -F foo -F bar» would use both 'foo' and 'bar'.

Implementing this would consist of changing this piece of code ('sp' is
the place to append to, 'p' is a pointer into 'argv' which are the
arguments of compadd; the «if (!*sp)» will need to grow an 'else'
branch):

diff --git a/Src/Zle/complete.c b/Src/Zle/complete.c
index ee4e5b0..30fab54 100644
--- a/Src/Zle/complete.c
+++ b/Src/Zle/complete.c
@@ -704,15 +704,18 @@ bin_compadd(char *name, char **argv, UNUSED(Options ops), UNUSED(int func))
 	    }
 	    if (sp) {
 		if (p[1]) {
+		    /* Pasted argument: -Xfoo. */
 		    if (!*sp)
 			*sp = p + 1;
 		    p = "" - 1;
 		} else if (argv[1]) {
+		    /* Argument in a separate word: -X foo. */
 		    argv++;
 		    if (!*sp)
 			*sp = *argv;
 		    p = "" - 1;
 		} else {
+		    /* Missing argument: argv[N] == "-X", argv[N+1] == NULL. */
 		    zwarnnam(name, e, *p);
 		    zsfree(mstr);
 		    return 1;

Cheers,

Daniel


      reply	other threads:[~2016-03-11 22:13 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.
2016-03-11 22:13           ` Daniel Shahaf [this message]

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=20160311221335.GA6922@tarsus.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=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).