From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2
Received: (qmail 14338 invoked from network); 28 Apr 2020 04:36:35 -0000
Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2)
  by inbox.vuxu.org with UTF8ESMTPZ; 28 Apr 2020 04:36:35 -0000
Received: (qmail 3793 invoked by alias); 28 Apr 2020 04:36:17 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
List-Unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
X-Seq: 45733
Received: (qmail 14459 invoked by uid 1010); 28 Apr 2020 04:36:17 -0000
X-Qmail-Scanner-Diagnostics: from mail-oo1-f66.google.com by f.primenet.com.au (envelope-from <schaefer@brasslantern.com>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.102.2/25793. spamassassin: 3.4.4.  
 Clear:RC:0(209.85.161.66):SA:0(-1.9/5.0):. 
 Processed in 2.806374 secs); 28 Apr 2020 04:36:17 -0000
X-Envelope-From: schaefer@brasslantern.com
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.161.66 as permitted sender)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc:content-transfer-encoding;
        bh=eqVPeUryRz1GRMAzLOLH3z2I12+cJhBbNxYw9yFT2EA=;
        b=Y6Oryr6sDU59hBjwwtqLQja94Q0lugxQEckZfUcsBud76YjOLA63bbdrHAKglAJuCC
         KI8zRdK2SbUxk9VY4tyGKNFj3eiTDawCi+ybaZccDQb1wkU2QRjhRQbMrtBaJBV5/R9R
         928ypJt0DC6TDoxijnDZkmh0Jm/rHRy3QbYHL/vSXCcOBWJdMLyAuxs26BR1r/EzzUqk
         of0npoGie/u7JsbSvK7qoOkhxkis6MAfN1tLES9QDMN5tIdV1EXvJo5cvLjpnboEWzYI
         KBZkHX9qMnowLmnoELPB+WLGByRzmwyPFm/2QbKVUHO5rtNWWw1nDeAhvSqisAq8MyWI
         r/Dg==
X-Gm-Message-State: AGi0PuaNxt/qnLqhc7lQYW9NBZ/kV2xI0iaGARAASJes5LKk2X603O/H
	1Gxv7X3UMPeu1tCIbqlPJqEp1eIEzX3eW1TbbHDk7w==
X-Google-Smtp-Source: APiQypJb2fJA3x4/yial1DGKcx3wO/8N+1bIhlAtlfR4zbsas4hINxroxuhnqRKDPSHRSp73ZhPv483c6/I4NeNV7YQ=
X-Received: by 2002:a4a:accf:: with SMTP id c15mr21293004oon.29.1588048539470;
 Mon, 27 Apr 2020 21:35:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAJ=fZjNLqQi3oLvzf3pd9j7OVKNMS3i_759dFrNWPkOM7yYKug@mail.gmail.com>
 <585FABCB-9B6A-47F8-886E-B24E359F8F51@dana.is>
In-Reply-To: <585FABCB-9B6A-47F8-886E-B24E359F8F51@dana.is>
From: Bart Schaefer <schaefer@brasslantern.com>
Date: Mon, 27 Apr 2020 21:35:28 -0700
Message-ID: <CAH+w=7bJT2C6u+4q7Q_+eqyJTqFhEsNmzHHOt2BxzEAf6y+9=Q@mail.gmail.com>
Subject: Re: Git-add completion should show full file paths
To: dana <dana@dana.is>
Cc: Amyn Bennamane <amynbe@gmail.com>, "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 =E2=80=94 maybe this styl=
e 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 pref=
ix 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.