Another completion-time screen refresh bug

Another completion-time screen refresh bug

[Bart Schaefer]

With this style:
zstyle ':completion:*' completer _all_matches _complete _match _approximate

If, in the zsh source tree, I type:

schaefer<528> rm <TAB>

I get the following output, with the cursor on the SECOND line:

schaefer<528> rm  
Completing filrm
Src/                  LICENCE               Doc/                
ChangeLog             CVS/                  Misc/               
Completion/           config.sub*           Functions/          
stamp-h.in            config.guess*         StartupFiles/       
configure*            INSTALL               ChangeLog-3.1       
autom4te-2.53.cache/  Makefile.in           ChangeLog.3.0       
configure.ac          README                mkinstalldirs*      
Util/                 config.h.in           install-sh*         
Test/                 config.h.in\~         aclocal.m4          
Etc/                  aczsh.m4                                  
Config/               META-FAQ                                  
Completing all matches
Src ChangeLog Completion stamp-h.in configure autom4te-2.53.cache configure. ...


Note that the final line there after "Completing all matches" is exactly as
wide as the terminal.  The line editor obviously has missed that the cursor
wrapped to the next line at that point, and didn't emit enough "up" motions.
(There is only one line after "Completing all matches", beware of your mail
program displaying it wrapped.)

Re: Another completion-time screen refresh bug

[Geoff Wing]

Bart Schaefer <schaefer@brasslantern.com> output in workers/19714:
:With this style:
:zstyle ':completion:*' completer _all_matches _complete _match _approximate
:
:If, in the zsh source tree, I type:
:schaefer<528> rm <TAB>
:I get the following output, with the cursor on the SECOND line:
:
:schaefer<528> rm  
:Completing filrm
...
:Completing all matches
:Src ChangeLog Completion stamp-h.in configure autom4te-2.53.cache configure. ...

I can't reproduce this anymore (though I think I could at the time).
Was it fixed or did it just go away or can people still reproduce it (and
provide steps from "zsh -f")

I can't reproduce workers/19587 either (don't remember if I could previously).

Regards,
Geoff

Re: Another completion-time screen refresh bug

[Bart Schaefer]

On Tue, 13 Jul 2004, Geoff Wing wrote:

> Bart Schaefer <schaefer@brasslantern.com> output in workers/19714:
> :With this style:
> :zstyle ':completion:*' completer _all_matches _complete _match _approximate
> :
> :If, in the zsh source tree, I type:
> :schaefer<528> rm <TAB>
> :I get the following output, with the cursor on the SECOND line:
> :
> :schaefer<528> rm  
> :Completing filrm
> ...
> :Completing all matches
> :Src ChangeLog Completion stamp-h.in configure autom4te-2.53.cache configure. ...
> 
> I can't reproduce this anymore (though I think I could at the time).
> Was it fixed or did it just go away or can people still reproduce it (and
> provide steps from "zsh -f")

I believe it's dependent on the width of and/or number of lines in the 
listing.  When Oliver and PWS rearranged the NEWS file etc. into the top 
level directory, they eliminated the conditions necessary to reproduce it. 
It's rather tricky to construct by hand a listing that reproduces the 
effect; I haven't managed to do so.

> I can't reproduce workers/19587 either (don't remember if I could 
> previously).

This one I can reproduce as follows:

zsh -f
autoload -U compinit
compinit -D
zstyle ':completion:*' completer \
    _oldlist _expand _complete _match _ignored _approximate _prefix
zstyle ':completion:*' format '%SCompleting %U%d%u%s'

and then enter "egrefoo" and TAB twice on the "f", as described in 19587.

Interestingly, the display remains wrong even after ^R (redisplay).  This 
bug may be related to 19714, and both may, I suppose, be related to the 
use of %S/%s and %U/%u in the format string ...

Re: Another completion-time screen refresh bug

[Bart Schaefer]

On Mon, 12 Jul 2004, Bart Schaefer wrote:

> bug may be related to 19714, and both may, I suppose, be related to the 
> use of %S/%s and %U/%u in the format string ...

Nope, %S and %U are red herrings; take them out, same thing still happens.  
Perhaps it has something to do with an empty group?

