Re: simulation of dabbrev-expand

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Adam Spiers wrote:

> > > The completion system *should* be handling this for you, but I'm going to
> > > leave that bug to Sven, [ ... ] 
> > 
> > Hm, actually I don't think this is a bug -- at least it is intended
> > behaviour. Although I admit that I partly did this for performance
> > reasons. So, should duplicates always be removed or should this be an
> > option (we're in trouble with `compctl', then -- no more option
> > letters).
> 
> I'd vote for the option er, option ... sorry :-)  No idea what you
> should do about the option letters, other than using 8-bit-high
> options ;-)

This is the non-option implementation because a) I couldn't think of a 
good option character (if someone has a suggestion and thinks we
should make this optional, tell me; what I'm really searching is
either something that is like `-v' but gives uniqified groups or
something that would be combined with `-v' to make it uniquify the
matches -- or we could make it remove duplicates unless that option is 
given (and then make it combinable with `-J' too)).

Bye
 Sven

diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Mon Sep 20 18:55:07 1999
+++ Src/Zle/zle_tricky.c	Mon Sep 20 18:52:48 1999
@@ -7272,13 +7272,23 @@
 		nl++;
 	}
 	*cp = NULL;
-    } else
+    } else {
+	for (ap = rp; *ap; ap++) {
+	    for (bp = cp = ap + 1; *bp; bp++) {
+		if (!matcheq(*ap, *bp))
+		    *cp++ = *bp;
+		else
+		    n--;
+	    }
+	    *cp = NULL;
+	}
 	for (ap = rp; *ap; ap++) {
 	    if ((*ap)->disp && ((*ap)->flags & CMF_DISPLINE))
 		ll++;
 	    if ((*ap)->flags & CMF_NOLIST)
 		nl++;
 	}
+    }
     if (np)
 	*np = n;
     if (nlp)

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx