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

[Johan Sundström <oyasumi@xxxxxxxxx>]

On Mon, Jun 27, 2011 at 22:17, Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> wrote:

> > -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.
>

I didn't, and that is a bit less damaging than what I understood it for.

Anyway, my -0 doesn't carry much weight here; it is just opinion and my
reasoning behind it. I personally prefer that in cases zsh completion
doesn't know what to complete, it won't try something that might, or might
not, be semantically valid for the command line.

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

I disagree. It tells me "when _git doesn't know the subcommand in question"
(so I could fix it to do the right thing, should I care to), and it would
never fill in something which might be wrong there instead of engaging a
blind, "best-effort" auto pilot.

This is one of those preference things where a behaviour somebody (your or
me) prefers isn't right or wrong, but where taste just differs among people.

In the unlikely event this was a heated topic among the majority of list
lurkers, and we saw a storm -1 chime-ins and another smaller trickle or
larger still mass of +1:s, the majority vote might not be a good thing to
implement. I think that's what zsh's whole configurable completion system is
all about, at heart; not implementing one size fits all wholesale behaviour.

>> 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.


Ah, I thought that was where you were going. This sounds useful to me, too.

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.
>

I think this kind of completion plugin plugins can benefit more than git, as
other commands (like npm and [home]brew) are using command line
styles similar to git's (rpm, dpkg, and probably other package managers do,
too, even though I guess most don't have as much user extensibility).

Best,

-- 
 / Johan Sundström, http://ecmanaut.blogspot.com/