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 14619 invoked from network); 29 Apr 2020 03:43:13 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with UTF8ESMTPZ; 29 Apr 2020 03:43:13 -0000 Received: (qmail 1425 invoked by alias); 29 Apr 2020 03:43:03 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45741 Received: (qmail 333 invoked by uid 1010); 29 Apr 2020 03:43:03 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi1-f169.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25793. spamassassin: 3.4.4. Clear:RC:0(209.85.167.169):SA:0(-1.9/5.0):. Processed in 2.127923 secs); 29 Apr 2020 03:43:03 -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.167.169 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=hmqqRZghRo/ZILinBdOIkDya6+/a8MpDRZXTtw2UXm8=; b=QlafYNi00vSP5iRsk2RElRvApMDxYM7/mPdUKvms+mLdR8v27TEZCe7K09g8PDkZZt 45DJ/GnJ1sYDY2mvAt/iztuTkDKE2Z7INHrGl4UnECOY+HXNfxvGWsdxvJm+qdHKxpdz b97TX+eTwXBGHlj4BT50DKiCtKYoqecoT6CM0i9zlB8N/Zo0EPqLEGIm0rKe+Qkg10zV XILELZhxW91P8CkEkVj+xntMS3blpRp/osxEA8dDeBOv0CxjYB/ck6iloX1lczcwnnIG c+yum/xJxj30gfovqq2roOQsrCZYRLiBpRCz4NWn3vwvr+DprtSh9NK8UgsBvPK9QHkI PoRw== X-Gm-Message-State: AGi0Pub7a5QG8y93/a1723zjOYKn6KInmWfRO2yyoet4tYTCoxsWl04D +ZfCY/oy8jLrAidMhdztDq6S2p5HAQQ/EytDKAgfeiiU2FM= X-Google-Smtp-Source: APiQypIISbNbT+haWI+ig/xEpGEXknSA7s6tmA4XiwoaVp+e3DepPHjTGExSVXA2xHFMs2Phr4ASIORtOg0W+z4Km5I= X-Received: by 2002:aca:d684:: with SMTP id n126mr376585oig.173.1588131747816; Tue, 28 Apr 2020 20:42:27 -0700 (PDT) MIME-Version: 1.0 References: <585FABCB-9B6A-47F8-886E-B24E359F8F51@dana.is> <20200428180118.26e97826@tarpaulin.shahaf.local2> In-Reply-To: <20200428180118.26e97826@tarpaulin.shahaf.local2> From: Bart Schaefer Date: Tue, 28 Apr 2020 20:42:16 -0700 Message-ID: Subject: Re: Git-add completion should show full file paths To: Daniel Shahaf Cc: dana , Amyn Bennamane , "zsh-workers@zsh.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 28, 2020 at 11:01 AM Daniel Shahaf wro= te: > > 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 =C2=ABzstyle -e=C2=BB to c= hoose > 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.