2011/4/28 SZEDER GÃbor <szeder@xxxxxxxxxx>:
> On Wed, Apr 27, 2011 at 01:40:34AM -0500, Jonathan Nieder wrote:
>> The "_get_comp_words_by_ref -n := words" command from the
>> bash_completion library reassembles a modified version of COMP_WORDS
>> with ':' and '=' no longer treated as word separators and stores it in
>> the ${words[@]} array. ÂGit's programmable tab completion script uses
>> this to abstract away the difference between bash v3's and bash v4's
>> definitions of COMP_WORDS (bash v3 used shell words, while bash v4
>> breaks at separator characters); see v1.7.4-rc0~11^2~2 (bash: get
>> --pretty=m<tab> completion to work with bash v4, 2010-12-02).
>>
>> zsh has (or rather its completion functions have) another idea about
>> what ${words[@]} should contain: the array is prepopulated with the
>> words from the command it is completing. ÂFor reasons that are not
>> well understood, when git-completion.bash reserves its own "words"
>> variable with "local words", the variable becomes empty and cannot be
>> changed from then on. ÂSo the completion script neglects the arguments
>> it has seen, and words complete like git subcommand names. ÂFor
>> example, typing "git log origi<TAB>" gives no completions because
>> there are no "git origi..." commands.
>>
>> Work around this by using a different variable (comp_words) that is
>> not special to zsh. ÂSo now commands that completed correctly before
>> v1.7.4-rc0~11^2~2 on zsh should be able to complete correctly again.
>
> Thanks for this explanation. ÂI tried to fix this some time ago, but
> got only as far as to indentify that something is amiss with returning
> $words from _get_comp_words_by_ref(), and during tracing I saw so much
> weird and (for me) unexplicable zsh behavior that I simply gave up.
>
> But this patch heavily conflicted with one of my long-forgotten
> cleanup patch series, and that series together with the above
> explanation gave me alternative ideas for fixing this issue with zsh.
>
> So, here it is. ÂThe first two patches are independent cleanups, but
> they make the actual fix in the third patch so short.
>
> It works well as far as I tested it with both bash and zsh, but I
> would really appreciate a few extra sets of eyeballs for the cleanups
> and sanity-checking and testing of the bugfix.
>
>
> SZEDER GÃbor (3):
> Âbash: don't modify the $cur variable in completion functions
> Âbash: remove unnecessary _get_comp_words_by_ref() invocations
> Âbash: don't declare 'local words' to make zsh happy
>
> Âcontrib/completion/git-completion.bash | Â225 +++++++++-----------------------
> Â1 files changed, 64 insertions(+), 161 deletions(-)
Nice! Much better approach.
I also noticed that behavior when not defining 'words' as local, but
though modifying all those instances was overkill.
Acked-by: Felipe Contreras <felipe.contreras@xxxxxxxxx>
--
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