* Re: simulation of dabbrev-expand
[not found] ` <19990916173409.A17932@thelonious.new.ox.ac.uk>
@ 1999-09-17 21:44 ` Adam Spiers
1999-09-18 19:59 ` PATCH: 3.1.6-pws-4: " Bart Schaefer
0 siblings, 1 reply; 11+ messages in thread
From: Adam Spiers @ 1999-09-17 21:44 UTC (permalink / raw)
To: zsh workers mailing list
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* PATCH: 3.1.6-pws-4: Re: simulation of dabbrev-expand
1999-09-17 21:44 ` simulation of dabbrev-expand Adam Spiers
@ 1999-09-18 19:59 ` Bart Schaefer
1999-09-22 22:21 ` Adam Spiers
0 siblings, 1 reply; 11+ messages in thread
From: Bart Schaefer @ 1999-09-18 19:59 UTC (permalink / raw)
To: zsh-workers, Adam Spiers
On Sep 16, 5:34pm, Adam Spiers wrote:
} Subject: Re: simulation of dabbrev-expand
}
} Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
} > On Sep 9, 1:39pm, Adam Spiers wrote:
} > } Subject: simulation of dabbrev-expand
} > }
} > } 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.
I'm finally able to reproduce something like this.
} % history 1 | grep ' /' | wc -l
} 650
} % less /<>
} % less /usr/share/zsh/functions/_man
} zsh: do you wish to see all 51 possibilities?
I just tried >>ing the histories from five different xterms into a single
file and then loading them all into a fresh zsh with "fc -R". Here's what
I get:
zagzig<2996> history 1 | grep ' /' | wc -l
110
zagzig<2997> less /tmp/histdump2
zsh: do you wish to see all 138 possibilities?
If I say "y" at this point I get a list with a lot of duplicate entries,
but it certainly seems to span all the history.
If I next setopt the complete collection of options that you quoted:
} cshjunkiehistory
} extendedhistory
} histallowclobber
} histexpiredupsfirst
} histignorealldups
} histignoredups
} histignorespace
} histreduceblanks
} histverify
} incappendhistory
then suddenly "compgen -H" fails to search back farther than the point at
which I executed the "setopts", and a few commands later it's searching
only a couple of lines back.
The problem is in zle_tricky.c's use of quietgethist(). With Wayne's new
stuff, the history list may have holes in it, but makecomplistflags() is
trying to iterate over the history by calling quietgethist() on consecutive
integers until it returns nothing -- which happens whenever it encounters
such a hole.
I think the patch below should take care of this part, but it's possible
that I've done more than was necessary; in particular, the hist.c hunk
may not be needed: it might suffice to call the original quietgethist()
before the loop in makecomplistflags(). It's also possible that calling
up_histent() N times is the wrong thing to do: Should the number passed
to compgen -H specify the number of history entries searched or the range
of history numbers searched? I've interpreted it as the former.
I haven't done an inventory looking for other such misuses of the gethist
family of functions, but perhaps Wayne or someone else very familiar with
them should do so.
On Sep 17, 10:44pm, Adam Spiers wrote:
} Subject: Re: simulation of dabbrev-expand
}
} How can I ensure that there are no duplicate words in the list of
} matches?
The completion system *should* be handling this for you, but I'm going to
leave that bug to Sven, as I don't feel like understanding the completion
system quite that deeply today. (I actually seem to be having much better
luck with that, too, after the patch below, but I'm mystified as to why.)
Index: Src/hist.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/hist.c,v
retrieving revision 1.15
diff -u -r1.15 hist.c
--- hist.c 1999/08/30 15:34:03 1.15
+++ hist.c 1999/09/18 19:21:49
@@ -1435,14 +1435,21 @@
/**/
Histent
-quietgethist(int ev)
+quietgethistent(int ev, int nearmatch)
{
if (ev == curhist && (histactive & HA_ACTIVE)) {
curline.text = chline;
curline.nwords = chwordpos/2;
curline.words = chwords;
}
- return gethistent(ev, GETHIST_EXACT);
+ return gethistent(ev, nearmatch);
+}
+
+/**/
+Histent
+quietgethist(int ev)
+{
+ return quietgethistent(ev, GETHIST_EXACT);
}
/**/
Index: Src/Zle/zle_tricky.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/Zle/zle_tricky.c,v
retrieving revision 1.157
diff -u -r1.157 zle_tricky.c
--- zle_tricky.c 1999/09/18 07:20:15 1.157
+++ zle_tricky.c 1999/09/18 19:32:19
@@ -6723,8 +6723,8 @@
/* We have a pattern to take things from the history. */
Patprog pprogc = NULL;
char *e, *h, hpatsav;
- Histent he;
int i = addhistnum(curhist,-1,HIST_FOREIGN), n = cc->hnum;
+ Histent he = quietgethistent(i, GETHIST_UPWARD);
/* Parse the pattern, if it isn't the null string. */
if (*(cc->hpat)) {
@@ -6738,7 +6738,7 @@
n = -1;
/* Now search the history. */
- while (n-- && (he = quietgethist(i--))) {
+ while (n-- && he) {
int iwords;
for (iwords = 0; iwords < he->nwords; iwords++) {
h = he->text + he->words[iwords*2];
@@ -6754,6 +6754,7 @@
if (hpatsav)
*e = hpatsav;
}
+ he = up_histent(he);
}
}
if ((t = cc->mask & (CC_ARRAYS | CC_INTVARS | CC_ENVVARS | CC_SCALARS |
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: 3.1.6-pws-4: Re: simulation of dabbrev-expand
1999-09-18 19:59 ` PATCH: 3.1.6-pws-4: " Bart Schaefer
@ 1999-09-22 22:21 ` Adam Spiers
0 siblings, 0 replies; 11+ messages in thread
From: Adam Spiers @ 1999-09-22 22:21 UTC (permalink / raw)
To: zsh-workers
Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> } > On Sep 9, 1:39pm, Adam Spiers wrote:
> } > } Subject: simulation of dabbrev-expand
> } > }
> } > } 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.
>
> I'm finally able to reproduce something like this.
[...]
> The problem is in zle_tricky.c's use of quietgethist(). With Wayne's new
> stuff, the history list may have holes in it, but makecomplistflags() is
> trying to iterate over the history by calling quietgethist() on consecutive
> integers until it returns nothing -- which happens whenever it encounters
> such a hole.
Ahhh! Of course! I had looked at quietgethist() but never twigged
about the holes.
> I think the patch below should take care of this part, but it's possible
> that I've done more than was necessary; in particular, the hist.c hunk
> may not be needed: it might suffice to call the original quietgethist()
> before the loop in makecomplistflags(). It's also possible that calling
> up_histent() N times is the wrong thing to do: Should the number passed
> to compgen -H specify the number of history entries searched or the range
> of history numbers searched? I've interpreted it as the former.
I think that's a sensible choice.
[snip patch]
Bart, you're a hero. This bug has been er, bugging me for ages.
Together with Sven's nice duplicate removing options we can finally
have the dabbrev-expand behaviour which up till now has been the only
aspect of zsh I've found inferior to any other shell. Great work guys :-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: simulation of dabbrev-expand
@ 1999-09-20 8:40 Sven Wischnowsky
1999-09-20 22:00 ` Adam Spiers
0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 1999-09-20 8:40 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: simulation of dabbrev-expand
1999-09-20 8:40 Sven Wischnowsky
@ 1999-09-20 22:00 ` Adam Spiers
0 siblings, 0 replies; 11+ messages in thread
From: Adam Spiers @ 1999-09-20 22:00 UTC (permalink / raw)
To: zsh-workers
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: simulation of dabbrev-expand
@ 1999-09-21 7:20 Sven Wischnowsky
1999-09-22 0:03 ` Adam Spiers
0 siblings, 1 reply; 11+ messages in thread
From: Sven Wischnowsky @ 1999-09-21 7:20 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: simulation of dabbrev-expand
1999-09-21 7:20 Sven Wischnowsky
@ 1999-09-22 0:03 ` Adam Spiers
0 siblings, 0 replies; 11+ messages in thread
From: Adam Spiers @ 1999-09-22 0:03 UTC (permalink / raw)
To: zsh-workers
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: simulation of dabbrev-expand
@ 1999-09-21 7:28 Sven Wischnowsky
0 siblings, 0 replies; 11+ messages in thread
From: Sven Wischnowsky @ 1999-09-21 7:28 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: simulation of dabbrev-expand
@ 1999-09-22 14:11 Sven Wischnowsky
1999-09-22 14:57 ` Zefram
1999-09-22 22:13 ` Adam Spiers
0 siblings, 2 replies; 11+ messages in thread
From: Sven Wischnowsky @ 1999-09-22 14:11 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: simulation of dabbrev-expand
1999-09-22 14:11 Sven Wischnowsky
@ 1999-09-22 14:57 ` Zefram
1999-09-22 22:13 ` Adam Spiers
1 sibling, 0 replies; 11+ messages in thread
From: Zefram @ 1999-09-22 14:57 UTC (permalink / raw)
To: Sven Wischnowsky; +Cc: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: simulation of dabbrev-expand
1999-09-22 14:11 Sven Wischnowsky
1999-09-22 14:57 ` Zefram
@ 1999-09-22 22:13 ` Adam Spiers
1 sibling, 0 replies; 11+ messages in thread
From: Adam Spiers @ 1999-09-22 22:13 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~1999-09-22 22:21 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <19990909133913.A30055@thelonious.new.ox.ac.uk>
[not found] ` <990909171104.ZM15814@candle.brasslantern.com>
[not found] ` <19990916173409.A17932@thelonious.new.ox.ac.uk>
1999-09-17 21:44 ` simulation of dabbrev-expand Adam Spiers
1999-09-18 19:59 ` PATCH: 3.1.6-pws-4: " Bart Schaefer
1999-09-22 22:21 ` Adam Spiers
1999-09-20 8:40 Sven Wischnowsky
1999-09-20 22:00 ` Adam Spiers
1999-09-21 7:20 Sven Wischnowsky
1999-09-22 0:03 ` Adam Spiers
1999-09-21 7:28 Sven Wischnowsky
1999-09-22 14:11 Sven Wischnowsky
1999-09-22 14:57 ` Zefram
1999-09-22 22:13 ` Adam Spiers
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).