From: Felipe Contreras Date: Tue, 10 May 2011 10:44:50 GMT Subject: Re: [PATCH v3 (for maint)] git-completion: fix zsh support Message-ID: In-Reply-To: <20110510020421.GA25814@elie> On Tue, May 10, 2011 at 5:04 AM, Jonathan Nieder wrote: > Felipe Contreras wrote: >> On Tue, May 10, 2011 at 12:13 AM, Jonathan Nieder 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" 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 > > .  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" would complete subcommand names). --- -- Felipe Contreras