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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 10, 2011, 10:44 UTC
Message-ID: <BANLkTikRM==ttn2qmd-PY9tdfUhe5Xtqzg@mail.gmail.com>
In-Reply-To: <20110510020421.GA25814@elie>

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

Show 13 quoted lines

> Felipe Contreras wrote:
>> On Tue, May 10, 2011 at 12:13 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>>        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?

This is what I explained: --- so by trying to set it as 'local' in git's completion, unexpected results occur; assignations are not propagated to outer levels in the call stack. ---

My text explains why Gabor's patch works: it doesn't set 'words' as local. Your text doesn't explain that; it generalizes that 'words' always behave that way, which is not the case. Your text also suggests that the assignments are always undone, which is not the case, as I explained; it only happens to the outer levels in the call stack.

Show 19 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.

I didn't notice that. That can be easily explained with one line:

--- 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). ---

-- 
Felipe Contreras