Hi, Sorry I missed this message before. 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? 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". >> Â Â Â Â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. -- 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