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
next 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).