Re: Autocompletion - commands no longer work as stand alone

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx>:
> 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@xxxxxxxxx> 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@xxxxxxxxxx>
>> 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@xxxxxxxxxx>
>>    Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]