Re: Calling all bash completion experts..

[Shawn Pearce <spearce@spearce.org>]

Linus Torvalds <torvalds@osdl.org> wrote:
> So I do "git repa<tab>" and get "git repack", which is fine, but I really 
> _wanted_ to get "git repack " (with the space at the end), since I've now 
> got a unique command, and that's the normal completion behaviour (ie I 
> want it to act the same way that "git-repa<tab>" would have acted).
[snip]
> Now, without knowing the completion syntax, I assume it's the "-o nospace" 
> things in the completion file. So I'm wondering _why_ that "nospace" is 
> there, and whether this could be fixed?

Yes, its the "-o nospace".

I added the nospace option because of the completion for fetch/push,
cat-file, diff-tree and ls-tree.

The problem is the file completion for e.g. cat-file.  We don't
want a space added after we complete a directory name, so you can
complete further, e.g.:

  git cat-file -p ma<tab>con<tab>comp<tab>git-com<tab>

gives us:

  git cat-file -p master:contrib/completion/git-completion.sh

but if I omitted the "-o nospace" then we would instead need:

  git cat-file ma<tab><bs>con<tab><bs>comp<tab><bs>git-com<tab>

as each successive <tab> would add a trailing space that you would need
to remove before you can complete again.

So as a user I decided that adding the space myself was less
annoying then needing to delete the space during completion down
through a tree.  But perhaps that was wrong.

I did try to inject the space myself in the completion code when
I knew something was unique, but bash didn't like that (it tossed
the space).

To be honest, I'm not really sure how to fix it.

One option would be to perform a `ls-tree -r` through whatever part
of the path we have now and offer up EVERYTHING in the tree as a
possible completion, but that is insane as it will take a little
while to generate and on a large tree (e.g. the Linux kernel) you
will get a large number of proposed completions back which aren't
really relevant.

--