Re: Autocompletion - commands no longer work as stand alone

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

 



Hi,


> 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?

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

--
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]