From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
git@vger.kernel.org, "SZEDER Gábor" <szeder@ira.uka.de>
Subject: Re: [PATCH for maint] git-completion: fix zsh support
Date: Fri, 6 May 2011 12:34:59 +0300 [thread overview]
Message-ID: <BANLkTim8=D3ivFoOsbAvDBSRbAu+0us-2g@mail.gmail.com> (raw)
In-Reply-To: <20110506052744.GA15132@elie>
On Fri, May 6, 2011 at 8:27 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>>> Maybe simplest would be to use Szeder's fix + make the zsh version of
>>> _get_comp_words_by_ref not overwrite "words" at all?
>>
>> I do not use zsh myself, but it appears to me that these three-patch
>> series can graduate and if real zsh users find problems after using it
>> they can be fixed independenty in-tree.
>>
>> Would that risk too many patch ping-pong among zsh users on 'master'?
>> The "don't declare 'local words' in zsh" patch seems to be the right
>> work-around for the peculiar semantics of "words" array, at least to me.
>
> Gábor's patches already work. I don't think they will cause breakage
> or patch ping-pong.
>
> I was trying to imagine Felipe's objection and all I could think of
> was that it is not so appealing that _get_comp_words_by_ref is not
> actually writing to "words". For example, the following on top of
> sg/completion-updates (= 3bee6a4) will print a greeting and the words
> being completed when you press tab, rather than <foo> <bar> <baz>:
[...]
> In practice it works great since "words" already has the right
> content, but maybe the "typeset -h" suggestion was motivated by a
> desire to have something easier to explain.
>
> I don't think that's a very strong reason to prevent the fix from
> graduating, though I suppose I would be happy to see something like
> the following on top at some point.
>
> -- 8< --
> Subject: completion: do not pretend to assign to special variable $words on zsh
>
> The special variable $words already has essentially the same meaning
> as bash's COMP_WORDS on zsh. While assigning one to the other appears
> to work okay, as a no-op, that is actually an illusion --- the value
> of $words can be changed in the _get_comp_words_by_ref function where
> it is assigned, but after that function returns, $words is back to
> normal.
>
> Guard against future breakage by adding a comment mentioning this and
> removing the redundant assignment.
I don't really object to Gábor's patches. The third one actually fixes
the issue.
The thing is that it's a *workaround*, and I prefer to keep
workarounds to the minimal. So I prefer my patch that introduces only
2 new lines and doesn't change the semantics of the rest of the code.
Moreover, it's already fixed in zsh's master, so at some point we
might want to remove it, and it's easier to remove 2 non-intrusive
lines.
But anyway, my end goal is to get this into the 'maint' branch. It's
up to Junio how to get the fix there (if at all), but I think it's
easier to just apply my patch there.
Cheers.
--
Felipe Contreras
next prev parent reply other threads:[~2011-05-06 9:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-05 14:24 [PATCH for maint branch] git-completion: fix zsh support Felipe Contreras
2011-05-05 17:34 ` Junio C Hamano
2011-05-05 19:29 ` Felipe Contreras
2011-05-05 18:59 ` SZEDER Gábor
2011-05-05 19:52 ` [PATCH for maint] " Felipe Contreras
2011-05-05 23:25 ` Jonathan Nieder
2011-05-06 4:51 ` Junio C Hamano
2011-05-06 5:27 ` Jonathan Nieder
2011-05-06 9:34 ` Felipe Contreras [this message]
2011-05-06 9:27 ` Felipe Contreras
2011-05-06 9:59 ` Jonathan Nieder
2011-05-06 10:06 ` Jonathan Nieder
2011-05-09 13:51 ` Felipe Contreras
2011-05-06 1:28 ` Jonathan Nieder
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='BANLkTim8=D3ivFoOsbAvDBSRbAu+0us-2g@mail.gmail.com' \
--to=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=szeder@ira.uka.de \
/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.
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).