zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: approximate completion in _path_files and multipart completion
Date: Tue, 4 Jan 2000 13:21:46 +0100 (MET)	[thread overview]
Message-ID: <200001041221.NAA02772@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Andrej Borsenkow"'s message of Thu, 23 Dec 1999 19:57:15 +0300


Andrej Borsenkow wrote:

> I believe, we should more precisely define, what actually approximate completion
> means in case of _path_files.
> 
> I have /archive/sni/mr, approximate with 3 errors, and tried
> 
> /a/sin/mr<TAB>
> 
> keeping in mind the above path. To my surprise I got
> 
> bor@itsrm2% cd /a1/sin/mr
> a1/   u1@   var/
> /a/sin/mr
> 
> and this after *really* long time. No wonder - zsh had tried the whole
> filesystem three levels deep!
> 
> Looking at it I doubt, if any sensible way to mix both
> (_approximate+_path_files) exists. And, in any case, decision about how and
> where to use approximate matching should be made by final completion function.
> Only this one knows about the real meaning of ${PREIFX}${SUFFIX}.

The patch below tries to improve this for the three functions we have
that do the matching themselves and do some sort of multi-level
matching (or are there more of them nowadays?). It makes these
functions use approximate matching only if no matches for a certain
part can be generated without it.

But I agree, that all this is a bit, er... complicated. Should the
number of errors allowed be used for each part or for all parts
together and questions like this. If anyone has any ideas for possible 
improvements, I'd like to hear about them.

Bye
 Sven

diff -ru ../z.old/Completion/Core/_multi_parts Completion/Core/_multi_parts
--- ../z.old/Completion/Core/_multi_parts	Tue Jan  4 10:21:17 2000
+++ Completion/Core/_multi_parts	Tue Jan  4 11:52:50 2000
@@ -93,7 +93,11 @@
   else
     # No exact match, see how many strings match what's on the line.
 
-    compadd -O tmp1 - "${(@)matches%%${sep}*}"
+    builtin compadd -O tmp1 - "${(@)matches%%${sep}*}"
+
+    [[ $#tmp1 -eq 0 && -n "$_comp_correct" ]] &&
+      compadd -O tmp1 - "${(@)matches%%${sep}*}"
+
     tmp2=( "$tmp1[@]" )
     tmp1=( "$tmp2[@]" )
 
diff -ru ../z.old/Completion/Core/_path_files Completion/Core/_path_files
--- ../z.old/Completion/Core/_path_files	Tue Jan  4 10:21:17 2000
+++ Completion/Core/_path_files	Tue Jan  4 11:47:13 2000
@@ -256,8 +256,12 @@
     if [[ -n "$PREFIX$SUFFIX" ]]; then
       # See which of them match what's on the line.
 
-      tmp2=("$tmp1[@]")
-      compadd -D tmp1 "$ignore[@]" "$matcher[@]" - "${(@)tmp1:t}"
+      builtin compadd -D tmp1 "$ignore[@]" "$matcher[@]" - "${(@)tmp1:t}"
+
+      if [[ $#tmp1 -eq 0 && -n "$_comp_correct" ]]; then
+        tmp1=( "$tmp2[@]" )
+	compadd -D tmp1 "$ignore[@]" "$matcher[@]" - "${(@)tmp2:t}"
+      fi
 
       # If no file matches, save the expanded path and continue with
       # the outer loop.
diff -ru ../z.old/Completion/Core/_sep_parts Completion/Core/_sep_parts
--- ../z.old/Completion/Core/_sep_parts	Tue Jan  4 10:21:18 2000
+++ Completion/Core/_sep_parts	Tue Jan  4 11:57:10 2000
@@ -63,7 +63,9 @@
   # Get the matching array elements.
 
   PREFIX="${str%%${sep}*}"
-  compadd -O testarr - "${(@P)arr}"
+  builtin compadd -O testarr - "${(@P)arr}"
+  [[ $#testarr -eq 0 && -n "$_comp_correct" ]] &&
+    compadd -O testarr - "${(@P)arr}"
 
   # If there are no matches we give up. If there is more than one
   # match, this is the part we will complete.
@@ -91,7 +93,9 @@
   # No more separators, build the matches.
 
   PREFIX="$str"
-  compadd -O testarr - "${(@P)arr}"
+  builtin compadd -O testarr - "${(@P)arr}"
+  [[ $#testarr -eq 0 && -n "$_comp_correct" ]] &&
+    compadd -O testarr - "${(@P)arr}"
 fi
 
 [[ $#testarr -eq 0 || ${#testarr[1]} -eq 0 ]] && return 1
@@ -126,7 +130,9 @@
     arr=tmparr
   fi
 
-  compadd -O tmparr - "${(@P)arr}"
+  builtin compadd -O tmparr - "${(@P)arr}"
+  [[ $#tmparr -eq 0 && -n "$_comp_correct" ]] &&
+    compadd -O tmparr - "${(@P)arr}"
 
   suffixes=("${(@)^suffixes[@]}${1}${(@)^tmparr}")
 

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~2000-01-04 12:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-01-04 12:21 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-12-23 16:57 Andrej Borsenkow

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=200001041221.NAA02772@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.dk \
    /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).