From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,MAILING_LIST_MULTI,MALFORMED_FREEMAIL,RCVD_IN_DNSWL_NONE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 15377 invoked from network); 2 Jun 2020 13:44:31 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 2 Jun 2020 13:44:31 -0000 Received: (qmail 12434 invoked by alias); 2 Jun 2020 13:44:17 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24892 Received: (qmail 12591 invoked by uid 1010); 2 Jun 2020 13:44:17 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25828. spamassassin: 3.4.4. Clear:RC:0(205.235.26.22):SA:0(-0.7/5.0):. Processed in 2.645524 secs); 02 Jun 2020 13:44:17 -0000 X-Envelope-From: SRS0=ZJoL=7P=yahoo.co.uk=okiddle@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at bounces.park01.gkg.net designates 205.235.26.22 as permitted sender) X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-YMail-OSG: q4LBcTkVM1mijxSQ8szOsSuQ0YUU8BbBi4OIEUIiumLSuSPXVBqe4__mgrpF2SO zEGDmLTH091DensLmxx_8StqasrnD4a42FjSxtmcVXiQzEAqj6KTF8o1OcgMi3DVM.nHVFXMRgdf 9Tyn4kaDbCRVxZBj3g887j2F4NTh7gJ.CMbi_q7tvdWx9cfO_4HJTtoD_R3Qt4f8J_VrkSgfDdNN 0sWbgVMSjcjvskAUklW8Hn8ovtB0Bp_0ivfMPVwDjy3vGtxQHK9LhzzDy6fKCY2uR_NN..C0OWF6 geXHYvAOOWHNycX1hdnzAAiUsxrxupNhNkqEyN53tIfc04OuzZP6lcxPJ4eQMWzG5_GUjGc070GK U..2TK3_MhjPMM6kNQJhT_PtQZxeY5IaAGjqNtPl30ZjW_hYpmgregs2qWzXTagbUlHAF7CTlJg2 8c29EENBhrjoQ3F7qstkjosopoBieAyxYBE25Dr8VB59uTh0Yyo8YS3hxSfAYq62cnjg5IJrFCqy 4ZerlLO.Mf3HJRCpYl8njrHwmIMo4Q4rYzhSmIlP4QnX7hqEJprE2QWI8OxuQa0WEUUIo6DDIOWk aLM1F.0EhST0NljhxBAuyjIvy8LAmEklool2P.LhyrKcVAMROb0o26dLana._Y.zwg3ikf7uPPas eRzZv6mVnAWqS4qWwxajoALU5Cj47OYNFz0UmMt3l_MaJlxBnrQsQSLQwx64_DQrdvysfOe_CVFF 1I.lK6.oXcvciySicGyWHm1b.cQ9okObCy2etJoHarfxf7AJJUSlBYnyXLxBKh60N8jEoI_fXPpn MeWzy1HbxIqS27TRBKKCI9wFD2XGpZby7eZNBVa7lM_YTJegA2heGNpykH5a4zRkdU92oq1.SXXc 7nCu9dFuPBCV70_U82VPcuHoZkm1Phm_qnWJw48iIXDneo6DfZP6M65MCmGVy4wNyFwiyaDIbal_ AUSqvuu.tHOh6D6BZzoAN.oeP_.sQoIvCQ2oK8Osjem.2pt.G1ecVsPes_lEisvclzfE48UMaYyr nF5L1ZOsfDurMFEFEyddc6F0CPD3xSvVr3YcPFrPaGq_kXdqISEx1kZ6i.IpFOronVz.no4Rro.h xFCqsjP0RuC39qMi1dctS.NRiZ0nQUCcPMpxlN3lUwRFXdsC.c52t2O1CvJ0qgQWiJ_6W7JFG2oh Wj_sVrvuU_wYY2RHT8adAibYYpsO5BWJGdvj7xnDOtQC.I1pZc3oyka8Mj73jpKk02yzoildNatK MxKCLUpgAX2bw1KPYO1V3jwEn8QkO0qShwHBDiwTZengg34jZfRzp6JOhC12qY4A7updYzCCdGEL qfvBau_cLSJ2XBms.IMjpbHICJYtV1ZpbIKeE2rsboZCoFavDq7hMcbln.2vYInkPzYaiicaQFXr 3pTreOPFQRWI- cc: Daniel Shahaf , Zsh Users In-reply-to: From: Oliver Kiddle References: <20200601080730.7d373c99@tarpaulin.shahaf.local2> To: Roman Perepelitsa Subject: Re: Completion introspection MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <5187.1591105405.1@hydra> Content-Transfer-Encoding: 8bit Date: Tue, 02 Jun 2020 15:43:25 +0200 Message-ID: <5188-1591105405.370946@cuHu.nL5d.Zy1a> X-Mailer: WebService/1.1.16037 hermes_yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.6) Roman Perepelitsa wrote: > Maybe there is another way? Perhaps it's possible to configure zsh > completion system so that all file completions are recursive? My tab > binding is actually also using fzf if there are multiple possible > completions, so if file completions were recursive, that would work. There is more than one possible approach to this depending on how you want it to work. There is a recursive-files style or you can approach it via the the file-patterns style. For a custom completion widget, the usual starting point is to use _generic, this creates one and binds it: zle -C recursive-files complete-word _generic bindkey '\ef' recursive-files Now you probably want to define a completer, if that's not covered by a generic style. _complete is a reasonable minimum but others (such as _approximate) may be useful. Or perhaps _files if you want to ignore completion or as a fallback if _complete fails. zstyle ':completion:recursive-files::::' completer _complete You can now try this style: zstyle ':completion:recursive-files:*' recursive-files '*' Or, try a different approach: zstyle ':completion:recursive-files:*' file-patterns \ '**/%p:globbed-files' '**/%p(#qD):hidden-globbed-files' '**/*(-.):all-files' zstyle ':completion:recursive-files:*' matcher 'r:/||[^/]=**' The matcher is what ensures that "two" on the command-line will match to "one/two". It'll also match "one/two/three" (I'd be interested if anyone knows of a way around that). You could go all-in and use 'b:=*' so that any substring will match. There may be cases where this doesn't work, especially where _files is somewhat bypassed such as for git completion. The recursive glob doesn't work well with how _path_files normally handles hidden files – hence the workaround of including it in file-patterns. Using menu-selection along with it's search feature gets closer to fzf. You'll need to load the complist module if you're not already doing that. Then we can force the use of a menu in the case of ambiguities. This is especially useful in cases where completion has determined that there are multiple possible insertion points to disambiguate a completion. zstyle ":completion:recursive-files:*:default" menu yes=1 select=0 search The search is not fuzzy and the list is not filtered and reordered to only give the matching entries but it has some advantages like using columns and much less space below the cursor. How valuable really is the fuzzy aspect of the fzf searching? The recursive-files style declares an array local inside a loop which causes it to be printed on subsequent loops. The _zstyle completer didn't complete it, and could perhaps complete a generated list of functions for the second part of the context. A patch for this is attached. Rather than using $PWD, shouldn't the recursive-files completer take notice of the -W and -P options plus and directory portion in $PREFIX. I'm not sure of the use case for limiting it by $PWD anyway. Oliver diff --git a/Completion/Unix/Type/_files b/Completion/Unix/Type/_files index 6adaa8154..4ddec1e12 100644 --- a/Completion/Unix/Type/_files +++ b/Completion/Unix/Type/_files @@ -1,6 +1,7 @@ #compdef -redirect-,-default-,-default- local -a match mbegin mend +local -a subtree local ret=1 # Look for glob qualifiers. This is duplicated from _path_files because @@ -110,7 +111,6 @@ for def in "$pats[@]"; do if _path_files -g "$pat" "$opts[@]" "$expl[@]"; then ret=0 elif [[ $PREFIX$SUFFIX != */* ]] && zstyle -a ":completion:${curcontext}:$tag" recursive-files rfiles; then - local subtree for rfile in $rfiles; do if [[ $PWD/ = ${~rfile} ]]; then if [[ -z $subtree ]]; then diff --git a/Completion/Zsh/Command/_zstyle b/Completion/Zsh/Command/_zstyle index 07b60605f..e9a5d800c 100644 --- a/Completion/Zsh/Command/_zstyle +++ b/Completion/Zsh/Command/_zstyle @@ -100,6 +100,7 @@ styles=( preserve-prefix c:preserve-prefix range c: recent-dirs-insert c:recent-dirs-insert + recursive-files c: regular c:bool rehash c:bool remote-access c:bool @@ -409,14 +410,15 @@ while (( $#state )); do ;; (function) - _wanted control-function expl 'control function' \ + _wanted control-functions expl 'control function' \ compadd predict-on all-matches ;; (functions) - _wanted comp-widget expl 'completion widget' \ - compadd $suf - all-matches complete-debug complete-tag \ - correct-word expand-word expand-alias-word history-words + _wanted comp-widgets expl 'completion widget' \ + compadd $suf -M 'r:|-=* r:|=*' - all-matches complete-debug complete-tag \ + correct-word expand-word expand-alias-word history-words \ + ${${${(M)${(f)"$(_call_program comp-widgets zle -l)"}:#*-C*}:#_*}/ -C*} ;; (user-host-port)