Re: [PATCH v3 (for maint)] git-completion: fix zsh support

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 10, 2011, 02:04 UTC
Message-ID: <20110510020421.GA25814@elie>
In-Reply-To: <BANLkTikkhryMa69DSx4EAYjw+aar4icKcQ@mail.gmail.com>

Hi,

Sorry I missed this message before.

Felipe Contreras wrote:

> On Tue, May 10, 2011 at 12:13 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 7 quoted lines

>>        zsh's bash completion emulation layer does not sufficiently
>>        insulate us from that reality.  In particular, the variable
>>        keeps the "special" attribute (even after a declaration "local
>>        words"), so assignments within a function are undone whenever
>>        the function returns.
>
> That explains less.

I believe you. Could you give a hint of what it misses, so that it can be fixed?

What I was trying to say is that (in the previous paragraph) it turns out 'words' is a special variable used by zsh completion and (in the quoted text)

 - we would prefer to use that variable for something else

 - zsh's bashcompinit library can and should help us to do so

 - it would do so by using typeset -h to hide the variable, an
   important effect of which is to clear the attribute called
   "special"

 - even declaring "local words" does not clear that attribute

 - the pertinent effect here is that (in the words of the zshcompwid
   manpage) as long as parameters like words remain special, "except
   for compstate, the parameters are reset on each function exit
   (including nested function calls from within the completion widget)
   to the values they had when the function was entered".

Show 11 quoted lines

>>        In particular, until 3bee6a473 (completion: don't declare
>>        'local words' to make zsh happy, 2011-04-28), the "words" array
>>        would be cleared in _git by declaring "local words" and its new
>>        value would never be propagated from _get_comp_words_by_ref so
>>        it remained empty and the completion script could not tell that
>>        there were existing subcommand names on the command line (so
>>        "git log m<TAB>" would complete subcommand names).
>
> I don't see the point in explaining in excruciating detail all the
> series of steps in which an unset variable causes problems; the
> variable doesn't get set, thus one can assume there are problems.

Am I daft? I guess so. I really do have sympathy for the person who runs into this code, and wanting to check while making some change with unrelated purpose that it is still fixed, fires up zsh and runs

	git a<TAB>

.  Does it complete?  Yep, check, moving on.  Oops.

There's some flamebait in the rest of your responses, so I'm snipping the rest of my explanations. If you have sincere questions about my feedback in the future, I'd be glad to answer them.