Git-add completion should show full file paths

Git-add completion should show full file paths

[Amyn Bennamane]

Hi all,

Daniel Shahaf kindly reviewed this pull request of mine:
https://github.com/zsh-users/zsh/pull/55.

The code turned out to be wrong but I'll summarise what would be nice
to have here:

If you have multiple files buried under subfolders, the current
completions only show top level folders.

Example, if you have a folder `src` containing files `bar1` and `bar2`:

```
% git add <TAB>
 -- modified file --
src
 -- untracked file --
foo  src
```

What I want is:

```
% git add <TAB>
 -- Unstaged --
foo       src/bar1  src/bar2
```

Quoting Daniel:

I see that offering `src/bar1` and `src/bar2` right off the bat can be
useful. However, I'm not sure how best to implement it. I wonder if it
would make sense to teach `_multi_parts` some sort of
`dont-try-to-be-smart-just-offer-all-matches-right-off-the-bat`
zstyle. This would solve the problem for every use of `_multi_parts`.

End quote.

Can anyone here comment on the above idea and/or suggest a way to
implement this?

Thank you in advance.


-- 
Amyn Bennamane

Re: Git-add completion should show full file paths

[dana]

On 26 Apr 2020, at 17:57, Amyn Bennamane <amynbe@gmail.com> wrote:
> Can anyone here comment on the above idea and/or suggest a way to
> implement this?

I've often wished it worked the way you suggested, but not always.

If i have two unstaged files like a/b/c/d/e/foo and a/b/c/d/f/bar, then having
it complete the full paths is useful, because there are only a few and i don't
want to repeatedly tab (or write out the correct pattern / abbreviated path)
to recurse into those directories.

But if i have 20 unstaged files that are all under a/b/c/d/e, i would rather
the completion assist me with adding that entire directory than show me a
million giant file paths.

I guess what Daniel is suggesting is basically an on/off switch for
_multi_parts's intended function, and you can turn it off for git if you want.
That'd work fine as long as you don't expect to run into the latter case very
often.

I wonder if it could be more intelligent though — maybe this style could take
an integer that acts as a threshold for whether it should work the normal way
or the 'dumb' way? Like if there are more than x files with the same prefix or
whatever. Not sure how you'd calculate it, but something like that.

Also, whether it's like that or just a boolean, it seems like you'd also need
to consider how recursive completion should work, or if it should, in the
'dumb' case. I think users are accustomed to being able to expand like
f/b/b<TAB> -> foo/bar/baz with file paths, and it would be confusing if that
only worked some of the time... though they would have to go out of their way
to set it like that, so idk

dana

Re: Git-add completion should show full file paths

[Bart Schaefer]

On Mon, Apr 27, 2020 at 12:24 PM dana <dana@dana.is> wrote:
>
> I guess what Daniel is suggesting is basically an on/off switch for
> _multi_parts's intended function, and you can turn it off for git if you want.

That seems a bit off the mark to me?  Wouldn't the right approach here
be to call something OTHER THAN _multi_parts if you don't want the
strings treated as having multiple parts?

More specifically, _git_files already has the whole list in the $files
array, so instead of running
  _wanted $tag expl $description _multi_parts -f $compadd_opts - / files
it could instead just do
  _wanted $tag expl $description compadd -f $compadd_opts $files
