* Autocompletion - commands no longer work as stand alone [not found] <CAPx=Vfp_HVr5W1fFic_1k+JsKr2RAKd-RK=VkfSgo7qkb5GsAw@mail.gmail.com> @ 2012-01-20 16:32 ` Nathan Bullock 2012-01-20 19:24 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Nathan Bullock @ 2012-01-20 16:32 UTC (permalink / raw) To: git I have for a number of years had the following in my .bashrc alias br="git branch" complete -F _git_branch br As well as similar commands for co and log. Recently though this broke, now when I type something like "br mas<command completion>" it will occasionally complain with messages like: bash: [: 1: unary operator expected From digging through the source it looks like this was broken back in April. (The commit is show at the bottom of this email.) So my questions are: 1. Is it reasonable for things like _git_branch to work as a standalone autocompletion function instead of having to go through _git? I certainly like it to work as a standalone function. I also use it to add autocompletion to other bash scripts that I use frequently. 2. If I add code that verifies that the variable cword exists at the start of these functions and only if not call something like _get_comp_words_by_ref -n =: cur words cword prev. Would that be reasonable? I think this should address the performance concerns that caused these to be removed in the first place, but it may make the code uglier. I have already added wrapper functions in my bashrc so that this is no longer a problem for me, but there may be other people who start hitting this as well once they start using newer versions of git. Nathan commit da4902a73017ad82b9926d03101ec69a2802d1e7 Author: SZEDER Gábor <szeder@ira.uka.de> Date: Thu Apr 28 18:01:52 2011 +0200 completion: remove unnecessary _get_comp_words_by_ref() invocations In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref() to access completion-related variables. That was large change, and to make it easily reviewable, we invoked _get_comp_words_by_ref() in each completion function and systematically replaced every occurance of bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with variables set by _get_comp_words_by_ref(). This has the downside that _get_comp_words_by_ref() is invoked several times during a single completion. The worst offender is perhaps 'git log mas<TAB>': during the completion of 'master' _get_comp_words_by_ref() is invoked no less than six times. However, the variables $prev, $cword, and $words provided by _get_comp_words_by_ref() are not modified in any of the completion functions, and the previous commit ensures that the $cur variable is not modified as well. This makes it possible to invoke _get_comp_words_by_ref() to get those variables only once in our toplevel completion functions _git() and _gitk(), and all other completion functions will inherit them. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Autocompletion - commands no longer work as stand alone 2012-01-20 16:32 ` Autocompletion - commands no longer work as stand alone Nathan Bullock @ 2012-01-20 19:24 ` Junio C Hamano 2012-01-20 19:33 ` Nathan Bullock 2012-01-24 23:26 ` SZEDER Gábor 0 siblings, 2 replies; 6+ messages in thread From: Junio C Hamano @ 2012-01-20 19:24 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Nathan Bullock, git Pinging Szeder. I personally do not think it is a crime for us to break anything that uses an internal function whose name begins with underscore, but people more deeply involved in this part of the system may have ideas to help supporting even such users. Nathan Bullock <nathanbullock@gmail.com> writes: > I have for a number of years had the following in my .bashrc > > alias br="git branch" > complete -F _git_branch br > > As well as similar commands for co and log. > > Recently though this broke, now when I type something like "br > mas<command completion>" it will occasionally complain with messages > like: > bash: [: 1: unary operator expected > > From digging through the source it looks like this was broken back in > April. (The commit is show at the bottom of this email.) > > So my questions are: > 1. Is it reasonable for things like _git_branch to work as a > standalone autocompletion function instead of having to go through > _git? I certainly like it to work as a standalone function. I also use > it to add autocompletion to other bash scripts that I use frequently. > > 2. If I add code that verifies that the variable cword exists at the > start of these functions and only if not call something like > _get_comp_words_by_ref -n =: cur words cword prev. Would that be > reasonable? I think this should address the performance concerns that > caused these to be removed in the first place, but it may make the > code uglier. > > I have already added wrapper functions in my bashrc so that this is no > longer a problem for me, but there may be other people who start > hitting this as well once they start using newer versions of git. > > Nathan > > > commit da4902a73017ad82b9926d03101ec69a2802d1e7 > Author: SZEDER Gábor <szeder@ira.uka.de> > Date: Thu Apr 28 18:01:52 2011 +0200 > > completion: remove unnecessary _get_comp_words_by_ref() invocations > > In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work > with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref() > to access completion-related variables. That was large change, and to > make it easily reviewable, we invoked _get_comp_words_by_ref() in each > completion function and systematically replaced every occurance of > bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with > variables set by _get_comp_words_by_ref(). > > This has the downside that _get_comp_words_by_ref() is invoked several > times during a single completion. The worst offender is perhaps 'git > log mas<TAB>': during the completion of 'master' > _get_comp_words_by_ref() is invoked no less than six times. > > However, the variables $prev, $cword, and $words provided by > _get_comp_words_by_ref() are not modified in any of the completion > functions, and the previous commit ensures that the $cur variable is > not modified as well. This makes it possible to invoke > _get_comp_words_by_ref() to get those variables only once in our > toplevel completion functions _git() and _gitk(), and all other > completion functions will inherit them. > > Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> > Signed-off-by: Junio C Hamano <gitster@pobox.com> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Autocompletion - commands no longer work as stand alone 2012-01-20 19:24 ` Junio C Hamano @ 2012-01-20 19:33 ` Nathan Bullock 2012-01-24 23:26 ` SZEDER Gábor 1 sibling, 0 replies; 6+ messages in thread From: Nathan Bullock @ 2012-01-20 19:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: SZEDER Gábor, git So just as a comment on the use of underscores. The actual main auto complete function, _git, also starts with an underscore. From looking at the code it looked like the double underscore functions were the internal ones. 2012/1/20 Junio C Hamano <gitster@pobox.com>: > Pinging Szeder. I personally do not think it is a crime for us to break > anything that uses an internal function whose name begins with underscore, > but people more deeply involved in this part of the system may have ideas > to help supporting even such users. > > Nathan Bullock <nathanbullock@gmail.com> writes: > >> I have for a number of years had the following in my .bashrc >> >> alias br="git branch" >> complete -F _git_branch br >> >> As well as similar commands for co and log. >> >> Recently though this broke, now when I type something like "br >> mas<command completion>" it will occasionally complain with messages >> like: >> bash: [: 1: unary operator expected >> >> From digging through the source it looks like this was broken back in >> April. (The commit is show at the bottom of this email.) >> >> So my questions are: >> 1. Is it reasonable for things like _git_branch to work as a >> standalone autocompletion function instead of having to go through >> _git? I certainly like it to work as a standalone function. I also use >> it to add autocompletion to other bash scripts that I use frequently. >> >> 2. If I add code that verifies that the variable cword exists at the >> start of these functions and only if not call something like >> _get_comp_words_by_ref -n =: cur words cword prev. Would that be >> reasonable? I think this should address the performance concerns that >> caused these to be removed in the first place, but it may make the >> code uglier. >> >> I have already added wrapper functions in my bashrc so that this is no >> longer a problem for me, but there may be other people who start >> hitting this as well once they start using newer versions of git. >> >> Nathan >> >> >> commit da4902a73017ad82b9926d03101ec69a2802d1e7 >> Author: SZEDER Gábor <szeder@ira.uka.de> >> Date: Thu Apr 28 18:01:52 2011 +0200 >> >> completion: remove unnecessary _get_comp_words_by_ref() invocations >> >> In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work >> with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref() >> to access completion-related variables. That was large change, and to >> make it easily reviewable, we invoked _get_comp_words_by_ref() in each >> completion function and systematically replaced every occurance of >> bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with >> variables set by _get_comp_words_by_ref(). >> >> This has the downside that _get_comp_words_by_ref() is invoked several >> times during a single completion. The worst offender is perhaps 'git >> log mas<TAB>': during the completion of 'master' >> _get_comp_words_by_ref() is invoked no less than six times. >> >> However, the variables $prev, $cword, and $words provided by >> _get_comp_words_by_ref() are not modified in any of the completion >> functions, and the previous commit ensures that the $cur variable is >> not modified as well. This makes it possible to invoke >> _get_comp_words_by_ref() to get those variables only once in our >> toplevel completion functions _git() and _gitk(), and all other >> completion functions will inherit them. >> >> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> >> Signed-off-by: Junio C Hamano <gitster@pobox.com> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Autocompletion - commands no longer work as stand alone 2012-01-20 19:24 ` Junio C Hamano 2012-01-20 19:33 ` Nathan Bullock @ 2012-01-24 23:26 ` SZEDER Gábor 2012-01-30 12:00 ` Nathan Bullock 1 sibling, 1 reply; 6+ messages in thread From: SZEDER Gábor @ 2012-01-24 23:26 UTC (permalink / raw) To: Nathan Bullock; +Cc: Junio C Hamano, git Hi, > Nathan Bullock <nathanbullock@gmail.com> writes: > > > I have for a number of years had the following in my .bashrc > > > > alias br="git branch" > > complete -F _git_branch br > > > > As well as similar commands for co and log. > > > > Recently though this broke, now when I type something like "br > > mas<command completion>" it will occasionally complain with messages > > like: > > bash: [: 1: unary operator expected > > > > From digging through the source it looks like this was broken back in > > April. (The commit is show at the bottom of this email.) > > > > So my questions are: > > 1. Is it reasonable for things like _git_branch to work as a > > standalone autocompletion function instead of having to go through > > _git? I certainly like it to work as a standalone function. I also use > > it to add autocompletion to other bash scripts that I use frequently. > > > > 2. If I add code that verifies that the variable cword exists at the > > start of these functions and only if not call something like > > _get_comp_words_by_ref -n =: cur words cword prev. Would that be > > reasonable? That would be too fragile, it will break if $cword is set in the environment from which you invoke _git_<cmd>() completion functions directly (i.e. not though _git()). > > I think this should address the performance concerns that > > caused these to be removed in the first place, but it may make the > > code uglier. Actually it was not a performance problem, but a cleanup in a patch series to fix a zsh-related bug. Without this cleanup the bugfix would have been much more intrusive. http://thread.gmane.org/gmane.comp.version-control.git/172142/focus=172369 > > I have already added wrapper functions in my bashrc so that this is no > > longer a problem for me, but there may be other people who start > > hitting this as well once they start using newer versions of git. This issue was reported earlier, so it seems there are people who would like to use it. But getting $cur, $cword, etc. variables right in _git_<cmd>() completion functions is just part of the problem, there are other issues, as mentioned in the previous thread: http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232 Unfortunately, I couldn't come up with a solution yet that doesn't introduce too much code churn and doesn't cause yet another inconsistency between bash and zsh. I also haven't looked whether there are other issues similar to that with _git_fetch() mentioned on the above link. Best, Gábor ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Autocompletion - commands no longer work as stand alone 2012-01-24 23:26 ` SZEDER Gábor @ 2012-01-30 12:00 ` Nathan Bullock 2012-01-30 18:14 ` Junio C Hamano 0 siblings, 1 reply; 6+ messages in thread From: Nathan Bullock @ 2012-01-30 12:00 UTC (permalink / raw) To: SZEDER Gábor; +Cc: Junio C Hamano, git 2012/1/24 SZEDER Gábor <szeder@ira.uka.de>: > Hi, > > >> Nathan Bullock <nathanbullock@gmail.com> writes: >> >> > I have for a number of years had the following in my .bashrc >> > >> > alias br="git branch" >> > complete -F _git_branch br >> > >> > As well as similar commands for co and log. >> > >> > Recently though this broke, now when I type something like "br >> > mas<command completion>" it will occasionally complain with messages >> > like: >> > bash: [: 1: unary operator expected >> > >> > From digging through the source it looks like this was broken back in >> > April. (The commit is show at the bottom of this email.) >> > >> > So my questions are: >> > 1. Is it reasonable for things like _git_branch to work as a >> > standalone autocompletion function instead of having to go through >> > _git? I certainly like it to work as a standalone function. I also use >> > it to add autocompletion to other bash scripts that I use frequently. >> > >> > 2. If I add code that verifies that the variable cword exists at the >> > start of these functions and only if not call something like >> > _get_comp_words_by_ref -n =: cur words cword prev. Would that be >> > reasonable? > > That would be too fragile, it will break if $cword is set in the > environment from which you invoke _git_<cmd>() completion functions > directly (i.e. not though _git()). > >> > I think this should address the performance concerns that >> > caused these to be removed in the first place, but it may make the >> > code uglier. > > Actually it was not a performance problem, but a cleanup in a patch > series to fix a zsh-related bug. Without this cleanup the bugfix > would have been much more intrusive. > > http://thread.gmane.org/gmane.comp.version-control.git/172142/focus=172369 > > >> > I have already added wrapper functions in my bashrc so that this is no >> > longer a problem for me, but there may be other people who start >> > hitting this as well once they start using newer versions of git. > > This issue was reported earlier, so it seems there are people who > would like to use it. But getting $cur, $cword, etc. variables right > in _git_<cmd>() completion functions is just part of the problem, > there are other issues, as mentioned in the previous thread: > > http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232 > > Unfortunately, I couldn't come up with a solution yet that doesn't > introduce too much code churn and doesn't cause yet another > inconsistency between bash and zsh. I also haven't looked whether > there are other issues similar to that with _git_fetch() mentioned on > the above link. At the end of this thread that you refer to, http://thread.gmane.org/gmane.comp.version-control.git/185184/focus=185232, there is a set of wrapper functions that look reasonably good for solving this problem. There was a question if those could be included in the main git code base. Do you know if that is likely to happen? Nathan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Autocompletion - commands no longer work as stand alone 2012-01-30 12:00 ` Nathan Bullock @ 2012-01-30 18:14 ` Junio C Hamano 0 siblings, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2012-01-30 18:14 UTC (permalink / raw) To: Nathan Bullock; +Cc: SZEDER Gábor, git Nathan Bullock <nathanbullock@gmail.com> writes: > ... There was a question if those could be included > in the main git code base. Do you know if that is likely to happen? It entirely is up to the author of the patch. "I have this random code on Github so people can just copy and paste it in their .bashrc" may be a good starting point to give hint to people who are interested to come up with a good patch with a use example on a handful of comment lines and a readable commit log message. I didn't see it happen in that thread, so perhaps nobody was interested back then. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-30 18:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CAPx=Vfp_HVr5W1fFic_1k+JsKr2RAKd-RK=VkfSgo7qkb5GsAw@mail.gmail.com>
2012-01-20 16:32 ` Autocompletion - commands no longer work as stand alone Nathan Bullock
2012-01-20 19:24 ` Junio C Hamano
2012-01-20 19:33 ` Nathan Bullock
2012-01-24 23:26 ` SZEDER Gábor
2012-01-30 12:00 ` Nathan Bullock
2012-01-30 18:14 ` Junio C Hamano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).