Zsh Mailing List Archive
Messages sorted by:
Re: Git-add completion should show full file paths
- X-seq: zsh-workers 45736
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: Git-add completion should show full file paths
- Date: Tue, 28 Apr 2020 18:01:18 +0000
- Cc: dana <dana@xxxxxxx>, Amyn Bennamane <amynbe@xxxxxxxxx>, "zsh-workers@xxxxxxx" <zsh-workers@xxxxxxx>
- In-reply-to: <CAH+w=7bJT2C6u+4q7Q_+eqyJTqFhEsNmzHHOt2BxzEAf6y+9=Q@mail.gmail.com>
- List-help: <mailto:firstname.lastname@example.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:email@example.com>
- List-unsubscribe: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CAJ=fZjNLqQi3oLvzf3pd9j7OVKNMS3i_759dFrNWPkOM7yYKug@mail.gmail.com> <585FABCB-9B6A-47F8-886E-B24E359F8F51@dana.is> <CAH+w=7bJT2C6u+4q7Q_+eqyJTqFhEsNmzHHOt2BxzEAf6y+9=Q@mail.gmail.com>
Bart Schaefer wrote on Mon, 27 Apr 2020 21:35 -0700:
> On Mon, Apr 27, 2020 at 12:24 PM dana <dana@xxxxxxx> 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
> 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.
Messages sorted by: