Autocompletion - commands no longer work as stand alone

Autocompletion - commands no longer work as stand alone

[Nathan Bullock]

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>

Re: Autocompletion - commands no longer work as stand alone

[Junio C Hamano]

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>

Re: Autocompletion - commands no longer work as stand alone

[Nathan Bullock]

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>

Re: Autocompletion - commands no longer work as stand alone

[SZEDER Gábor]

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

Re: Autocompletion - commands no longer work as stand alone

[Nathan Bullock]

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

Re: Autocompletion - commands no longer work as stand alone

[Junio C Hamano]

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.