{"thread":{"id":"27314","subject":"[PATCH v5 (for maint)] git-completion: fix regression in zsh support","startedAt":"2011-05-10T12:20:39Z","lastAt":"2011-05-10T22:18:58Z","messageCount":6,"participants":["Felipe Contreras","Junio C Hamano","Jonathan Nieder"],"isPatch":true,"patchVersion":5,"patchTotal":null},"messages":[{"id":"167595","messageId":"1305030039-16044-1-git-send-email-felipe.contreras@gmail.com","threadId":"27314","inReplyTo":null,"subject":"[PATCH v5 (for maint)] git-completion: fix regression in zsh support","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-05-10T12:20:39Z","receivedAt":"2011-05-10T12:20:39Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Right now zsh is quite broken; the completion doesn't notice when\nthere's a subcommand. For example: \"git log origi<TAB>\" gives no\ncompletions because it would try to find a \"git origi...\" command. The\nissue would be gone in zsh 4.3.12, but for now we can workaround it by\nporting the same fix.\n\nThe problem started after commit v1.7.4-rc0~11^2~2 (bash: get\n--pretty=m<tab> completion to work with bash v4), which introduced\n_get_comp_words_by_ref() that comes from bash-completion[1] scripts, and\nrelies on the 'words' variable. However, it turns out 'words' is a\nspecial variable used by zsh completion. From zshcompwid(1):\n\n  [...] the parameters are reset on each function exit (including nested\n  function calls from within the completion widget) to the values they\n  had when the function was entered.\n\nAs a result, subcommand words are lost.\n\nThis is now fixed in the latest master branch of zsh[2] by simply\ndefining 'words' as hidden (typeset -h), which removes the special\nmeaning inside the emulated bash function. So let's do the same.\n\nJonathan Nieder helped on the commit message.\n\n[1] http://bash-completion.alioth.debian.org/\n[2] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=e880604f029088f32fb1ecc39213d720ae526aaa\n\nReported-by: Stefan Haller <lists@haller-berlin.de>\nComments-by: SZEDER Gábor <szeder@ira.uka.de>\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n contrib/completion/git-completion.bash |    8 ++++++++\n 1 files changed, 8 insertions(+), 0 deletions(-)\n\nv2: fix _gitk() too as Szeder suggested.\n\nv3: improve commit message as Jonathan Nieder suggested.\n    Also, improve comments.\n\nv4: more commit message improvements\n\nv5: even more commit message improvements from Jonathan's version\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 840ae38..a7d20df 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -2710,6 +2710,10 @@ _git ()\n \tif [[ -n ${ZSH_VERSION-} ]]; then\n \t\temulate -L bash\n \t\tsetopt KSH_TYPESET\n+\n+\t\t# workaround zsh's bug that leaves 'words' as a special\n+\t\t# variable in versions < 4.3.12\n+\t\ttypeset -h words\n \tfi\n \n \tlocal cur words cword\n@@ -2761,6 +2765,10 @@ _gitk ()\n \tif [[ -n ${ZSH_VERSION-} ]]; then\n \t\temulate -L bash\n \t\tsetopt KSH_TYPESET\n+\n+\t\t# workaround zsh's bug that leaves 'words' as a special\n+\t\t# variable in versions < 4.3.12\n+\t\ttypeset -h words\n \tfi\n \n \t__git_has_doubledash && return\n-- \n1.7.5.1\n"},{"id":"167606","messageId":"7vr586jwzm.fsf@alter.siamese.dyndns.org","threadId":"27314","inReplyTo":"1305030039-16044-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v5 (for maint)] git-completion: fix regression in zsh support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-10T17:17:49Z","receivedAt":"2011-05-10T17:17:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Right now zsh is quite broken;...\n\nYuck--sounds like zsh as a whole is broken, but certainly you didn't mean\nthat ;-) Could you also clarify \"Right now\" a bit?\n\nIs \"The git-completion script in contrib/ in 1.7.5 is broken for versions\nof zsh before 4.3.12\" a good rewrite of the above?\n\nNo need for resend if that is the only change required.\n"},{"id":"167607","messageId":"BANLkTinRB-hUwOdZsWRFZWxUAebkFeaGVQ@mail.gmail.com","threadId":"27314","inReplyTo":"7vr586jwzm.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v5 (for maint)] git-completion: fix regression in zsh support","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-05-10T17:36:33Z","receivedAt":"2011-05-10T17:36:33Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, May 10, 2011 at 8:17 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> Right now zsh is quite broken;...\n>\n> Yuck--sounds like zsh as a whole is broken, but certainly you didn't mean\n> that ;-)\n\nRight: s/zsh/zsh support/\n\n> Could you also clarify \"Right now\" a bit?\n>\n> Is \"The git-completion script in contrib/ in 1.7.5 is broken for versions\n> of zsh before 4.3.12\" a good rewrite of the above?\n\nWell, \"right now\" all versions of zsh are before 4.3.12. I also don't\nsee the point mentioning of 1.7.5. Maybe \"The git-completion script in\ncontrib/ is quite broken\".\n\n> of zsh before 4.3.12\"\n> No need for resend if that is the only change required.\n\nAll right. Hopefully there won't be other changes.\n\n-- \nFelipe Contreras\n"},{"id":"167609","messageId":"7vd3jqjtqx.fsf@alter.siamese.dyndns.org","threadId":"27314","inReplyTo":"BANLkTinRB-hUwOdZsWRFZWxUAebkFeaGVQ@mail.gmail.com","subject":"Re: [PATCH v5 (for maint)] git-completion: fix regression in zsh support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-10T18:27:50Z","receivedAt":"2011-05-10T18:27:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Well, \"right now\" all versions of zsh are before 4.3.12.\n\nI was trying to help people who read the log in 12 months.  They can\ncertainly see the date of the commit, but then they have to correlate that\ndate with the then-current version of zsh if you do not mention it.\n\n> I also don't\n> see the point mentioning of 1.7.5. Maybe \"The git-completion script in\n> contrib/ is quite broken\".\n\nThat is Ok by me, if you mean this zsh breakages is not something our\nrecent change has exposed.  Mentioning 1.7.5 only helps the users if\ngit-completion.bash in 1.7.4 did not have an issue even on the current zsh\nand 1.7.5 had an issue. I thought you may know which without me having to\ndig that information out.\n"},{"id":"167635","messageId":"20110510221600.GD1994@elie","threadId":"27314","inReplyTo":"1305030039-16044-1-git-send-email-felipe.contreras@gmail.com","subject":"Re: [PATCH v5 (for maint)] git-completion: fix regression in zsh support","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-10T22:16:00Z","receivedAt":"2011-05-10T22:16:00Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Felipe Contreras wrote:\n\n> Right now zsh is quite broken; the completion doesn't notice when\n> there's a subcommand. For example: \"git log origi<TAB>\" gives no\n> completions because it would try to find a \"git origi...\" command. The\n> issue would be gone in zsh 4.3.12, but for now we can workaround it by\n> porting the same fix.\n>\n> The problem started after commit v1.7.4-rc0~11^2~2 (bash: get\n> --pretty=m<tab> completion to work with bash v4), which introduced\n> _get_comp_words_by_ref() that comes from bash-completion[1] scripts, and\n> relies on the 'words' variable. However, it turns out 'words' is a\n\nThe _get_comp_words_by_ref function does not rely on but writes to the\n'words' variable.  Aside from that, this is a nicer summary.\n\n> special variable used by zsh completion. From zshcompwid(1):\n[...]\n> [2] http://zsh.git.sourceforge.net/git/gitweb.cgi?p=zsh/zsh;a=commitdiff;h=e880604f029088f32fb1ecc39213d720ae526aaa\n\nI doubt this URL will last forever.  Why not just say commit\ne880604f029088f32fb1ecc, or '\"29140: hide the \"words\" special variable\nso that it may be used as an ordinary variable by bash completions\",\n2011-05-04' which conveniently includes a mailing list reference?\n\nThanks for the fix and your patience with me.  To answer the sincere\nquestions I could find among your replies to v4:\n\n - I included the \"completion: move private shopt shim for zsh to\n   __git_ namespace\" patch in the series as a reminder to Junio,\n   since he had requested one.\n\n - \"in no part of [compgen] does the zsh emulation make use of the\n   'words' special variable\" is just plain false.  compgen -F uses the\n   'words' variable, and we are lucky to have not needed to use it\n   yet.\n\n - I changed the comment because when I read the original, putting\n   myself in the shoes of someone who didn't know the context, I found\n   it confusing.  \"work around bug in old versions of zsh\" just leaves\n   me wondering \"What bug?  Is it a bug in the behavior of 'local',\n   and are we working around it by using an alternate spelling?\"  \n\n   That said, I suppose the main point of a comment is to say\n   \"something important happens here\", and a person can use \n\n\tgit log -S\"workaround zsh's bug\" -- contrib/completion/git-completion.bash\n\n   to find out what exactly it is, so no harm done.\n"},{"id":"167636","messageId":"20110510221858.GE1994@elie","threadId":"27314","inReplyTo":"7vd3jqjtqx.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v5 (for maint)] git-completion: fix regression in zsh support","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-10T22:18:58Z","receivedAt":"2011-05-10T22:18:58Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> Mentioning 1.7.5 only helps the users if\n> git-completion.bash in 1.7.4 did not have an issue even on the current zsh\n> and 1.7.5 had an issue. I thought you may know which without me having to\n> dig that information out.\n\nThe zsh support was introduced in 1.7.4-rc0[1] and the breakage was introduced\nin 1.7.4-rc0[2], for what it's worth.\n\n[1] v1.7.4-rc0~169^2 (completion: make compatible with zsh, 2010-09-06)\n[2] v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work\nwith bash v4, 2010-12-02)\n"}]}