Re: [PATCH/RFC] completion: complete refs in multiple steps

[Duy Nguyen <pclouds@gmail.com>]

On Tue, Jan 29, 2019 at 12:27 AM Jeff King <peff@peff.net> wrote:
>
> On Mon, Jan 28, 2019 at 03:38:28PM +0100, SZEDER Gábor wrote:
>
> > > -   __gitcomp_direct "$(__git_refs "$remote" "$track" "$pfx" "$cur_" "$sfx")"
> > > +   __gitcomp_direct "$(__git_refs "$remote" "$track" "$pfx" "$cur_" "$sfx" | __git_collapse_refs "$cur_")"
> > >  }
> >
> > In general I think it would be much better to rely more on 'git
> > for-each-ref' to do the heavy lifting, extending it with new format
> > specifiers/options as necessary.
>
> FWIW, that was my first thought, too.

I was more concerned whether it's a good idea to begin with. But it
sounds like you two both think it's good otherwise would have
objected.

> > '%(refname:rstrip=-<N>)' already comes somewhat close to what we would
> > need for full ref completion (i.e. 'refs/b<TAB>' to complete
> > 'refs/bisec/bad'), we only have to figure out how many "ref path
> > components" to show based on the number of path components in the
> > current word to be completed.  Alas, it won't add the trailing '/' for
> > "ref directories".
>
> I think it also makes it hard to do one thing which (I think) people
> would want: if there is a single deep ref, complete the whole thing.
> E.g., given:
>
>   $ git for-each-ref --refname='%(refname)'
>   refs/heads/foo/bar
>   refs/heads/foo/baz
>   refs/heads/another/deep/one
>
> we'd ideally complete "fo" to "foo/" and "ano" to "another/deep/one",
> rather than making the user tab through each level.

Ah ha, like github sometimes show nested submodule paths. Just one
small modification, when doing "refs/heads/<tab>" I would just show

refs/heads/foo/
refs/heads/another/

not refs/heads/another/deep/one to save space. But when you do
"refs/heads/a<tab>" then you get "refs/heads/another/deep/one"
immediately.

> Doing that requires actually understanding that the refs are in a list,
> and not formatting each one independently. So I kind of wonder if it
> would be easier to simply have a completion mode in for-each-mode.

That also allows more complicated logic. I think sometimes completion
code gets it wrong (I think it's often the case with rev/path
ambiguation, but maybe dwim stuff too). And we already have all this
logic in C.
-- 
Duy