Re: [PATCH] git-completion: workaround zsh COMPREPLY bug

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] git-completion: workaround zsh COMPREPLY bug

From: Matthieu Moy <hidden>
Date: 2016-06-15 22:52:51

Felipe Contreras [off-list ref] writes:
The simplest and most generic solution is to hide all the changes we do
to IFS, so that "foo \nbar " is recognized by zsh as "foo bar". This
works on versions of git before and after the introduction of
__gitcomp_nl (a31e626), and versions of zsh before and after 4.3.12.
[...]
+
+		# another workaround for zsh because it would quote spaces in
+		# the COMPREPLY array if IFS doesn't contain spaces
+		typeset -h IFS
No time to test right now, but is this not going to

1) leave IFS as hidden even outside the completion script, possibly
affecting unrelated scripts that would need to set IFS as local and keep
its special effect?

2) break cases where strings are to be split on \n only (e.g. see
"foo bar\nboz" as three possible completions "foo", "bar", "boz" instead
of "foo bar" and "boz"?

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [PATCH] git-completion: workaround zsh COMPREPLY bug

From: Felipe Contreras <hidden>
Date: 2016-06-15 22:52:51

On Wed, Jan 25, 2012 at 9:41 AM, Matthieu Moy
[off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
The simplest and most generic solution is to hide all the changes we do
to IFS, so that "foo \nbar " is recognized by zsh as "foo bar". This
works on versions of git before and after the introduction of
__gitcomp_nl (a31e626), and versions of zsh before and after 4.3.12.
[...]
quoted
+
+             # another workaround for zsh because it would quote spaces in
+             # the COMPREPLY array if IFS doesn't contain spaces
+             typeset -h IFS
No time to test right now, but is this not going to

1) leave IFS as hidden even outside the completion script, possibly
affecting unrelated scripts that would need to set IFS as local and keep
its special effect?
What special effect?

Unrelated scripts can still set IFS as local.

You can test this:

---
#!/bin/sh

if [[ -n ${ZSH_VERSION-} ]]; then
    autoload -U +X bashcompinit && bashcompinit
fi

_foo()
{
    typeset -h IFS
    local cur="${COMP_WORDS[COMP_CWORD]}"
    local IFS=$'\n'
    w[0]='first '
    w[1]='second and space '
    w[2]='third\\ quoted\\ space '
    ./test1 >> /tmp/t1.txt
    COMPREPLY=( $(compgen -W "${w[*]}" -- $cur) )
}
complete -o nospace -F _foo foo
---

test1:
---
#!/bin/sh

test1() {
	local IFS=$'\n'
	w=( $(echo -e "foo \nbar"))
	echo "test1: 0:'${w[0]}' 1:'${w[1]}'"
}

test1

w=( $(echo -e "foo \nbar"))
echo "test2: 0:'${w[0]}' 1:'${w[1]}'"
---

The result in /tmp/t1.txt would be:
test1: 0:'foo ' 1:'bar'
test2: 0:'foo' 1:'bar'

Regardless of whether you use typeset -h or not.
2) break cases where strings are to be split on \n only (e.g. see
"foo bar\nboz" as three possible completions "foo", "bar", "boz" instead
of "foo bar" and "boz"?
Those cases are already broken, which is what I reported to the zsh
mailing list. You would get "foo\ bar" and "boz", and that's after
4.3.12; before, compgen -W would still break the completions in 3,
because they did 'results+=( $words )', instead of 'results+=(
"$words" )'.

Cheers.

-- 
Felipe Contreras
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help