{"thread":{"id":"29410","subject":"Autocompletion - commands no longer work as stand alone","startedAt":"2012-01-20T16:32:05Z","lastAt":"2012-01-30T18:14:03Z","messageCount":6,"participants":["Nathan Bullock","Junio C Hamano","SZEDER Gábor"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"182860","messageId":"CAPx=Vfqj3UZuFv3Xmupy7k9arUxyZJyprm628p9QVKabdOz8cw@mail.gmail.com","threadId":"29410","inReplyTo":"CAPx=Vfp_HVr5W1fFic_1k+JsKr2RAKd-RK=VkfSgo7qkb5GsAw@mail.gmail.com","subject":"Autocompletion - commands no longer work as stand alone","fromName":"Nathan Bullock","fromEmail":"nathanbullock@gmail.com","sentAt":"2012-01-20T16:32:05Z","receivedAt":"2012-01-20T16:32:05Z","isPatch":false,"sender":{"key":"nathanbullock@gmail.com","avatar":"https://gravatar.com/avatar/d8d2714dc203db6b899a705e72b8b38a90bf78593022b744cecb8eb003c70a67?d=mp&s=160"},"body":"I have for a number of years had the following in my .bashrc\n\nalias br=\"git branch\"\ncomplete -F _git_branch br\n\nAs well as similar commands for co and log.\n\nRecently though this broke, now when I type something like \"br\nmas\" it will occasionally complain with messages\nlike:\nbash: [: 1: unary operator expected\n\nFrom digging through the source it looks like this was broken back in\nApril. (The commit is show at the bottom of this email.)\n\nSo my questions are:\n1. Is it reasonable for things like _git_branch to work as a\nstandalone autocompletion function instead of having to go through\n_git? I certainly like it to work as a standalone function. I also use\nit to add autocompletion to other bash scripts that I use frequently.\n\n2. If I add code that verifies that the variable cword exists at the\nstart of these functions and only if not call something like\n_get_comp_words_by_ref -n =: cur words cword prev. Would that be\nreasonable? I think this should address the performance concerns that\ncaused these to be removed in the first place, but it may make the\ncode uglier.\n\nI have already added wrapper functions in my bashrc so that this is no\nlonger a problem for me, but there may be other people who start\nhitting this as well once they start using newer versions of git.\n\nNathan\n\n\ncommit da4902a73017ad82b9926d03101ec69a2802d1e7\nAuthor: SZEDER Gábor \nDate:   Thu Apr 28 18:01:52 2011 +0200\n\n   completion: remove unnecessary _get_comp_words_by_ref() invocations\n\n   In v1.7.4-rc0~11^2~2 (bash: get --pretty=m completion to work\n   with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()\n   to access completion-related variables.  That was large change, and to\n   make it easily reviewable, we invoked _get_comp_words_by_ref() in each\n   completion function and systematically replaced every occurance of\n   bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with\n   variables set by _get_comp_words_by_ref().\n\n   This has the downside that _get_comp_words_by_ref() is invoked several\n   times during a single completion.  The worst offender is perhaps 'git\n   log mas': during the completion of 'master'\n   _get_comp_words_by_ref() is invoked no less than six times.\n\n   However, the variables $prev, $cword, and $words provided by\n   _get_comp_words_by_ref() are not modified in any of the completion\n   functions, and the previous commit ensures that the $cur variable is\n   not modified as well.  This makes it possible to invoke\n   _get_comp_words_by_ref() to get those variables only once in our\n   toplevel completion functions _git() and _gitk(), and all other\n   completion functions will inherit them.\n\n   Signed-off-by: SZEDER Gábor \n   Signed-off-by: Junio C Hamano \n"},{"id":"182869","messageId":"7vwr8mdvo8.fsf@alter.siamese.dyndns.org","threadId":"29410","inReplyTo":"CAPx=Vfqj3UZuFv3Xmupy7k9arUxyZJyprm628p9QVKabdOz8cw@mail.gmail.com","subject":"Re: Autocompletion - commands no longer work as stand alone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-20T19:24:23Z","receivedAt":"2012-01-20T19:24:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pinging Szeder. I personally do not think it is a crime for us to break\nanything that uses an internal function whose name begins with underscore,\nbut people more deeply involved in this part of the system may have ideas\nto help supporting even such users.\n\nNathan Bullock writes:\n\n> I have for a number of years had the following in my .bashrc\n>\n> alias br=\"git branch\"\n> complete -F _git_branch br\n>\n> As well as similar commands for co and log.\n>\n> Recently though this broke, now when I type something like \"br\n> mas\" it will occasionally complain with messages\n> like:\n> bash: [: 1: unary operator expected\n>\n> From digging through the source it looks like this was broken back in\n> April. (The commit is show at the bottom of this email.)\n>\n> So my questions are:\n> 1. Is it reasonable for things like _git_branch to work as a\n> standalone autocompletion function instead of having to go through\n> _git? I certainly like it to work as a standalone function. I also use\n> it to add autocompletion to other bash scripts that I use frequently.\n>\n> 2. If I add code that verifies that the variable cword exists at the\n> start of these functions and only if not call something like\n> _get_comp_words_by_ref -n =: cur words cword prev. Would that be\n> reasonable? I think this should address the performance concerns that\n> caused these to be removed in the first place, but it may make the\n> code uglier.\n>\n> I have already added wrapper functions in my bashrc so that this is no\n> longer a problem for me, but there may be other people who start\n> hitting this as well once they start using newer versions of git.\n>\n> Nathan\n>\n>\n> commit da4902a73017ad82b9926d03101ec69a2802d1e7\n> Author: SZEDER Gábor \n> Date: Thu Apr 28 18:01:52 2011 +0200\n>\n> completion: remove unnecessary _get_comp_words_by_ref() invocations\n>\n> In v1.7.4-rc0~11^2~2 (bash: get --pretty=m completion to work\n> with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()\n> to access completion-related variables. That was large change, and to\n> make it easily reviewable, we invoked _get_comp_words_by_ref() in each\n> completion function and systematically replaced every occurance of\n> bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with\n> variables set by _get_comp_words_by_ref().\n>\n> This has the downside that _get_comp_words_by_ref() is invoked several\n> times during a single completion. The worst offender is perhaps 'git\n> log mas': during the completion of 'master'\n> _get_comp_words_by_ref() is invoked no less than six times.\n>\n> However, the variables $prev, $cword, and $words provided by\n> _get_comp_words_by_ref() are not modified in any of the completion\n> functions, and the previous commit ensures that the $cur variable is\n> not modified as well. This makes it possible to invoke\n> _get_comp_words_by_ref() to get those variables only once in our\n> toplevel completion functions _git() and _gitk(), and all other\n> completion functions will inherit them.\n>\n> Signed-off-by: SZEDER Gábor \n> Signed-off-by: Junio C Hamano \n"},{"id":"182870","messageId":"CAPx=VfrZ+TZhX51gUfyep2Az0zwmdM3YsEkLMzxa7LSEUFzOnw@mail.gmail.com","threadId":"29410","inReplyTo":"7vwr8mdvo8.fsf@alter.siamese.dyndns.org","subject":"Re: Autocompletion - commands no longer work as stand alone","fromName":"Nathan Bullock","fromEmail":"nathanbullock@gmail.com","sentAt":"2012-01-20T19:33:03Z","receivedAt":"2012-01-20T19:33:03Z","isPatch":false,"sender":{"key":"nathanbullock@gmail.com","avatar":"https://gravatar.com/avatar/d8d2714dc203db6b899a705e72b8b38a90bf78593022b744cecb8eb003c70a67?d=mp&s=160"},"body":"So just as a comment on the use of underscores. The actual main auto\ncomplete function, _git, also starts with an underscore. From looking\nat the code it looked like the double underscore functions were the\ninternal ones.\n\n\n2012/1/20 Junio C Hamano :\n> Pinging Szeder. I personally do not think it is a crime for us to break\n> anything that uses an internal function whose name begins with underscore,\n> but people more deeply involved in this part of the system may have ideas\n> to help supporting even such users.\n>\n> Nathan Bullock writes:\n>\n>> I have for a number of years had the following in my .bashrc\n>>\n>> alias br=\"git branch\"\n>> complete -F _git_branch br\n>>\n>> As well as similar commands for co and log.\n>>\n>> Recently though this broke, now when I type something like \"br\n>> mas\" it will occasionally complain with messages\n>> like:\n>> bash: [: 1: unary operator expected\n>>\n>> From digging through the source it looks like this was broken back in\n>> April. (The commit is show at the bottom of this email.)\n>>\n>> So my questions are:\n>> 1. Is it reasonable for things like _git_branch to work as a\n>> standalone autocompletion function instead of having to go through\n>> _git? I certainly like it to work as a standalone function. I also use\n>> it to add autocompletion to other bash scripts that I use frequently.\n>>\n>> 2. If I add code that verifies that the variable cword exists at the\n>> start of these functions and only if not call something like\n>> _get_comp_words_by_ref -n =: cur words cword prev. Would that be\n>> reasonable? I think this should address the performance concerns that\n>> caused these to be removed in the first place, but it may make the\n>> code uglier.\n>>\n>> I have already added wrapper functions in my bashrc so that this is no\n>> longer a problem for me, but there may be other people who start\n>> hitting this as well once they start using newer versions of git.\n>>\n>> Nathan\n>>\n>>\n>> commit da4902a73017ad82b9926d03101ec69a2802d1e7\n>> Author: SZEDER Gábor \n>> Date:   Thu Apr 28 18:01:52 2011 +0200\n>>\n>>    completion: remove unnecessary _get_comp_words_by_ref() invocations\n>>\n>>    In v1.7.4-rc0~11^2~2 (bash: get --pretty=m completion to work\n>>    with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()\n>>    to access completion-related variables.  That was large change, and to\n>>    make it easily reviewable, we invoked _get_comp_words_by_ref() in each\n>>    completion function and systematically replaced every occurance of\n>>    bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with\n>>    variables set by _get_comp_words_by_ref().\n>>\n>>    This has the downside that _get_comp_words_by_ref() is invoked several\n>>    times during a single completion.  The worst offender is perhaps 'git\n>>    log mas': during the completion of 'master'\n>>    _get_comp_words_by_ref() is invoked no less than six times.\n>>\n>>    However, the variables $prev, $cword, and $words provided by\n>>    _get_comp_words_by_ref() are not modified in any of the completion\n>>    functions, and the previous commit ensures that the $cur variable is\n>>    not modified as well.  This makes it possible to invoke\n>>    _get_comp_words_by_ref() to get those variables only once in our\n>>    toplevel completion functions _git() and _gitk(), and all other\n>>    completion functions will inherit them.\n>>\n>>    Signed-off-by: SZEDER Gábor \n>>    Signed-off-by: Junio C Hamano \n"},{"id":"183056","messageId":"20120124232658.GD2256@goldbirke","threadId":"29410","inReplyTo":"7vwr8mdvo8.fsf@alter.siamese.dyndns.org","subject":"Re: Autocompletion - commands no longer work as stand alone","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2012-01-24T23:26:58Z","receivedAt":"2012-01-24T23:26:58Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi,\n\n\n> Nathan Bullock writes:\n> \n> > I have for a number of years had the following in my .bashrc\n> >\n> > alias br=\"git branch\"\n> > complete -F _git_branch br\n> >\n> > As well as similar commands for co and log.\n> >\n> > Recently though this broke, now when I type something like \"br\n> > mas\" it will occasionally complain with messages\n> > like:\n> > bash: [: 1: unary operator expected\n> >\n> > From digging through the source it looks like this was broken back in\n> > April. (The commit is show at the bottom of this email.)\n> >\n> > So my questions are:\n> > 1. Is it reasonable for things like _git_branch to work as a\n> > standalone autocompletion function instead of having to go through\n> > _git? I certainly like it to work as a standalone function. I also use\n> > it to add autocompletion to other bash scripts that I use frequently.\n> >\n> > 2. If I add code that verifies that the variable cword exists at the\n> > start of these functions and only if not call something like\n> > _get_comp_words_by_ref -n =: cur words cword prev. Would that be\n> > reasonable?\n\nThat would be too fragile, it will break if $cword is set in the\nenvironment from which you invoke _git_() completion functions\ndirectly (i.e. not though _git()).\n\n> > I think this should address the performance concerns that\n> > caused these to be removed in the first place, but it may make the\n> > code uglier.\n\nActually it was not a performance problem, but a cleanup in a patch\nseries to fix a zsh-related bug. Without this cleanup the bugfix\nwould have been much more intrusive.\n\n http://thread.gmane.org/gmane.comp.version-control.git/172142/focus=172369\n\n\n> > I have already added wrapper functions in my bashrc so that this is no\n> > longer a problem for me, but there may be other people who start\n> > hitting this as well once they start using newer versions of git.\n\nThis issue was reported earlier, so it seems there are people who\nwould like to use it. But getting $cur, $cword, etc. variables right\nin _git_() completion functions is just part of the problem,\nthere are other issues, as mentioned in the previous thread:\n\n http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232\n\nUnfortunately, I couldn't come up with a solution yet that doesn't\nintroduce too much code churn and doesn't cause yet another\ninconsistency between bash and zsh. I also haven't looked whether\nthere are other issues similar to that with _git_fetch() mentioned on\nthe above link.\n\n\nBest,\nGábor\n"},{"id":"183317","messageId":"CAPx=Vfo20wWKOTeeKc=WM9dOpm85enTZHJsTnBL5uh8v0r6PRQ@mail.gmail.com","threadId":"29410","inReplyTo":"20120124232658.GD2256@goldbirke","subject":"Re: Autocompletion - commands no longer work as stand alone","fromName":"Nathan Bullock","fromEmail":"nathanbullock@gmail.com","sentAt":"2012-01-30T12:00:23Z","receivedAt":"2012-01-30T12:00:23Z","isPatch":false,"sender":{"key":"nathanbullock@gmail.com","avatar":"https://gravatar.com/avatar/d8d2714dc203db6b899a705e72b8b38a90bf78593022b744cecb8eb003c70a67?d=mp&s=160"},"body":"2012/1/24 SZEDER Gábor :\n> Hi,\n>\n>\n>> Nathan Bullock writes:\n>>\n>> > I have for a number of years had the following in my .bashrc\n>> >\n>> > alias br=\"git branch\"\n>> > complete -F _git_branch br\n>> >\n>> > As well as similar commands for co and log.\n>> >\n>> > Recently though this broke, now when I type something like \"br\n>> > mas\" it will occasionally complain with messages\n>> > like:\n>> > bash: [: 1: unary operator expected\n>> >\n>> > From digging through the source it looks like this was broken back in\n>> > April. (The commit is show at the bottom of this email.)\n>> >\n>> > So my questions are:\n>> > 1. Is it reasonable for things like _git_branch to work as a\n>> > standalone autocompletion function instead of having to go through\n>> > _git? I certainly like it to work as a standalone function. I also use\n>> > it to add autocompletion to other bash scripts that I use frequently.\n>> >\n>> > 2. If I add code that verifies that the variable cword exists at the\n>> > start of these functions and only if not call something like\n>> > _get_comp_words_by_ref -n =: cur words cword prev. Would that be\n>> > reasonable?\n>\n> That would be too fragile, it will break if $cword is set in the\n> environment from which you invoke _git_() completion functions\n> directly (i.e. not though _git()).\n>\n>> > I think this should address the performance concerns that\n>> > caused these to be removed in the first place, but it may make the\n>> > code uglier.\n>\n> Actually it was not a performance problem, but a cleanup in a patch\n> series to fix a zsh-related bug.  Without this cleanup the bugfix\n> would have been much more intrusive.\n>\n>  http://thread.gmane.org/gmane.comp.version-control.git/172142/focus=172369\n>\n>\n>> > I have already added wrapper functions in my bashrc so that this is no\n>> > longer a problem for me, but there may be other people who start\n>> > hitting this as well once they start using newer versions of git.\n>\n> This issue was reported earlier, so it seems there are people who\n> would like to use it.  But getting $cur, $cword, etc. variables right\n> in _git_() completion functions is just part of the problem,\n> there are other issues, as mentioned in the previous thread:\n>\n>  http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232\n>\n> Unfortunately, I couldn't come up with a solution yet that doesn't\n> introduce too much code churn and doesn't cause yet another\n> inconsistency between bash and zsh.  I also haven't looked whether\n> there are other issues similar to that with _git_fetch() mentioned on\n> the above link.\n\nAt the end of this thread that you refer to,\nhttp://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232,\nthere is a set of wrapper functions that look reasonably good for\nsolving this problem. There was a question if those could be included\nin the main git code base. Do you know if that is likely to happen?\n\nNathan\n"},{"id":"183348","messageId":"7vliopcb2s.fsf@alter.siamese.dyndns.org","threadId":"29410","inReplyTo":"CAPx=Vfo20wWKOTeeKc=WM9dOpm85enTZHJsTnBL5uh8v0r6PRQ@mail.gmail.com","subject":"Re: Autocompletion - commands no longer work as stand alone","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-30T18:14:03Z","receivedAt":"2012-01-30T18:14:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nathan Bullock writes:\n\n> ... There was a question if those could be included\n> in the main git code base. Do you know if that is likely to happen?\n\nIt entirely is up to the author of the patch.\n\n\"I have this random code on Github so people can just copy and paste it in\ntheir .bashrc\" may be a good starting point to give hint to people who are\ninterested to come up with a good patch with a use example on a handful of\ncomment lines and a readable commit log message.\n\nI didn't see it happen in that thread, so perhaps nobody was interested\nback then.\n"}]}