Re: simulation of dabbrev-expand

Re: simulation of dabbrev-expand

[Sven Wischnowsky]

I wrote:

> This is the non-option implementation because a) [ ... ]

I forgot: b) the manual doesn't saythat duplicates aren't removed, and 
c) Bart called it a bug.

Bye
 Sven


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

Re: simulation of dabbrev-expand

[Adam Spiers]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> 
> Adam Spiers wrote:
> 
> > [ removing duplicates in completion lists ]
> > 
> > I think it should be optional.  I also think you should have the
> > choice of whether to remove all duplicates or just consecutive ones.
> > What about -1 and -2, or some other funny option characters?
> 
> Ok. This makes `-1' keep the completion system from removing all
> duplicates and `-2' keep it from removing consecutive duplicates. Yes, 
> the sense is reversed so that `-J' still gives the normal behaviour.

Nice work, Sven!  The potential for an almost perfect
_history_complete_word is now upon us ... although I'm having problems
creating it.

The current situation is that _history_complete_word crawls through
matching history words, oldest first.  This is counter-intuitive,
impractical, and not what tcsh users would expect; so I've been
trying to change it to the following setup:

   M-/  _reverse_history_complete_word
   M-,  _history_complete_word

_reverse_history_complete_word startest with the most recent match and
works back, and vice versa for _history_complete_word.

However, I got stuck when handling the history_stop feature.
When in verbose mode, history_stop uses _message to indicate that the
beginning/end of the history has been reached.  However, unless I've
got things really wrong, _message seems to destroy any old list of matches
which you might want to keep.  I can't understand why, as it's only
essentially a compadd -X ... -n ''.  I want to do something like:

    compstate[old_list]=keep
    _message 'beginning of history reached'

so that if you hit the oldest match and press M-/ again, it displays
this message but keeps the oldest match (should I need a
compstate[insert]=1 again, or is it enough to have done that the first
time the oldest match was displayed?), and if you switch to M-, it
will keep this old_list again and start moving in the opposite
direction.

Finally, should forward and reverse motion both be handled by the same
widget?

If you can help with the above problem then with luck I'll be able to
save you the hassle of rewriting all the code.  Thanks!

Adam

Re: simulation of dabbrev-expand

[Zefram]

Sven Wischnowsky wrote:
>Ok. This makes `-1' keep the completion system from removing all
>duplicates and `-2' keep it from removing consecutive duplicates. Yes, 
>the sense is reversed so that `-J' still gives the normal behaviour.

So you mean

	neither option = remove all duplicates
	-1 = keep non-consecutive duplicates and remove consecutive duplicates
	-2 = keep all duplicates

>In other words:
>-V   -- unsorted list without duplicates
>-V1  -- unsorted list with only non-consecutive duplicates
>-V2  -- unsorted list with all duplicates

OK

>-J   -- sorted list without duplicates
>-J1  -- sorted list with duplicates (which are all consecutive due to
>        the sorting)
>-J2  -- same as -J1

That can't be right.  -J1 should be removing consecutive duplicates,
i.e., all duplicates due to the sorting.  Shouldn't it?

>+item(tt(-2))(
>+If given together with the tt(-J) option, behaves the same as
>+tt(-J).

This looks fishy too.

-zefram

Re: simulation of dabbrev-expand

[Sven Wischnowsky]

Adam Spiers wrote:

> [ removing duplicates in completion lists ]
> 
> I think it should be optional.  I also think you should have the
> choice of whether to remove all duplicates or just consecutive ones.
> What about -1 and -2, or some other funny option characters?

Ok. This makes `-1' keep the completion system from removing all
duplicates and `-2' keep it from removing consecutive duplicates. Yes, 
the sense is reversed so that `-J' still gives the normal behaviour.

In other words:

-J   -- sorted list without duplicates
-J1  -- sorted list with duplicates (which are all consecutive due to
        the sorting)
-J2  -- same as -J1
-V   -- unsorted list without duplicates
-V1  -- unsorted list with only non-consecutive duplicates
-V2  -- unsorted list with all duplicates

Ok?

I took the opportunity to clean up begcmgroup() and makearray().

This also changes `_description' to accept any `-[JV]*' option as its
first argument.

Bye
 Sven

diff -u os/Zle/comp.h Src/Zle/comp.h
--- os/Zle/comp.h	Wed Sep 22 13:33:18 1999
+++ Src/Zle/comp.h	Wed Sep 22 15:20:46 1999
@@ -161,6 +161,8 @@
 #define CC_CCCONT	(1<<2)
 #define CC_PATCONT	(1<<3)
 #define CC_DEFCONT	(1<<4)
+#define CC_UNIQCON      (1<<5)
+#define CC_UNIQALL      (1<<6)
 
 typedef struct cexpl *Cexpl;
 typedef struct cmgroup *Cmgroup;
@@ -206,9 +208,11 @@
 };
 
 
