zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: dana <dana@dana.is>, Amyn Bennamane <amynbe@gmail.com>,
	"zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: Git-add completion should show full file paths
Date: Tue, 28 Apr 2020 18:01:18 +0000	[thread overview]
Message-ID: <20200428180118.26e97826@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <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@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

  reply	other threads:[~2020-04-28 18:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-26 22:57 Amyn Bennamane
2020-04-27 19:25 ` dana
2020-04-28  4:35   ` Bart Schaefer
2020-04-28 18:01     ` Daniel Shahaf [this message]
2020-04-29  3:42       ` Bart Schaefer
2020-04-29  9:21         ` Daniel Shahaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200428180118.26e97826@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=amynbe@gmail.com \
    --cc=dana@dana.is \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).