(probably with some cleanup of subtleties I've ignored).

> I wonder if it could be more intelligent though — maybe this style could take
> an integer that acts as a threshold for whether it should work the normal way
> or the 'dumb' way? Like if there are more than x files with the same prefix or
> whatever. Not sure how you'd calculate it, but something like that.

That could be put into a wrapper function around the two possible
_wanted calls above, if it were desirable to have it somewhere other
than in _git_files.  Things do get a bit tricky if you're not passing
the -f option to compadd; you need something, other than the file
system, to which to compare the original strings.

> Also, whether it's like that or just a boolean, it seems like you'd also need
> to consider how recursive completion should work, or if it should, in the
> 'dumb' case. I think users are accustomed to being able to expand like
> f/b/b<TAB> -> foo/bar/baz with file paths

I think you'd just need to fall back on "_wanted _multi_parts" when
"_wanted compadd" didn't add anything.

Re: Git-add completion should show full file paths

[Daniel Shahaf]

Bart Schaefer wrote on Mon, 27 Apr 2020 21:35 -0700:
> On Mon, Apr 27, 2020 at 12:24 PM dana <dana@dana.is> wrote:
> >
> > I guess what Daniel is suggesting is basically an on/off switch for
> > _multi_parts's intended function, and you can turn it off for git if you want.  
> 
> That seems a bit off the mark to me?  Wouldn't the right approach here
> be to call something OTHER THAN _multi_parts if you don't want the
> strings treated as having multiple parts?
> 

That'd force everyone to use the "list of all files" semantics.
However, I assumed that _multi_parts was used there for a reason (and
dana's input confirms _multi_parts semantics are desired in some
use-cases at least).  Therefore, I looked for a way to make the
behaviour configurable.

> More specifically, _git_files already has the whole list in the $files
> array, so instead of running
>   _wanted $tag expl $description _multi_parts -f $compadd_opts - / files
> it could instead just do
>   _wanted $tag expl $description compadd -f $compadd_opts $files
> (probably with some cleanup of subtleties I've ignored).

(e.g., s/$files/-a files/ in case filenames start with a minus)

> > I wonder if it could be more intelligent though — maybe this style could take
> > an integer that acts as a threshold for whether it should work the normal way
> > or the 'dumb' way? Like if there are more than x files with the same prefix or
> > whatever. Not sure how you'd calculate it, but something like that.  
> 
> That could be put into a wrapper function around the two possible
> _wanted calls above, if it were desirable to have it somewhere other
> than in _git_files.  Things do get a bit tricky if you're not passing
> the -f option to compadd; you need something, other than the file
> system, to which to compare the original strings.
> 

Seems like this would also allow people to use «zstyle -e» to choose
between the two behaviours dynamically, which could be used to
implement the "if there are more than x files" semantics dana described.

Cheers,

Daniel

Re: Git-add completion should show full file paths

[Bart Schaefer]

On Tue, Apr 28, 2020 at 11:01 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Bart Schaefer wrote on Mon, 27 Apr 2020 21:35 -0700:
> > ... call something OTHER THAN _multi_parts if you don't want the
> > strings treated as having multiple parts?
>
> That'd force everyone to use the "list of all files" semantics.

I don't mean unconditionally call something else.  I mean, check a
style and either call _multi_parts, or not.

> > That could be put into a wrapper function around the two possible
> > _wanted calls above, if it were desirable to have it somewhere other
> > than in _git_files.
>
> Seems like this would also allow people to use «zstyle -e» to choose
> between the two behaviours dynamically, which could be used to
> implement the "if there are more than x files" semantics dana described.

Yes, or the algorithm for that could be built into the wrapper and
activated by a style value.

Re: Git-add completion should show full file paths

[Daniel Shahaf]

Bart Schaefer wrote on Tue, 28 Apr 2020 20:42 -0700:
> On Tue, Apr 28, 2020 at 11:01 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Bart Schaefer wrote on Mon, 27 Apr 2020 21:35 -0700:  
> > > ... call something OTHER THAN _multi_parts if you don't want the
> > > strings treated as having multiple parts?  
> >
> > That'd force everyone to use the "list of all files" semantics.  
> 
> I don't mean unconditionally call something else.  I mean, check a
> style and either call _multi_parts, or not.

I assumed making _multi_parts opt-outable would be useful for all uses
thereof, not just for the _git-files one.

> > > That could be put into a wrapper function around the two possible
> > > _wanted calls above, if it were desirable to have it somewhere other
> > > than in _git_files.  
> >
> > Seems like this would also allow people to use «zstyle -e» to choose
> > between the two behaviours dynamically, which could be used to
> > implement the "if there are more than x files" semantics dana described.  
> 
> Yes, or the algorithm for that could be built into the wrapper and
> activated by a style value.

Sure.  Personally, though, I'd recommend to test-drive potential styles
using «zstyle -e» (or other means) before adding them to _git as
first-class supported APIs.

Cheers,

Daniel