-#define CGF_NOSORT  1		/* don't sort this group */
-#define CGF_LINES   2		/* these are to be printed on different lines */
-#define CGF_HASDL   4		/* has disply strings printed on sseparate lines */
+#define CGF_NOSORT   1		/* don't sort this group */
+#define CGF_LINES    2		/* these are to be printed on different lines */
+#define CGF_HASDL    4		/* has display strings printed on separate lines */
+#define CGF_UNIQALL  8		/* remove all duplicates */
+#define CGF_UNIQCON 16		/* remove consecutive duplicates */
 
 /* This is the struct used to hold matches. */
 
@@ -301,6 +305,8 @@
 #define CAF_NOSORT   2
 #define CAF_ALT      4
 #define CAF_MATCH    8
+#define CAF_UNIQCON 16
+#define CAF_UNIQALL 32
 
 /* Data for compadd and addmatches() */
 
diff -u os/Zle/compctl.c Src/Zle/compctl.c
--- os/Zle/compctl.c	Wed Sep 22 13:33:18 1999
+++ Src/Zle/compctl.c	Wed Sep 22 15:39:01 1999
@@ -750,6 +750,14 @@
 		}
 		cct.mask2 |= CC_NOSORT;
 		break;
+	    case '1':
+		cct.mask2 |= CC_UNIQALL;
+		cct.mask2 &= ~CC_UNIQCON;
+		break;
+	    case '2':
+		cct.mask2 |= CC_UNIQCON;
+		cct.mask2 &= ~CC_UNIQALL;
+		break;
 	    case 'M':
 		if (cclist & COMP_LIST) {
 		    cclist |= COMP_LISTMATCH;
@@ -1439,7 +1447,7 @@
     }
 
     /* loop through flags w/o args that are set, printing them if so */
-    if (flags & t) {
+    if ((flags & t) || (flags2 & (CC_UNIQALL | CC_UNIQCON))) {
 	printf(" -");
 	if ((flags & (CC_ALREG | CC_ALGLOB)) == (CC_ALREG | CC_ALGLOB))
 	    putchar('a'), flags &= ~(CC_ALREG | CC_ALGLOB);
@@ -1450,6 +1458,10 @@
 	    flags >>= 1;
 	    t >>= 1;
 	}
+	if (flags2 & CC_UNIQALL)
+	    putchar('1');
+	else if (flags2 & CC_UNIQCON)
+	    putchar('2');
     }
     if (flags2 & (CC_XORCONT | CC_PATCONT | CC_DEFCONT)) {
 	printf(" -t");
@@ -1787,6 +1799,14 @@
 		    dat.aflags |= CAF_NOSORT;
 		sp = &(dat.group);
 		e = "group name expected after -%c";
+		break;
+	    case '1':
+		if (!(dat.aflags & CAF_UNIQCON))
+		    dat.aflags |= CAF_UNIQALL;
+		break;
+	    case '2':
+		if (!(dat.aflags & CAF_UNIQALL))
+		    dat.aflags |= CAF_UNIQCON;
 		break;
 	    case 'y':
 		sp = &(dat.ylist);
diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c
--- os/Zle/zle_tricky.c	Wed Sep 22 13:33:20 1999
+++ Src/Zle/zle_tricky.c	Wed Sep 22 15:58:39 1999
@@ -3963,7 +3963,7 @@
     char **aign = NULL, **dparr = NULL, oaq = autoq, *oppre = dat->ppre;
     char *oqp = qipre, *oqs = qisuf, qc, **disp = NULL;
     int lpl, lsl, pl, sl, bpl, bsl, bppl = -1, bssl = -1;
-    int llpl = 0, llsl = 0, nm = mnum;
+    int llpl = 0, llsl = 0, nm = mnum, gflags;
     int oisalt = 0, isalt, isexact, doadd, ois = instring, oib = inbackt;
     Cline lc = NULL;
     Cmatch cm;
@@ -4145,20 +4145,19 @@
 		} else
 		    dat->prpre = dupstring(dat->prpre);
 		/* Select the group in which to store the matches. */
