match again

match again

[Andrej Borsenkow]

This does not work:

bor@itsrm2% patch -p0 --dry-run < /u/p/u/z/p/*/9441<TAB>

with settings

bor@itsrm2% compstyle -L
compstyle ':correct:' prompt 'correct to:'
compstyle ':approximate:' max-errors '3'
compstyle ':(correct|approximate):' max-errors '2' 'numeric'
compstyle '*:default' list-colors ''
compstyle '*:default' menu 'select=0'
compstyle '*:match' original 'yes'
compstyle '*:match' insert-unambiguous 'yes'
compstyle '*:paths' cursor 'yes'
compstyle '*:oldlist' list '_match'
compstyle ':*' verbose 'yes'
compstyle ':*' prefix-needed 'yes'
compstyle ':*' prefix-hidden 'no'
compstyle ':*' completer '_oldlist' '_complete' '_match'
compstyle ':*' tag-order 'arguments values' 'options' 'globbed-files'
'directories' 'all-files'

But this one does

bor@itsrm2% patch -p0 --dry-run <
/u2/pub/unix/zsh/patches/3.1.6-dev-16/<9440-><TAB>
bor@itsrm2% patch -p0 --dry-run < /u2/pub/unix/zsh/patches/3.1.6-dev-16/9441
9441   9442

/andrej

Re: match again

[Sven Wischnowsky]

Peter Stephenson wrote:

> It looks better, but is it enough to sort out all possible cases where you
> might want to use `:*:'?  Or are there even more cases where we might get
> into trouble with that?  I'm worried we could be barking up the wrong tree,
> and should, for example, fix the fields of the pattern to
> e.g. :completion:completer:command-or-context:arguments:tag (this may not
> even be complete) with unrequired fields set to null strings but retaining
> the colons, so you can always guarantee to pick out the appropriate
> bit (unless there are extra colons inside the fields).  This will mean a
> lot of multiple colons, but I don't think that's a major problem (in fact,
> that's where we're heading anyway).
> 
> Any other uses of colons in the pattern --- e.g. to indicate a command name
> --- would have to be rethought, but replacing the second `:' by a `-' might
> be enough.  Or just have commands and other contexts specified in different
> fields (i.e. one is ...::command:... and the other ...:context::).
> 
> Probably the big headache would be enforcing consistency in the code as it
> stands --- virtually every use of styles would have to be rewritten.  But
> I like the idea that you can set `acontext=(${(s.:.)curcontext})' and pick
> a particular word of $acontext to check.

Yes, I'd like that, too -- and changing almost every function has been
done before. I don't think that we would need to change that many
functions anyway.

The problem is with `nested' completions a la `cvs add ...' where it
is very convenient to be able to stuff the `add' into the context
name, but maybe `cvs-add' is just as good. And in cases like
`find . -exec cvs add <TAB>' we probably don't need to have both
`find' and `cvs' in the final context name.

All this has been suggested before, btw (by Bart). He even suggested
using an array. I'd prefer to still use a simple string to make
testing and re-defining faster and cheaper, but if we don't use extra
fields for the `nested' cases above, it would be nice to be able to
access fields directly -- which suggests using a tied array at least
in those functions that modify some fields (instead of just
saving/restoring $curcontext or appending one of the basic name
components).

We may need another field: my suggested nslookup function sticks a
`:nslookup' after the `:completion' -- but maybe we don't really need
that. For things like the `cvs-add' above and the number of errors
accepted by correct and approximate using another separation character 
might be a good idea... opinions?

Bye
 Sven


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

Re: match again

[Peter Stephenson]

Sven Wischnowsky wrote:
> But, before we start modifying docs are something like this, I'd like
> to repeat the question: would it be ok for everyone to make completer
> names be preceeded by two colons? With that we could use this kind of
> pattern:
> 
> > That means this example from the doc is wrong, does it not?
> > 
> >      To be able to share the same specifications one has set up for the
> >      GNU version of the ls command one can use:
> > 
> >           zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
> >                              ^^^
> 
> ... which is indeed wrong for the current state of the code. And I
> really, really don't like having to use patterns like `:completion*:...'.
> The only reason I didn't do that was because I had added the `::cmd:'
> thing at that time already.

It looks better, but is it enough to sort out all possible cases where you
might want to use `:*:'?  Or are there even more cases where we might get
into trouble with that?  I'm worried we could be barking up the wrong tree,
and should, for example, fix the fields of the pattern to
e.g. :completion:completer:command-or-context:arguments:tag (this may not
even be complete) with unrequired fields set to null strings but retaining
the colons, so you can always guarantee to pick out the appropriate
bit (unless there are extra colons inside the fields).  This will mean a
lot of multiple colons, but I don't think that's a major problem (in fact,
that's where we're heading anyway).

Any other uses of colons in the pattern --- e.g. to indicate a command name
--- would have to be rethought, but replacing the second `:' by a `-' might
be enough.  Or just have commands and other contexts specified in different
fields (i.e. one is ...::command:... and the other ...:context::).

Probably the big headache would be enforcing consistency in the code as it
stands --- virtually every use of styles would have to be rewritten.  But
I like the idea that you can set `acontext=(${(s.:.)curcontext})' and pick
a particular word of $acontext to check.

> And: any suggestion for how to test the completer style with a tag?
> Use the `default' tag (that just sounds weird, somehow, but maybe this 
> is only my problem).

Well, with the way described above it becomes much clearer what an empty
tag means.  You'd have something like `:completion::::'.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

Re: match again

[Alexandre Duret-Lutz]

>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:

 Bart> On Jan 28,  5:47pm, Alexandre Duret-Lutz wrote:
 Bart> } Subject: Re: match again
 Bart> }
 Bart> } -compstyle '*:options' prefix-hidden yes"
 Bart> } +zstyle '*:options' prefix-hidden yes"

 Bart> (And several similar examples in comments.)

 Bart> These are not equivalent.  Is it really correct to change it this way?
 Bart> The actual equivalent of the "compstyle" statement would be 

 Bart> 	zstyle ':completion*:options' prefix-hidden yes

Oops, sorry!  So let's remove my garbage...
(this also fix the comment in _urls that used 
ztyle incorrectly (well, I think :-))

Index: Completion/User/_urls
--- Completion/User/_urls Sat, 29 Jan 2000 09:42:57 +0100 Alexandre
+++ Completion/User/_urls Tue, 01 Feb 2000 11:08:04 +0100 Alexandre
@@ -6,7 +6,7 @@
 #
 # Configuration styles used:
 #
-#  urls:path
+#  path
 #    The path to a directory containing a URL database, such as:
 #
 #      % cd ~/.zsh/urls
@@ -29,14 +29,14 @@
 #      % cat bookmark/zsh/meta
 #      http://www.zsh.org/
 #
-#  urls:local
+#  local
 #    Specify a local web server as an array with three elements:
 #      <hostname> <doc root> <user area>
 #    where hostname is the name of the web server, doc root is the path to
 #    the default web pages for the server and user area is the directory
 #    name used by a user placing web pages within their home area.
 #    E.g.:
-#      zstyle '*:urls:local' www /usr/local/apache/htdocs public_html
+#      zstyle ':completion:*:urls' local www /usr/local/apache/htdocs public_html
 
 local ipre scheme host user uhosts ret=1 expl
 local urls_path localhttp
Index: Completion/Core/compinit
--- Completion/Core/compinit Sat, 29 Jan 2000 09:42:57 +0100 Alexandre
+++ Completion/Core/compinit Tue, 01 Feb 2000 11:42:13 +0100 Alexandre
@@ -358,7 +358,7 @@
       tmp="'*:options' prefix-needed yes"
       [[ "$val" = hide* ]] &&
           tmp="$tmp
-zstyle '*:options' prefix-hidden yes"
+zstyle ':completion*:options' prefix-hidden yes"
       ;;    
     group_matches)
       tmp="'*' group-name ''"
@@ -403,7 +403,7 @@
       tmp="'*' last-prompt 'yes'"
       ;;
     esac
-    [[ -n "$tmp" ]] && style="${style}${cmt}zstyle ${tmp}
+    [[ -n "$tmp" ]] && style="${style}${cmt}zstyle :completion${tmp}
 "
   done
 
Index: Completion/Core/_menu
--- Completion/Core/_menu Sat, 29 Jan 2000 09:42:57 +0100 Alexandre
+++ Completion/Core/_menu Tue, 01 Feb 2000 11:16:05 +0100 Alexandre
@@ -6,7 +6,7 @@
 # implemented with the new completion system.
 # Use this one before the normal _complete completer, as in:
 #
-#   zstyle "*" completer _menu _complete
+#   zstyle ":completion:*" completer _menu _complete
 
 if [[ -n "$compstate[old_list]" ]]; then
 
Index: Completion/Core/_match
--- Completion/Core/_match Sat, 29 Jan 2000 09:42:57 +0100 Alexandre
+++ Completion/Core/_match Tue, 01 Feb 2000 11:16:43 +0100 Alexandre
@@ -1,7 +1,7 @@
 #autoload
 
 # This is intended to be used as a completer function after the normal
-# completer as in: `zstyle "*" completer _complete _match'.
+# completer as in: `zstyle ":completion:*" completer _complete _match'.
 # It temporarily switches on pattern matching, allowing you to try 
 # completion on patterns without having to setopt glob_complete.
 #
Index: Completion/Base/_combination
--- Completion/Base/_combination Sat, 29 Jan 2000 09:42:57 +0100 Alexandre
+++ Completion/Base/_combination Tue, 01 Feb 2000 11:38:44 +0100 Alexandre
@@ -11,7 +11,7 @@
 #  Assume an user sets the style `hosts-ports-users' as for the my-accounts
 #  tag:
 #
-#    zstyle '*:telnet*:my-accounts' hosts-ports-users \
+#    zstyle ':completion:*:telnet*:my-accounts' hosts-ports-users \
 #      host0:: host1::user1 host2::user2
 #      mail-server:{smtp,pop3}:
 #      news-server:nntp:
-- 
Alexandre Duret-Lutz

Re: match again

[Sven Wischnowsky]

Bart Schaefer wrote:

> } The problem is that the default tag is tested in _main_complete which
> } doesn't add a context name
> 
> This seems an important point to me.  Is there a listing somewhere of
> the tags which are tested in _main_complete, or is "default" the only
> one?  At the least the doc for the default tag should mention this.

default and warnings (and the completer style is tested without tag at 
all). When I last cleanup up style/tag handling I mentioned that last
one, I think.

But, before we start modifying docs are something like this, I'd like
to repeat the question: would it be ok for everyone to make completer
names be preceeded by two colons? With that we could use this kind of
pattern:

> That means this example from the doc is wrong, does it not?
> 
>      To be able to share the same specifications one has set up for the
>      GNU version of the ls command one can use:
> 
>           zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
>                              ^^^

... which is indeed wrong for the current state of the code. And I
really, really don't like having to use patterns like `:completion*:...'.
The only reason I didn't do that was because I had added the `::cmd:'
thing at that time already.

And: any suggestion for how to test the completer style with a tag?
Use the `default' tag (that just sounds weird, somehow, but maybe this 
is only my problem).

> BTW, I hope the intention is to put a lot more zstyle examples into the
> docs before final release.

Sure. Everyone is kindly invited to tell us about h(er|is) favorite
style settings. Ahem.

Bye
 Sven


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

Re: match again

[Bart Schaefer]

On Jan 31, 10:06am, Sven Wischnowsky wrote:
} Subject: Re: match again
}
} Bart Schaefer wrote:
} 
} > whereas all the others resemble one of
} > 
} > 	zstyle :completion:correct: prompt 'correct to:'
} > or
} > 	zstyle ':completion:*' verbose yes
} > 
} > which makes me wonder if it should be
} > 
} > 	zstyle ':completion:*:default' list-colors ...
} 
} The problem is that the default tag is tested in _main_complete which
} doesn't add a context name

This seems an important point to me.  Is there a listing somewhere of
the tags which are tested in _main_complete, or is "default" the only
one?  At the least the doc for the default tag should mention this.

That means this example from the doc is wrong, does it not?

     To be able to share the same specifications one has set up for the
     GNU version of the ls command one can use:

          zstyle ':completion:*:default' list-colors ${(s.:.)LS_COLORS}
                             ^^^

BTW, I hope the intention is to put a lot more zstyle examples into the
docs before final release.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: match again

[Sven Wischnowsky]

Alexandre Duret-Lutz wrote:

> compinit was still generating a ~/.zsh-styles using compstyle, 
> was it intentional?

Oops, no. Before the next official release we'll have to update
compconf() anyway. A ugly task, given the changes that were made to
the styles. I would much prefer to just remove compconf() and
compstyle() and let users who use 3.1.6 change their config stuff by
hand (at least compstyle() should be removed).

Bye
 Sven


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

Re: match again

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jan 28,  5:47pm, Alexandre Duret-Lutz wrote:
> } Subject: Re: match again
> }
> } -compstyle '*:options' prefix-hidden yes"
> } +zstyle '*:options' prefix-hidden yes"
> 
> (And several similar examples in comments.)
> 
> These are not equivalent.  Is it really correct to change it this way?
> The actual equivalent of the "compstyle" statement would be 
> 
> 	zstyle ':completion*:options' prefix-hidden yes

Right.

> While I'm on the topic, should there be a ':' before the '*' in that
> example?  One of the defaults installed by compinit itself comes out
> like 
> 	zstyle ':completion*:default' list-colors ...
> 
> whereas all the others resemble one of
> 
> 	zstyle :completion:correct: prompt 'correct to:'
> or
> 	zstyle ':completion:*' verbose yes
> 
> which makes me wonder if it should be
> 
> 	zstyle ':completion:*:default' list-colors ...
> 
> Clue me on the subtlety, please.

The problem is that the default tag is tested in _main_complete which
doesn't add a context name, so it is tested in the simple case as
`:completion:default', but when called from, e.g. _correct_word, as
`:completion:correct-word:default'. A nicer pattern would be
`:completion(|:*):default'.

This is the one place I don't like about the context names. One
solution would be to always stuff `:completion:' in front so that
there are two colons before the completer name, but then we would have 
those double colons not only before the command name (although this
may be not that big a problem).

Bye
 Sven


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

Re: match again

[Bart Schaefer]

On Jan 28,  5:47pm, Alexandre Duret-Lutz wrote:
} Subject: Re: match again
}
} -compstyle '*:options' prefix-hidden yes"
} +zstyle '*:options' prefix-hidden yes"

(And several similar examples in comments.)

These are not equivalent.  Is it really correct to change it this way?
The actual equivalent of the "compstyle" statement would be 

	zstyle ':completion*:options' prefix-hidden yes

While I'm on the topic, should there be a ':' before the '*' in that
example?  One of the defaults installed by compinit itself comes out
like 
	zstyle ':completion*:default' list-colors ...

whereas all the others resemble one of

	zstyle :completion:correct: prompt 'correct to:'
or
	zstyle ':completion:*' verbose yes

which makes me wonder if it should be

	zstyle ':completion:*:default' list-colors ...

Clue me on the subtlety, please.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: match again

[Alexandre Duret-Lutz]

>>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

[...]

 Sven> [ Time to use zstyle instead of compstyle (but maybe you just used it
 Sven> for output?). ]

[...]

compinit was still generating a ~/.zsh-styles using compstyle, 
was it intentional?


Index: Completion/User/_urls
--- Completion/User/_urls Mon, 24 Jan 2000 13:13:23 +0100 Alexandre
+++ Completion/User/_urls Fri, 28 Jan 2000 17:39:44 +0100 Alexandre
@@ -36,7 +36,7 @@
 #    the default web pages for the server and user area is the directory
 #    name used by a user placing web pages within their home area.
 #    E.g.:
-#      compstyle '*:urls:local' www /usr/local/apache/htdocs public_html
+#      zstyle '*:urls:local' www /usr/local/apache/htdocs public_html
 
 local ipre scheme host user uhosts ret=1 expl
 local urls_path localhttp
Index: Completion/Core/compinit
--- Completion/Core/compinit Tue, 04 Jan 2000 16:18:39 +0100 Alexandre
+++ Completion/Core/compinit Fri, 28 Jan 2000 17:39:08 +0100 Alexandre
@@ -358,7 +358,7 @@
       tmp="'*:options' prefix-needed yes"
       [[ "$val" = hide* ]] &&
           tmp="$tmp
-compstyle '*:options' prefix-hidden yes"
+zstyle '*:options' prefix-hidden yes"
       ;;    
     group_matches)
       tmp="'*' group-name ''"
@@ -403,7 +403,7 @@
       tmp="'*' last-prompt 'yes'"
       ;;
     esac
-    [[ -n "$tmp" ]] && style="${style}${cmt}compstyle ${tmp}
+    [[ -n "$tmp" ]] && style="${style}${cmt}zstyle ${tmp}
 "
   done
 
Index: Completion/Core/_menu
--- Completion/Core/_menu Fri, 31 Dec 1999 13:32:44 +0100 Alexandre
+++ Completion/Core/_menu Fri, 28 Jan 2000 16:11:35 +0100 Alexandre
@@ -6,7 +6,7 @@
 # implemented with the new completion system.
 # Use this one before the normal _complete completer, as in:
 #
-#   compstyle "*" completer _menu _complete
+#   zstyle "*" completer _menu _complete
 
 if [[ -n "$compstate[old_list]" ]]; then
 
Index: Completion/Core/_match
--- Completion/Core/_match Fri, 31 Dec 1999 13:32:44 +0100 Alexandre
+++ Completion/Core/_match Fri, 28 Jan 2000 16:11:19 +0100 Alexandre
@@ -1,7 +1,7 @@
 #autoload
 
 # This is intended to be used as a completer function after the normal
-# completer as in: `compstyle "*" completer _complete _match'.
+# completer as in: `zstyle "*" completer _complete _match'.
 # It temporarily switches on pattern matching, allowing you to try 
 # completion on patterns without having to setopt glob_complete.
 #
Index: Completion/Base/_combination
--- Completion/Base/_combination Fri, 31 Dec 1999 13:32:44 +0100 Alexandre
+++ Completion/Base/_combination Fri, 28 Jan 2000 16:10:40 +0100 Alexandre
@@ -11,7 +11,7 @@
 #  Assume an user sets the style `hosts-ports-users' as for the my-accounts
 #  tag:
 #
-#    compstyle '*:telnet*:my-accounts' hosts-ports-users \
+#    zstyle '*:telnet*:my-accounts' hosts-ports-users \
 #      host0:: host1::user1 host2::user2
 #      mail-server:{smtp,pop3}:
 #      news-server:nntp:

-- 
Alexandre Duret-Lutz

Re: match again

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> This does not work:
> 
> bor@itsrm2% patch -p0 --dry-run < /u/p/u/z/p/*/9441<TAB>
> 
> with settings
> 
> bor@itsrm2% compstyle -L
> compstyle ':correct:' prompt 'correct to:'
> ...

