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

[Felipe Contreras <felipe.contreras@gmail.com>]

On Tue, May 10, 2011 at 5:04 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> 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.

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