+		gflags = (((dat->aflags & CAF_NOSORT ) ? CGF_NOSORT  : 0) |
+			  ((dat->aflags & CAF_UNIQALL) ? CGF_UNIQALL : 0) |
+			  ((dat->aflags & CAF_UNIQCON) ? CGF_UNIQCON : 0));
 		if (dat->group) {
 		    endcmgroup(NULL);
-		    begcmgroup(dat->group, (dat->aflags & CAF_NOSORT));
-		    if (dat->aflags & CAF_NOSORT)
-			mgroup->flags |= CGF_NOSORT;
+		    begcmgroup(dat->group, gflags);
 		} else {
 		    endcmgroup(NULL);
 		    begcmgroup("default", 0);
 		}
 		if (dat->ylist) {
 		    endcmgroup(NULL);
-		    begcmgroup(NULL, (dat->aflags & CAF_NOSORT));
-		    if (dat->aflags & CAF_NOSORT)
-			mgroup->flags |= CGF_NOSORT;
+		    begcmgroup(NULL, gflags);
 		}
 		/* Select the set of matches. */
 		oisalt = (dat->aflags & CAF_ALT);
@@ -4247,7 +4246,7 @@
 	    if (dat->ylist) {
 		if (dat->group) {
 		    endcmgroup(get_user_var(dat->ylist));
-		    begcmgroup(dat->group, (dat->aflags & CAF_NOSORT));
+		    begcmgroup(dat->group, gflags);
 		    if (dat->exp)
 			addexpl();
 		} else {
@@ -6164,7 +6163,7 @@
 static void
 makecomplistflags(Compctl cc, char *s, int incmd, int compadd)
 {
-    int t, sf1, sf2, ooffs, um = usemenu, delit, oaw;
+    int t, sf1, sf2, ooffs, um = usemenu, delit, oaw, gflags;
     char *p, *sd = NULL, *tt, *s1, *s2, *os =  dupstring(s);
     struct cmlist ms;
 
@@ -6199,18 +6198,19 @@
     curcc = cc;
 
     mflags = 0;
+    gflags = (((cc->mask2 & CC_NOSORT ) ? CGF_NOSORT  : 0) |
+	      ((cc->mask2 & CC_UNIQALL) ? CGF_UNIQALL : 0) |
+	      ((cc->mask2 & CC_UNIQCON) ? CGF_UNIQCON : 0));
     if (cc->gname) {
 	endcmgroup(NULL);
-	begcmgroup(cc->gname, cc->mask2 & CC_NOSORT);
+	begcmgroup(cc->gname, gflags);
     }
     if (cc->ylist) {
 	endcmgroup(NULL);
-	begcmgroup(NULL, cc->mask2 & CC_NOSORT);
+	begcmgroup(NULL, gflags);
     }
     if (cc->mask & CC_REMOVE)
 	mflags |= CMF_REMOVE;
-    if (cc->mask2 & CC_NOSORT)
-	mgroup->flags |= CGF_NOSORT;
     if (cc->explain) {
 	expl = (Cexpl) zhalloc(sizeof(struct cexpl));
 	expl->count = expl->fcount = 0;
@@ -7006,7 +7006,7 @@
 	    expl->str = tt;
 	    if (cc->gname) {
 		endcmgroup(yaptr);
-		begcmgroup(cc->gname, cc->mask2 & CC_NOSORT);
+		begcmgroup(cc->gname, gflags);
 		addexpl();
 	    } else {
 		addexpl();
@@ -7227,7 +7227,7 @@
 
 /**/
 static Cmatch *
-makearray(LinkList l, int s, int u, int *np, int *nlp, int *llp)
+makearray(LinkList l, int type, int flags, int *np, int *nlp, int *llp)
 {
     Cmatch *ap, *bp, *cp, *rp;
     LinkNode nod;
@@ -7242,57 +7242,75 @@
 	*ap++ = (Cmatch) getdata(nod);
     *ap = NULL;
 
-    if (s == 1) {
-	char **ap, **bp, **cp;
-
-	/* Now sort the array (it contains strings). */
-	qsort((void *) rp, n, sizeof(char *),
-	      (int (*) _((const void *, const void *)))strbpcmp);
-
-	/* And delete the ones that occur more than once. */
-	for (ap = cp = (char **) rp; *ap; ap++) {
-	    *cp++ = *ap;
-	    for (bp = ap; bp[1] && !strcmp(*ap, bp[1]); bp++, n--);
-	    ap = bp;
-	}
-	*cp = NULL;
-    } else if (s) {
-	/* Now sort the array (it contains matches). */
-	qsort((void *) rp, n, sizeof(Cmatch),
-	      (int (*) _((const void *, const void *)))matchcmp);
-
-	/* And delete the ones that occur more than once. */
-	for (ap = cp = rp; *ap; ap++) {
-	    *cp++ = *ap;
-	    for (bp = ap; bp[1] && matcheq(*ap, bp[1]); bp++, n--);
-	    ap = bp;
-	    /* Mark those, that would show the same string in the list. */
-	    for (; bp[1] && !(*ap)->disp && !(bp[1])->disp &&
-		     !strcmp((*ap)->str, (bp[1])->str); bp++)
-		(bp[1])->flags |= CMF_NOLIST;
-	}
-	for (ap = rp; *ap; ap++) {
-	    if ((*ap)->disp && ((*ap)->flags & CMF_DISPLINE))
-		ll++;
-	    if ((*ap)->flags & CMF_NOLIST)
-		nl++;
-	}
-	*cp = NULL;
-    } else if (u) {
-	for (ap = rp; *ap; ap++) {
-	    for (bp = cp = ap + 1; *bp; bp++) {
-		if (!matcheq(*ap, *bp))
-		    *cp++ = *bp;
-		else
-		    n--;
+    if (!type) {
+	if (flags) {
+	    char **ap, **bp, **cp;
+
+	    /* Now sort the array (it contains strings). */
+	    qsort((void *) rp, n, sizeof(char *),
+		  (int (*) _((const void *, const void *)))strbpcmp);
+
+	    /* And delete the ones that occur more than once. */
+	    for (ap = cp = (char **) rp; *ap; ap++) {
+		*cp++ = *ap;
+		for (bp = ap; bp[1] && !strcmp(*ap, bp[1]); bp++, n--);
+		ap = bp;
 	    }
 	    *cp = NULL;
 	}
-	for (ap = rp; *ap; ap++) {
-	    if ((*ap)->disp && ((*ap)->flags & CMF_DISPLINE))
-		ll++;
-	    if ((*ap)->flags & CMF_NOLIST)
-		nl++;
+    } else {
+	if (!(flags & CGF_NOSORT)) {
+	    /* Now sort the array (it contains matches). */
+	    qsort((void *) rp, n, sizeof(Cmatch),
+		  (int (*) _((const void *, const void *)))matchcmp);
+
+	    if (!(flags & (CGF_UNIQALL | CGF_UNIQCON))) {
+		/* And delete the ones that occur more than once. */
+		for (ap = cp = rp; *ap; ap++) {
+		    *cp++ = *ap;
+		    for (bp = ap; bp[1] && matcheq(*ap, bp[1]); bp++, n--);
+		    ap = bp;
+		    /* Mark those, that would show the same string in the list. */
+		    for (; bp[1] && !(*ap)->disp && !(bp[1])->disp &&
+			     !strcmp((*ap)->str, (bp[1])->str); bp++)
+			(bp[1])->flags |= CMF_NOLIST;
+		}
+		*cp = NULL;
+	    }
+	    for (ap = rp; *ap; ap++) {
+		if ((*ap)->disp && ((*ap)->flags & CMF_DISPLINE))
+		    ll++;
+		if ((*ap)->flags & CMF_NOLIST)
+		    nl++;
+	    }
+	} else {
+	    if (!(flags & CGF_UNIQALL) && !(flags & CGF_UNIQCON)) {
+		for (ap = rp; *ap; ap++) {
+		    for (bp = cp = ap + 1; *bp; bp++) {
+			if (!matcheq(*ap, *bp))
+			    *cp++ = *bp;
+			else
+			    n--;
+		    }
+		    *cp = NULL;
+		}
+	    } else if (!(flags & CGF_UNIQCON)) {
+		for (ap = cp = rp; *ap; ap++) {
+		    *cp++ = *ap;
+		    for (bp = ap; bp[1] && matcheq(*ap, bp[1]); bp++, n--);
+		    ap = bp;
+		    for (; bp[1] && !(*ap)->disp && !(bp[1])->disp &&
+			     !strcmp((*ap)->str, (bp[1])->str); bp++)
+			(bp[1])->flags |= CMF_NOLIST;
+		}
+		*cp = NULL;
+	    }
+	    for (ap = rp; *ap; ap++) {
+		if ((*ap)->disp && ((*ap)->flags & CMF_DISPLINE))
+		    ll++;
+		if ((*ap)->flags & CMF_NOLIST)
+		    nl++;
+	    }
 	}
     }
     if (np)
@@ -7308,13 +7326,14 @@
 
 /**/
 static void
-begcmgroup(char *n, int nu)
+begcmgroup(char *n, int flags)
 {
     if (n) {
 	Cmgroup p = amatches;
 
 	while (p) {
-	    if (p->name && ((nu && !p->lallccs) || (!nu && p->lallccs)) &&
+	    if (p->name &&
+		flags == (p->flags & (CGF_NOSORT|CGF_UNIQALL|CGF_UNIQCON)) &&
 		!strcmp(n, p->name)) {
 		mgroup = p;
 
@@ -7330,7 +7349,8 @@
     }
     mgroup = (Cmgroup) zhalloc(sizeof(struct cmgroup));
     mgroup->name = dupstring(n);
-    mgroup->flags = mgroup->lcount = mgroup->llcount = mgroup->mcount = 0;
+    mgroup->lcount = mgroup->llcount = mgroup->mcount = 0;
+    mgroup->flags = flags;
     mgroup->matches = NULL;
     mgroup->ylist = NULL;
     mgroup->expls = NULL;
@@ -7339,7 +7359,7 @@
     mgroup->lmatches = matches = newlinklist();
     mgroup->lfmatches = fmatches = newlinklist();
 
-    mgroup->lallccs = allccs = (nu ? NULL : newlinklist());
+    mgroup->lallccs = allccs = ((flags & CGF_NOSORT) ? NULL : newlinklist());
 
     mgroup->next = amatches;
     amatches = mgroup;
@@ -7435,9 +7455,7 @@
 		/* We have no matches, try ignoring fignore. */
 		g->lmatches = g->lfmatches;
 
-	    g->matches = makearray(g->lmatches,
-				   ((g->flags & CGF_NOSORT) ? 0 : 2), 1,
-				   &nn, &nl, &ll);
+	    g->matches = makearray(g->lmatches, 1, g->flags, &nn, &nl, &ll);
 	    g->mcount = nn;
 	    if ((g->lcount = nn - nl) < 0)
 		g->lcount = 0;
@@ -9172,7 +9190,7 @@
     smatches = 1;
     validlist = 1;
     memset(&dg, 0, sizeof(struct cmgroup));
-    dg.ylist = (char **) makearray(l, 1, 0, &(dg.lcount), NULL, NULL);
+    dg.ylist = (char **) makearray(l, 0, 1, &(dg.lcount), NULL, NULL);
     amatches = &dg;
     ilistmatches(NULL, NULL);
     amatches = am;
diff -u od/Zsh/compctl.yo Doc/Zsh/compctl.yo
--- od/Zsh/compctl.yo	Wed Sep 22 13:33:04 1999
+++ Doc/Zsh/compctl.yo	Wed Sep 22 16:00:48 1999
@@ -137,7 +137,7 @@
 texinode(Option Flags)(Alternative Completion)(Command Flags)(Programmable Completion Using compctl)
 sect(Option Flags)
 startlist()
-list([ tt(-fcFBdeaRGovNAIOPZEnbjrzu/) ])
+list([ tt(-fcFBdeaRGovNAIOPZEnbjrzu/12) ])
 list([ tt(-k) var(array) ] [ tt(-g) var(globstring) ] \
   [ tt(-s) var(subststring) ])
 list([ tt(-K) var(function) ] [ tt(-i) var(function) ])
@@ -515,6 +515,18 @@
 nor in menucompletion. These unsorted groups are in a different name
 space from the sorted ones, so groups defined as tt(-J files) and tt(-V
 files) are distinct.
+)
+item(tt(-1))(
+If given together with the tt(-J) option, makes duplicate matches in
+the group be kept. If given together with the tt(-V) option, makes
+only consecutive duplicates in the group be removed. Note that groups
+with and without this flag are in different name spaces.
+)
+item(tt(-2))(
+If given together with the tt(-J) option, behaves the same as
+tt(-J). If given together with the tt(-V) option, keep all duplicate
+matches. Again, groups with and without this flag are in different
+name spaces.
 )
 item(tt(-M) var(match-spec))(
 This defines additional matching control specifications that should be used
diff -u od/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- od/Zsh/compsys.yo	Wed Sep 22 13:33:04 1999
+++ Doc/Zsh/compsys.yo	Wed Sep 22 16:05:57 1999
@@ -566,8 +566,10 @@
 matches are placed in a separate group (the second argument is used as 
 the name of the group) if the configuration key tt(group_matches) is
 set to a non-empty string. Normally a sorted group will be used for this
-(with the `tt(-J)' option), but if the option `tt(-V)' is given, a
-unsorted group will be used instead.
+(with the `tt(-J)' option), but if a option starting with `tt(-V)' or
+`tt(-J)' is given, that option will be included in the array, so that
+it is possible to make the group unsorted by given the option
+`tt(-V)', `tt(-V1)', or `tt(-V2)'.
 
 In most cases, this function will be used like this:
 
diff -u od/Zsh/compwid.yo Doc/Zsh/compwid.yo
--- od/Zsh/compwid.yo	Wed Sep 22 13:33:04 1999
+++ Doc/Zsh/compwid.yo	Wed Sep 22 16:01:05 1999
@@ -369,7 +369,7 @@
 )
 findex(compadd)
 cindex(completion widgets, adding specified matches)
-xitem(tt(compadd) [ tt(-qQfenUaml) ] [ tt(-F) var(array) ])
+xitem(tt(compadd) [ tt(-qQfenUaml12) ] [ tt(-F) var(array) ])
 xitem([ tt(-P) var(prefix) ] [ tt(-S) var(suffix) ])
 xitem([ tt(-p) var(hidden-prefix) ] [ tt(-s) var(hidden-suffix) ])
 xitem([ tt(-i) var(ignored-prefix) ] [ tt(-I) var(ignored-suffix) ])
@@ -462,6 +462,18 @@
 )
 item(tt(-V) var(name))(
 Like tt(-J) but naming a unsorted group.
+)
+item(tt(-1))(
+If given together with the tt(-J) option, makes duplicate matches in
+the group be kept. If given together with the tt(-V) option, makes
+only consecutive duplicates in the group be removed. Note that groups
+with and without this flag are in different name spaces.
+)
+item(tt(-2))(
+If given together with the tt(-J) option, behaves the same as
+tt(-J). If given together with the tt(-V) option, keep all duplicate
+matches. Again, groups with and without this flag are in different
+name spaces.
 )
 item(tt(-X) var(explanation))(
 As for tt(compctl) and tt(compgen), the var(explanation) string will be
diff -u oldcompletion/Core/_description Completion/Core/_description
--- oldcompletion/Core/_description	Tue Sep 21 10:26:40 1999
+++ Completion/Core/_description	Wed Sep 22 16:06:15 1999
@@ -2,8 +2,8 @@
 
 local gropt=-J
 
-if [[ "$1" = -V ]]; then
-  gropt=-V
+if [[ "$1" = -[VJ]* ]]; then
+  gropt="$1"
   shift
 fi
 

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

Re: simulation of dabbrev-expand

[Adam Spiers]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> 
> 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

I think it should be optional.  I also think you should have the
choice of whether to remove all duplicates or just consecutive ones.
What about -1 and -2, or some other funny option characters?

Re: simulation of dabbrev-expand

[Sven Wischnowsky]

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@informatik.hu-berlin.de

Re: simulation of dabbrev-expand

[Adam Spiers]

Sven Wischnowsky (wischnow@informatik.hu-berlin.de) wrote:
> 
> Adam Spiers wrote:
> 
> > How can I ensure that there are no duplicate words in the list of
> > matches?  Even if this isn't the real problem I'm experiencing, it may
> > well help narrow it down. 
> 
> Bart Schaefer answered:
> 
> > 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 ;-)

> You've missed some mails in which I wrote something about this. See
> 6117 and 6119 (and somewhere before that, but I don't have this in my
> list any more, it seems).

Thanks; interesting reading.

Re: simulation of dabbrev-expand

[Sven Wischnowsky]

Adam Spiers wrote:

> How can I ensure that there are no duplicate words in the list of
> matches?  Even if this isn't the real problem I'm experiencing, it may
> well help narrow it down. 

Bart Schaefer answered:

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

> This questions leads me to another: we have
> all these variables at our disposal in the widget functions for
> examining the completion system's state in great detail ... but the
> one thing we still can't do (AFAICS) is actually see what completions
> have currently been calculated.  If there was a special array
> parameter, `completions' say, then things like removing duplicate
> matches, or choosing your own match sorting algorithm (although heaven
> forbid I would ever need to implement a quicksort in zsh :-) would
> become possible in the shell functions.  Have I missed something here?

You've missed some mails in which I wrote something about this. See
6117 and 6119 (and somewhere before that, but I don't have this in my
list any more, it seems).

Bye
 Sven


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

Re: simulation of dabbrev-expand

[Adam Spiers]

Adam Spiers, on thelonious (adam@thelonious.new.ox.ac.uk) wrote:
> Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> > On Sep 9,  1:39pm, Adam Spiers wrote:
> > } It appears to always work fine when grabbing words from history added
> > } by the current shell, but either doesn't work at all, or very
> > } unreliably when you want to grab a word from the saved history.
> > 
> > Can you perhaps give a more specific example?  I'm not having any trouble
> > with this at all.
> 
>   % history 1 | grep ' /' | wc -l
>       650
>   % less /<TAB>
>   % less /usr/share/zsh/functions/_man
>   zsh: do you wish to see all 51 possibilities? 
> 
> Where did all the others go?

[snip]

> The newer entries work fine.  This problem has
> exhibited itself in exactly the same way across zsh-3.1.6-pws-* :-(

I've done a lot of further investigation into this, and *still* cannot
spot an exact pattern to when it does and doesn't work, which is
unbelievably frustrating.  However, I'm beginning to suspect that it
may have something to do with history duplicates.  Sven's latest patch
to _history_complete_word is very nice, but if the `history_sort'
configuration key is unset, no sorting occurs, and hence no removal of
duplicates.  (As we're talking about individual words extracted from
the history, the options dealing with history line duplicates have
little bearing on this.)

How can I ensure that there are no duplicate words in the list of
matches?  Even if this isn't the real problem I'm experiencing, it may
well help narrow it down.  This questions leads me to another: we have
all these variables at our disposal in the widget functions for
examining the completion system's state in great detail ... but the
one thing we still can't do (AFAICS) is actually see what completions
have currently been calculated.  If there was a special array
parameter, `completions' say, then things like removing duplicate
matches, or choosing your own match sorting algorithm (although heaven
forbid I would ever need to implement a quicksort in zsh :-) would
become possible in the shell functions.  Have I missed something here?

Adam