Re: PATCH: Fall back to file completion if nothing else works

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Johan Sundström wrote:
> On Mon, Jun 27, 2011 at 14:55, Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> wrote:
>
>> Some people have for third party add-ons to git. `annex' is one such
>> add-on. Currently "git annex add <tab>" does nothing, because there is
>> no special subcommand handling function.
>>
>> _git should really fallback to file name completion in such cases. This
>> patch does exactly that.
>>
>
> -0. As I read this, you're proposing going from 0 (or close to it?) to an
> unbounded number of completion false positives.
>
> Before such a patch, you can be sure that git <anything> <tab> will complete
> something that is legal in this spot: a tag or branch name, for instance, a
> file which has not yet been added to the index, a flag for this command, et
> cetera.
>
> After it, one can never know whether zsh completed a filename because that
> particular filename was legal in this context, or just because it didn't
> know how to complete something in the given context – the completion could
> be super smart, but it wouldn't be possible to tell, since you can't know if
> a completion was legal without knowing git inside and out, or from running
> the command line.

What? Non sense.

I don't know how you understood the code, but

  zsh% git an-existing-known-subcommand <tab>

will *never* run into this fall back and complete file names, because
the subcommand completion function for `an-existing-known-subcommand'
will know what to do. The *only* thing this does is to fall back to file
name completion when _git doesn't know the subcommand in question.

Doing noting in that spot is entirely useless. And that's what's
happening with the current code.

Also, the old _git did fall back to file completion, too, after
zsh-workers-28411 <http://www.zsh.org/mla/workers/2010/msg00855.html>,
because offering file names when you don't know any better is vastly
more useful than just sitting on your hands doing nothing.

I'm pretty sure changing this behaviour was an unintended oversight when
Nikolai rewrote `_git'.


>> I'm wondering how we should handle third party add ons to commands. _git
>> used provide the `user-commands' style to do stuff like this:
>>
>>    % zstyle ':completion:*:*:git:*' user-commands foo:'description for foo'
>>
>> You could even define `_git-foo()' to have special handling.
>>
>
> I think that sounds like a better way to enable the behaviour you seek, for
> people that specifically want it.

No, it's not.  The behaviour I really want is for _git to accept real
completion add ons. The problem with the `user-commands' commands style
is, that add-ons can't really use it because they will never know which
style to add their description to.

You can already defined `_git-foo()' and it'll be picked up as a
sub-command completion. So the "git foo <tab>" situation would be
solvable. You'd have to manually load the _git-foo completion file
currently or put #autoload into it. I think _git should handle loading
of _git-* files itself so add-ons just had to drop their completion
somewhere into $fpath.

Then _git could register the command name, too and "git fo<tab>" would
suggest `foo' as well. That way we could also drop my "use `foo' from
git-foo binaries from $path" path.


As for `user-commands': It *was* in the old _git. And I know people who
use it. Throwing away existing functionality without good reason or
telling anybody is just bad behaviour.

Though, I am pretty sure this - again - was just an oversight when
Nikolai rewrote `_git', which was a quite the task on to pull off on his
own. Otherwise he would have removed the comment on top of _git, too.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925