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

Re: Autocompletion - commands no longer work as stand alone

From
Nathan Bullock <nathanbullock@gmail.com>
Date
Jan 30, 2012, 12:00 UTC
Message-ID
<CAPx=Vfo20wWKOTeeKc=WM9dOpm85enTZHJsTnBL5uh8v0r6PRQ@mail.gmail.com>
In-Reply-To
<20120124232658.GD2256@goldbirke>
2012/1/24 SZEDER Gábor <szeder@ira.uka.de>:
Show 62 quoted lines
> 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
Previous: SZEDER GáborNext: Junio C Hamano
Message 5 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.