[ Time to use zstyle instead of compstyle (but maybe you just used it
for output?). ]

> 
> But this one does
> 
> bor@itsrm2% patch -p0 --dry-run <
> /u2/pub/unix/zsh/patches/3.1.6-dev-16/<9440-><TAB>
> bor@itsrm2% patch -p0 --dry-run < /u2/pub/unix/zsh/patches/3.1.6-dev-16/9441
> 9441   9442

I've already explained this at least twice. The problem is that the
completion code gets a PREFIX of the form f/*/b with
`compadd -p foo/baz/ - bar'. It tries to match `foo/baz/' with `f/*'
which doesn't work, because we can only either match the whole thing
with pattern matching (messing up braces and things) or do what we do
now, i.e. try to match the prefix (and suffix) normally and use
pattern matching for the strings (like `bar' in the example).

But we can try to make _path_files a bit cleverer... the patch below
makes it stop its ambiguous-part searching loop if it arrives at a
part with a pattern. It then changes the way the cursor style is
tested to hopefully give more sensible behaviour.

Andrej, is this, finally, acceptable for you?

Bye
 Sven

diff -ru ../z.old/Completion/Core/_path_files Completion/Core/_path_files
--- ../z.old/Completion/Core/_path_files	Fri Jan 28 10:23:55 2000
+++ Completion/Core/_path_files	Fri Jan 28 10:58:33 2000
@@ -172,7 +172,7 @@
 eorig="$orig"
 
 [[ $compstate[insert] = (*menu|[0-9]*) || -n "$_comp_correct" ||
-   ( $#compstate[pattern_match] -ne 0 &&
+   ( -n "$compstate[pattern_match]" &&
      "${orig#\~}" != "${${orig#\~}:q}" ) ]] && menu=yes
 
 # If given no `-F' option, we may want to use $fignore, turned into patterns.
@@ -442,7 +442,17 @@
       tmp4=( "${(@)tmp1:#${tmp1[1]}}" )
     fi
 
-    if (( $#tmp4 )); then
+    if [[ "$tpre" = */* ]]; then
+      PREFIX="${donepath}${linepath}${cpre}${tpre%%/*}"
+      SUFFIX="/${tsuf#*/}"
+    else
+      PREFIX="${donepath}${linepath}${cpre}${tpre}"
+      SUFFIX="${tsuf}"
+    fi
+
+    if (( $#tmp4 )) ||
+       [[ -n "$compstate[pattern_match]" &&
+          "$PREFIX$SUFFIX" != "${(q)PREFIX}${(q)SUFFIX}" ]]; then
 
       # It is. For menucompletion we now add the possible completions
       # for this component with the unambigous prefix we have built
@@ -451,29 +461,21 @@
       # collected as the suffixes to make the completion code expand
       # it as far as possible.
 
-      if [[ "$tpre" = */* ]]; then
-        PREFIX="${donepath}${linepath}${cpre}${tpre%%/*}"
-	SUFFIX="/${tsuf#*/}"
-      else
-        PREFIX="${donepath}${linepath}${cpre}${tpre}"
-	SUFFIX="${tsuf}"
-      fi
-
-      tmp4="$testpath"
-      compquote tmp1 tmp4
+      tmp2="$testpath"
+      compquote tmp1 tmp2
 
       if [[ -n $menu ]] ||
          ! zstyle -t ":completion${curcontext}:paths" expand suffix; then
-        zstyle -t ":completion${curcontext}:paths" cursor &&
+        (( $#tmp4 )) && zstyle -t ":completion${curcontext}:paths" cursor &&
             compstate[to_end]=''
         if [[ "$tmp3" = */* ]]; then
-	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" -s "/${tmp3#*/}" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp2" -s "/${tmp3#*/}" \
 	          -W "$prepath$realpath$testpath" \
 		  "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                   -M "r:|/=* r:|=* $mspec" "$group[@]" "$expl[@]" \
 		  - "${(@)tmp1%%/*}"
 	else
-	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp2" \
 	          -W "$prepath$realpath$testpath" \
 		   "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                    -M "r:|/=* r:|=* $mspec" "$group[@]" "$expl[@]" \
@@ -481,7 +483,7 @@
 	fi
       else
         if [[ "$tmp3" = */* ]]; then
-	  atmp=( -Qf "$mopts[@]" -p "$linepath$tmp4"
+	  atmp=( -Qf "$mopts[@]" -p "$linepath$tmp2"
 	         -W "$prepath$realpath$testpath"
 	         "$addpfx[@]" "$addsfx[@]" "$remsfx[@]"
                  -M "r:|/=* r:|=* $mspec" "$group[@]" "$expl[@]" )
@@ -489,7 +491,7 @@
 	    compadd "$atmp[@]" -s "/${i#*/}" - "${i%%/*}"
 	  done
         else
-	  compadd -Qf "$mopts[@]" -p "$linepath$tmp4" \
+	  compadd -Qf "$mopts[@]" -p "$linepath$tmp2" \
 		  -W "$prepath$realpath$testpath" \
 		  "$addpfx[@]" "$addsfx[@]" "$remsfx[@]" \
                   -M "r:|/=* r:|=* $mspec" "$group[@]" "$expl[@]" \

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