Hi,
On Thu, Jan 12, 2012 at 03:56:28PM +0100, Matthieu Moy wrote:
> lists@xxxxxxxxxxxxxxxx (Stefan Haller) writes:
>
> > I'm using zsh 4.3.11.
> >
> > When I type "git log mas<TAB>", it completes to "git log master\ " (a
> > backslash, a space, and then the cursor).
Stefan, thanks for reporting and bisecting.
> The following patch makes the situation better, but is not really a fix:
>
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -525,7 +525,7 @@ __gitcomp ()
> __gitcomp_nl ()
> {
> local s=$'\n' IFS=' '$'\t'$'\n'
> - local cur_="$cur" suffix=" "
> + local cur_="$cur" suffix=""
>
> if [ $# -gt 2 ]; then
> cur_="$3"
>
> With this, the trailing space isn't added,
Yeah, this would be a regression for Bash users, because then they
will need to manually append that space.
> but e.g. "git checkout
> master<TAB>" does not add the trailing space, at all.
I'm not sure what you mean; did you got a trailing space after
'master<TAB>' before a31e6262 (completion: optimize refs completion,
2011-10-15)?
I'm not a zsh user myself, but just tried it and found that in
a31e626^ 'git checkout master<TAB>' doesn't add the trailing space,
and neither does 'git checkout mas<TAB>', which is in sync with what
Stefan reported ("Before this commit, I get "git log master" (with no
space at the end).").
> The problem is a little bit below:
>
> IFS=$s
> COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
>
> The -S "$suffix" adds a space to the completion, but ZSH escapes the
> space (which sounds sensible in general, but is not at all what we
> expect).
So it seems we have two issues here with zsh:
- Spaces appended with 'compgen -S " "' in __gitcomp_nl() are quoted.
This is the regression caused by a31e6262.
- Spaces appended in __gitcomp_1() (by echo "$word ") are stripped.
This is a long-standing issue; if those spaces weren't stripped, the
quoting issue would have been noted earlier, I suspect.
We could fix the regression by not appending a space suffix to
completion words in __gitcomp_nl(), but only when the completion
script is running under zsh to avoid hurting bash users, like this:
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2d02a7f3..49393243 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -601,6 +601,9 @@ __gitcomp_nl ()
suffix="$4"
fi
fi
+ if [ -n "${ZSH_VERSION-}" ] && [ "$suffix" = " " ]; then
+ suffix=""
+ fi
IFS=$s
COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
Although it wouldn't append a space at all for zsh users, that's
nothing new, it's just restoring old behavior. And then later someone
more knowledgable about the quirks of zsh's completion and in
particular zsh's bash completion emulation can come up with a proper
fix to the issue of quoted spaces and stripped trailing spaces.
However.
While playing around with zsh, I noticed that git completion works
without even sourcing git's bash completion script. As it turned out,
zsh ships its own git completion script[1], and from my cursory tests
it seems to be quite capable: it supports commands, aliases, options,
refs, ref1..ref2, config variables, ... and I also saw a __git_ps1()
equivalent for zsh.
So, is there any reason why you are still using git's bash completion
under zsh (which has some quirks and lacks some features) instead of
zsh's own? Perhaps it would make sense to point zsh users to zsh's
git completion and drop zsh compatibility from git's bash completion.
We did similar with vim config files: git included a vim syntax
highlight config file for commit messages under contrib/vim/, but
eventually we dropped it after vim started shipping more capable
git-specific config files (for git config files, rebase instruction
sheets, etc.).
[1] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=blob;f=Completion/Unix/Command/_git;hb=HEAD
Best,
Gábor
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html