Re: [PATCH/RFC] completion: complete refs in multiple steps
- Date: Tue, 29 Jan 2019 07:43:45 +0700
- From: Duy Nguyen <pclouds@xxxxxxxxx>
- Subject: Re: [PATCH/RFC] completion: complete refs in multiple steps
On Tue, Jan 29, 2019 at 12:27 AM Jeff King <peff@xxxxxxxx> 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
> > '%(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)'
> 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
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"
> 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.