* Re: bug with completion (after 15 oct?)
@ 2000-10-25 8:17 Sven Wischnowsky
2000-10-25 10:24 ` Geoff Wing
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 2000-10-25 8:17 UTC (permalink / raw)
To: zsh-workers
Geoff Wing wrote:
> ...
>
> # then do
> ls ba<TAB><CTRL-U>ls ba<TAB><CTRL-U>ls ba<TAB>
> # core dump
Aha. It didn't find out that it had a new list. The patch adds a
counter counting how often we have invalidated a completion list and
then uses that counter to find out if the list displayed is the same
as before.
Bye
Sven
Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.35
diff -u -r1.35 complist.c
--- Src/Zle/complist.c 2000/10/24 07:50:24 1.35
+++ Src/Zle/complist.c 2000/10/25 08:17:03
@@ -986,7 +986,7 @@
static int
compprintlist(int showall)
{
- static int lasttype = 0, lastbeg = 0, lastml = 0;
+ static int lasttype = 0, lastbeg = 0, lastml = 0, lastinvcount = -1;
static int lastn = 0, lastnl = 0, lastnlnct = -1;
static Cmgroup lastg = NULL;
static Cmatch *lastp = NULL;
@@ -999,7 +999,7 @@
int lastused = 0;
mfirstl = -1;
- if (mnew || lastbeg != mlbeg || mlbeg < 0) {
+ if (mnew || lastinvcount != invcount || lastbeg != mlbeg || mlbeg < 0) {
lasttype = 0;
lastg = NULL;
lastexpl = NULL;
@@ -1010,6 +1010,7 @@
lines - nlnct - mhasstat : listdat.nlines) - (lastnlnct > nlnct);
lastnlnct = nlnct;
mrestlines = lines - 1;
+ lastinvcount = invcount;
if (cl < 2) {
cl = -1;
Index: Src/Zle/compresult.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/compresult.c,v
retrieving revision 1.26
diff -u -r1.26 compresult.c
--- Src/Zle/compresult.c 2000/10/24 07:50:25 1.26
+++ Src/Zle/compresult.c 2000/10/25 08:17:03
@@ -30,6 +30,12 @@
#include "complete.mdh"
#include "compresult.pro"
+/* This counts how often the list of completions was invalidated.
+ * Can be used to detect if we have a new list. */
+
+/**/
+mod_export int invcount;
+
#define inststr(X) inststrlen((X),1,-1)
/* This cuts the cline list before the stuff that isn't worth
@@ -1264,6 +1270,8 @@
mod_export int
calclist(int showall)
{
+ static int lastinvcount = -1;
+
Cmgroup g;
Cmatch *p, m;
Cexpl *e;
@@ -1271,10 +1279,12 @@
int max = 0, i;
VARARR(int, mlens, nmatches + 1);
- if (listdat.valid && onlyexpl == listdat.onlyexpl &&
+ if (lastinvcount == invcount &&
+ listdat.valid && onlyexpl == listdat.onlyexpl &&
menuacc == listdat.menuacc && showall == listdat.showall &&
lines == listdat.lines && columns == listdat.columns)
return 0;
+ lastinvcount = invcount;
for (g = amatches; g; g = g->next) {
char **pp = g->ylist;
@@ -2089,6 +2099,7 @@
mod_export int
invalidate_list(void)
{
+ invcount++;
if (validlist) {
if (showinglist == -2)
zrefresh();
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug with completion (after 15 oct?)
2000-10-25 8:17 bug with completion (after 15 oct?) Sven Wischnowsky
@ 2000-10-25 10:24 ` Geoff Wing
0 siblings, 0 replies; 6+ messages in thread
From: Geoff Wing @ 2000-10-25 10:24 UTC (permalink / raw)
To: zsh-workers
Sven Wischnowsky <wischnow@informatik.hu-berlin.de> typed:
:Geoff Wing wrote:
:Aha. It didn't find out that it had a new list. The patch adds a
:counter counting how often we have invalidated a completion list and
:then uses that counter to find out if the list displayed is the same
:as before.
OK, if that's what you committed, then here's the next quirk:
(continuation from same situation as before)
% ls ba<TAB><TAB><TAB><TAB><TAB>
# gives
% ls bar bar bar
# when I think it should still be cycling between them. I'll have to
# check the setopt's I gave but historically it would. Of course, it
# doesn't coredump :-) So that's better!
Regards,
Geoff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug with completion (after 15 oct?)
@ 2000-10-25 10:51 Sven Wischnowsky
0 siblings, 0 replies; 6+ messages in thread
From: Sven Wischnowsky @ 2000-10-25 10:51 UTC (permalink / raw)
To: zsh-workers
Geoff Wing wrote:
> ...
>
> OK, if that's what you committed, then here's the next quirk:
> (continuation from same situation as before)
>
> % ls ba<TAB><TAB><TAB><TAB><TAB>
> # gives
> % ls bar bar bar
> # when I think it should still be cycling between them. I'll have to
> # check the setopt's I gave but historically it would. Of course, it
> # doesn't coredump :-) So that's better!
Ouch. There is now a cleanup-redisplay which should only be called
conditionally. It cleared `noselect', making the following tests fail.
Bye
Sven
Index: Src/Zle/complist.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v
retrieving revision 1.36
diff -u -r1.36 complist.c
--- Src/Zle/complist.c 2000/10/25 08:18:45 1.36
+++ Src/Zle/complist.c 2000/10/25 10:51:02
@@ -2270,7 +2270,12 @@
menucmp = 2;
showinglist = -2;
minfo.asked = 0;
- zrefresh();
+ if (!noselect) {
+ int nos = noselect;
+
+ zrefresh();
+ noselect = nos;
+ }
}
if (!noselect && (!dat || acc)) {
showinglist = -2;
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug with completion (after 15 oct?)
2000-10-25 7:14 Sven Wischnowsky
@ 2000-10-25 7:49 ` Geoff Wing
0 siblings, 0 replies; 6+ messages in thread
From: Geoff Wing @ 2000-10-25 7:49 UTC (permalink / raw)
To: zsh-workers
Sven Wischnowsky <wischnow@informatik.hu-berlin.de> typed:
:Geoff Wing wrote:
:Does that mean that amatches is garbled at that point?
No, amatches had some information. From memory, had some
sort of valid information so did ->next , ->next->next was NULL.
This is what I'm currently down to: this is stuff ripped out of my zshrc
though maybe slightly rearranged (the extra stuff in there is because
some is shared with 3.0.x startup) - but I can reproduce it with this
on the second or third go - if the second succeeds it'll also put my
cursor one line too high.
% zsh.new -f
% PROMPT=
_compdir=/usr/local/share/zsh/${ZSH_VERSION}/functions
[[ -z $fpath[(r)$_compdir] ]] && fpath=($fpath $_compdir)
autoload -U compinit
compinit
autoloadflag=-U
zstyle '*' completer _complete _correct _approximate
[[ -n "$fpath" ]] && for dir in $fpath; do [[ -d $dir ]] && autoload $autoloadflag $dir/*~*/_*(N.:t); done
zstyle ':completion:*' format '--> completing %d'
zstyle ':completion:*' menu select=1
setopt menu_complete
unsetopt always_last_prompt
# then do
ls ba<TAB><CTRL-U>ls ba<TAB><CTRL-U>ls ba<TAB>
# core dump
Regards,
--
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff : <gcw@zsh.org>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: bug with completion (after 15 oct?)
@ 2000-10-25 7:14 Sven Wischnowsky
2000-10-25 7:49 ` Geoff Wing
0 siblings, 1 reply; 6+ messages in thread
From: Sven Wischnowsky @ 2000-10-25 7:14 UTC (permalink / raw)
To: zsh-workers
Geoff Wing wrote:
> Heyla,
> am currently investigating a bug with completion which manifested in the
> last week or so:
>
> % zsh.new -f
> % cd /tmp; mkdir foo; cd foo; touch bar baz
> % ls ba<TAB> # <TAB><RETURN> or CTRL-U or whatever
> bar baz
> % ls ba<TAB> # OK
> % exit
> % zsh.new
> % cd /tmp
> % ls ba<TAB> # <TAB><RETURN> or CTRL-U or whatever
> --> completing file
> bar baz
> % ls ba<TAB>
> zsh: 20301 segmentation fault (core dumped) zsh.new
>
> A backtrace gives the following - maybe it's useful to someone - but I'll
> try to narrow it down to a set of initialisation options.
> Hmm, what's worse is that a version compiled --disable-dynamic sometimes
> gives a segv a bit later (line 1034).
Sigh. Of course I couldn't reproduce that.
> 0x80af60b in compprintlist (showall=0) at complist.c:1023
> 1023 char **pp = g->ylist;
> (gdb) p *lastg
> $1 = {name = 0x0, prev = 0x0, next = 0x2, flags = 135607944, mcount = 2,
> matches = 0x0, lcount = 0, llcount = 1, ylist = 0x8157fc8, ecount = 0,
> expls = 0x0, ccount = 0, lexpls = 0x0, lmatches = 0x0, lfmatches = 0x1,
> lallccs = 0x0, num = 0, nbrbeg = 0, nbrend = 2, new = 2, dcount = 1,
> cols = 6, lins = 0, width = 12, widths = 0x6, totl = 0, shortest = 80,
> perm = 0x0}
Does that mean that amatches is garbled at that point?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug with completion (after 15 oct?)
@ 2000-10-24 14:33 Geoff Wing
0 siblings, 0 replies; 6+ messages in thread
From: Geoff Wing @ 2000-10-24 14:33 UTC (permalink / raw)
To: zsh-workers
Heyla,
am currently investigating a bug with completion which manifested in the
last week or so:
% zsh.new -f
% cd /tmp; mkdir foo; cd foo; touch bar baz
% ls ba<TAB> # <TAB><RETURN> or CTRL-U or whatever
bar baz
% ls ba<TAB> # OK
% exit
% zsh.new
% cd /tmp
% ls ba<TAB> # <TAB><RETURN> or CTRL-U or whatever
--> completing file
bar baz
% ls ba<TAB>
zsh: 20301 segmentation fault (core dumped) zsh.new
A backtrace gives the following - maybe it's useful to someone - but I'll
try to narrow it down to a set of initialisation options.
Hmm, what's worse is that a version compiled --disable-dynamic sometimes
gives a segv a bit later (line 1034).
0x80af60b in compprintlist (showall=0) at complist.c:1023
1023 char **pp = g->ylist;
(gdb) p *lastg
$1 = {name = 0x0, prev = 0x0, next = 0x2, flags = 135607944, mcount = 2,
matches = 0x0, lcount = 0, llcount = 1, ylist = 0x8157fc8, ecount = 0,
expls = 0x0, ccount = 0, lexpls = 0x0, lmatches = 0x0, lfmatches = 0x1,
lallccs = 0x0, num = 0, nbrbeg = 0, nbrend = 2, new = 2, dcount = 1,
cols = 6, lins = 0, width = 12, widths = 0x6, totl = 0, shortest = 80,
perm = 0x0}
(gdb) bt
#0 0x80af60b in compprintlist (showall=0) at complist.c:1023
#1 0x80b0e6a in complistmatches (dummy=0x80dc2f4, dat=0xbfbfd504)
at complist.c:1575
#2 0x8072666 in runhookdef (h=0x80dc2f4, d=0xbfbfd504) at module.c:1835
#3 0x80ad4d8 in list_matches (dummy=0x80df6e4, dummy2=0x0)
at compresult.c:2080
#4 0x8072666 in runhookdef (h=0x80df6e4, d=0x0) at module.c:1835
#5 0x80c309a in zrefresh () at zle_refresh.c:607
#6 0x80b2817 in domenuselect (dummy=0x80dc2b8, dat=0xbfbfd654)
at complist.c:2271
#7 0x807263f in runhookdef (h=0x80dc2b8, d=0xbfbfd654) at module.c:1829
#8 0x80a09f2 in after_complete (dummy=0x80df720, dat=0xbfbfd6b4)
at compcore.c:496
#9 0x8072666 in runhookdef (h=0x80df720, d=0xbfbfd6b4) at module.c:1835
#10 0x80c6236 in docomplete (lst=0) at zle_tricky.c:786
#11 0x80c54d7 in expandorcomplete (args=0x80df674) at zle_tricky.c:282
#12 0x80c520d in completecall (args=0x80df674) at zle_tricky.c:176
#13 0x80be7d9 in execzlefunc (func=0x80dd620, args=0x80df674) at zle_main.c:655
#14 0x80be4d1 in zleread (lp=0x80ed4d0 "%b%s%u%m:%B%3c%b%# %B",
rp=0x80ed428 "%b%?:2:%h:%l %B%D{%R}%b", flags=3) at zle_main.c:567
#15 0x806519f in inputline () at input.c:265
#16 0x80650e1 in ingetc () at input.c:210
#17 0x805f8f5 in ihgetc () at hist.c:236
#18 0x80689f7 in gettok () at lex.c:628
#19 0x8068346 in yylex () at lex.c:344
#20 0x80786c6 in parse_event () at parse.c:425
#21 0x8062f56 in loop (toplevel=1, justonce=0) at init.c:123
#22 0x8064e6f in zsh_main (argc=1, argv=0xbfbfd85c) at init.c:1197
#23 0x804a6e6 in main (argc=1, argv=0xbfbfd85c) at ./main.c:37
#24 0x804a491 in ___start ()
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-10-25 10:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-10-25 8:17 bug with completion (after 15 oct?) Sven Wischnowsky
2000-10-25 10:24 ` Geoff Wing
-- strict thread matches above, loose matches on Subject: below --
2000-10-25 10:51 Sven Wischnowsky
2000-10-25 7:14 Sven Wischnowsky
2000-10-25 7:49 ` Geoff Wing
2000-10-24 14:33 Geoff Wing
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).