Something else wrong with _multi_parts

Something else wrong with _multi_parts

[Bart Schaefer]

Given something like

	names=( foo bar home/test /usr/tmp /tmp/foo )
	_multi_parts / names

Only (/usr/tmp /tmp/foo) make it into the `matches' array in _multi_parts.
I would have expected to be offered (foo bar home /) as the initial set of
completions.

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

Re: Something else wrong with _multi_parts

[Bart Schaefer]

On Feb 21, 11:01am, Sven Wischnowsky wrote:
} Subject: Re: Something else wrong with _multi_parts
}
} Bart Schaefer wrote:
} 
} > 	names=( foo bar home/test /usr/tmp /tmp/foo )
} > 	_multi_parts / names
} > 
} > Only (/usr/tmp /tmp/foo) make it into the `matches' array in _multi_parts.
} 
} At one point while building this patch I got (with /<TAB>) the matches 
} `/' and `home'. Somehow, this is correct, but I think the behaviour
} this shows now is more intuitive.

Hmm, using the _mailboxes that I just sent, I get offered two matches at
this point:

zagzig[152] mail -f /usr<TAB>
/usr/
usr/

That certainly can't be right.  Looking at a fragment of an xtrace:

[...]

+_multi_parts:84> tmp1=( usr/mail/schaefer usr/spool/mail/schaefer ) 
+_multi_parts:89> ((  2  ))
+_multi_parts:90> npref=usr/ 
+_multi_parts:216> matches=( mail/schaefer spool/mail/schaefer ) 
+_multi_parts:217> pref=/usr/ 
+_multi_parts:221> [[ usr == */* ]]
+_multi_parts:224> [[  == */* ]]
+_multi_parts:233> PREFIX=/usr 
+_multi_parts:234> SUFFIX= 
+_multi_parts:236> [[ -n /usr/ && /usr != /usr/ ]]
+_multi_parts:237> compadd -J -default- -S  -M r:|/=* r:|=*  - /usr/
+_multi_parts:240> return

[...]

+_path_files:517> compadd -Qf -J all-files -F _comp_ignore -p / -W / -M r:|/=* r:|=* - usr

It appears that _multi_parts is compadding "/usr/" and _path_files is
compadding "usr".  I expected them both to "compadd ... usr".

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

Re: Something else wrong with _multi_parts

[Sven Wischnowsky]

Bart Schaefer wrote:

> Given something like
> 
> 	names=( foo bar home/test /usr/tmp /tmp/foo )
> 	_multi_parts / names
> 
> Only (/usr/tmp /tmp/foo) make it into the `matches' array in _multi_parts.
> I would have expected to be offered (foo bar home /) as the initial set of
> completions.

At one point while building this patch I got (with /<TAB>) the matches 
`/' and `home'. Somehow, this is correct, but I think the behaviour
this shows now is more intuitive.

Bye
 Sven

diff -ru ../z.old/Completion/Core/_multi_parts Completion/Core/_multi_parts
--- ../z.old/Completion/Core/_multi_parts	Mon Feb 21 10:50:49 2000
+++ Completion/Core/_multi_parts	Mon Feb 21 10:59:05 2000
@@ -80,7 +80,11 @@
   # use the stuff from the line. This avoids having `foo' complete to
   # both `foo' and `foobar'.
 
-  tmp1=( "${(@M)matches:#${PREFIX}${SUFFIX}${sep}*}" )
+  if [[ -n "$PREFIX$SUFFIX" || "$pre" = ${sep}* ]]; then
+    tmp1=( "${(@M)matches:#${PREFIX}${SUFFIX}${sep}*}" )
+  else
+    tmp1=
+  fi
 
   if (( $#tmp1 )); then
     npref="${PREFIX}${SUFFIX}${sep}"

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