git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Autocompletion - commands no longer work as stand alone

From
SZEDER Gábor <szeder@ira.uka.de>
Date
Jan 24, 2012, 23:26 UTC
Message-ID
<20120124232658.GD2256@goldbirke>
In-Reply-To
<7vwr8mdvo8.fsf@alter.siamese.dyndns.org>
Hi,
Show 27 quoted lines
> 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

Previous: Nathan BullockNext: Nathan Bullock
Message 4 of 6 in “Autocompletion - commands no longer work as stand alone”
  1. Nathan BullockJan 20, 2012
  2. Junio C HamanoJan 20, 2012
  3. Nathan BullockJan 20, 2012
  4. SZEDER GáborJan 24, 2012
  5. Nathan BullockJan 30, 2012
  6. Junio C HamanoJan 30, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.