Re: Another completion-time screen refresh bug

[Geoff Wing]

Bart Schaefer <schaefer@brasslantern.com> output:
:On Tue, 13 Jul 2004, Geoff Wing wrote:
:> Bart Schaefer <schaefer@brasslantern.com> output in workers/19714:
:I believe it's dependent on the width of and/or number of lines in the 
:listing.

I was decrementing my term width and couldn't reproduce it.  I'll try
with some other directories.

:> I can't reproduce workers/19587 either (don't remember if I could 
:> previously).
:This one I can reproduce as follows:
[...snipped instructions...]
:and then enter "egrefoo" and TAB twice on the "f", as described in 19587.

Can't reproduce it with that and the four permutations of vanilla zsh-4.2.0,
zsh-4.2.0-dev-1 (from today), & rxvt and xterm 4.3.99.903(184).  Sits on ``f''

g% egrefoo
Completing `external command', `builtin command', `shell function', `alias', `su
ffix alias', `reserved word', `job', `parameter', or `corrections'

Putting term width at 73 gives two full lines, still works.  Widths of 72, 74,
145, 146 & 147 (and 80) also work.  I wonder what else is involved.

Regards,
Geoff

Re: Another completion-time screen refresh bug

[Bart Schaefer]

On Tue, 13 Jul 2004, Geoff Wing wrote:

> Bart Schaefer <schaefer@brasslantern.com> output:
> :On Tue, 13 Jul 2004, Geoff Wing wrote:
> :> Bart Schaefer <schaefer@brasslantern.com> output in workers/19714:
> :I believe it's dependent on the width of and/or number of lines in the 
> :listing.
> 
> I was decrementing my term width and couldn't reproduce it.  I'll try
> with some other directories.

It may also be dependent on my zstyle settings; I haven't managed to get
it to happen with "zsh -f" yet.

> :> I can't reproduce workers/19587 either (don't remember if I could 
> :> previously).
> :This one I can reproduce as follows:
> [...snipped instructions...]

I just realized I missed out one line of the instructions:

setopt completeinword

If you don't first get from "egrefoo" to "egrepfoo" the bug won't occur.

Re: Another completion-time screen refresh bug

[Geoff Wing]

Bart Schaefer <schaefer@brasslantern.com> output:
:I just realized I missed out one line of the instructions:
:setopt completeinword

:If you don't first get from "egrefoo" to "egrepfoo" the bug won't occur.

Even better is also adding "setopt menucomplete".  First tab goes to
"egrepfoo", second tab goes to "egrepxfoo" with duplication.
zsh-4.0.6 does similar stuff but doesn't reprint the line so you end
up one line down but it ``appears'' empty.

I'm still looking into this.

Regards,
Geoff

Re: Another completion-time screen refresh bug

[Geoff Wing]

Tracked down to Src/Zle/compresult.c:printlist():2027-2028
This seems wrong - it's a near copy of compprintlist() (or the
other way around) but it doesn't necessarily make sense here.
Printing the new line only makes sense _after_ printing other
stuff which is OK in compprintlist() where there are possibly
multiple sets of lists & explanations to print.  Don't know if
this is the case here.

I don't (want to) understand this section.  I'm thinking that
those lines should be ripped out though maybe it should be
something like the following.  Anybody (besides Sven) looked
through this code before?

Regards,
Geoff

--- Src/Zle/compresult.c	2004-07-13 04:31:41.000000000 +1000
+++ Src/Zle/compresult.c	2004-07-15 15:40:41.000000000 +1000
@@ -1855,8 +1855,7 @@
 	if (tccan(TCCLEAREOD))
 	    tcout(TCCLEAREOD);
     }
-    g = amatches;
-    while (g) {
+    for (g = amatches; g; g = g->next) {
 	char **pp = g->ylist;
 
 	if ((e = g->expls)) {
@@ -2023,10 +2022,10 @@
 			    p = skipnolist(p + 1, showall);
 		}
 	    }
-	}
+	} else
+	    continue;
 	if (g->lcount || (showall && g->mcount))
 	    pnl = 1;
-	g = g->next;
     }
     lastlistlen = 0;
     if (clearflag) {