Re: broken bash completion

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 5, 2012, 13:11 UTC
Message-ID: <CAMP44s0q_zeVwzhgeda1=9+Psjr5PaO1QtHT1QC0RwyCpfd=rg@mail.gmail.com>
In-Reply-To: <20120505121319.GG2164@goldbirke>

On Sat, May 5, 2012 at 2:13 PM, SZEDER Gábor <szeder@ira.uka.de> wrote:

Show 9 quoted lines

> But you miss an important point here: users expect the completion to
> be pretty fast, because delays are quite noticeable and annoying while
> typing a command.  So there's a trade-off between correctness and
> usability.  Unfortunately, in the real world all that filtering costs
> a great deal, so git's completion script does that only if it can be
> done cheaply (e.g. 'git rebase --<TAB>' won't offer you '--abort' and
> '--continue' if you're not in the middle of an ongoing rebase).  And
> as pointed out above, something might be nonsense for a command, but
> still be useful for the user.

Completely agree with this.

The reason I started to use the bash completion in zsh is that the zsh completion goes for 100% correctness, that means 'git checkout <TAB>' took literally *minutes* in my machine on the Linux kernel repo. The zsh developers said that was OK, and my patch to solve the problem was not, because it would make the result less than 100% correct.

The whole point of completion is to avoid typing as much as possible, and if typing something is faster than doing the completion; the completion is pointless. It has to be fast.

Cheers.

-- 
Felipe Contreras