On Tue, May 10, 2011 at 5:04 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Felipe Contreras wrote: >> On Tue, May 10, 2011 at 12:13 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html