BUG? in histreduceblanks in 3.1.2-beta

BUG? in histreduceblanks in 3.1.2-beta

[Andrej Borsenkow]

I have problems with latest 3.1.2-beta (probably it existed before as
well).  Try to enter long command (separated with \NL to get around tty
buffer length limit). If I now try scroll backward (I use standard emacs
keymap, where cursor keys are bound to up/down-line-or-history), the
display is almost completely broken. If I try to scroll several times,
thing get even worse. Example is: 


bor@itsrm1:~/test/zsh%> zsh -f
bor@itsrm1:~/test/zsh%> setopt histreduceblanks
bor@itsrm1:~/test/zsh%> aaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
> aaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
> aaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
> aaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
> aaaaaaaaaaaaaa
zsh: command not found: aaaaaa

So far so good. Now up-line-or-history:

bor@itsrm1:~/test/zsh%> aaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaa
aaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaa aaa

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaa aaaaaaaaaaaaa

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaa

Now it is a mess - it is not even possible to tell, how much lines I have.
Once more up-line-or-history:

bor@itsrm1:~/test/zsh%> aaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaa
aaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaa aaa
                        setopt histreduceblanks
                                               ^ cursor here
Oooops! If you try more up/downs, things get even worse.

I don't have previous version handy, but I have the feeling, that error
was not there. Term I use have size 24x80 (with so far correct terminfo).

Without histreduceblanks all is O.K. - I get exactly the same history
event as was input.

thanks

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Re: BUG? in histreduceblanks in 3.1.2-beta

[Andrej Borsenkow]

It is even worse - it happens also in vanilla zsh -f (and probably has
nothing to do with histreduceblanks - or these are two different
problems).

So, here follows:

bor@itsrm1:~/tmp%> zsh -f

Contents of history (three events):
                    [1] =>
bor@itsrm1:~/tmp%> gzcat /muenchen/packages/tcl/tcl7.6p2.patch.gz | sed -e 'y/a/
a/' | pg
                    [2] =>
bor@itsrm1:~/tmp%> gzcat /muenchen/packages/tcl/tcl7.6p2.patch.gz | sed -e 'y/a/
a/' -e 'y/b/b/'
                    [3] =>
bor@itsrm1:~/tmp%> gzcat /muenchen/packages/tcl/tcl7.6p2.patch.gz | sed -e 'y/a/
a/' -e 'y/b/b/' -e 'y/c/c/'

Now I press ^R (inclremental-search backward) and 'gzca':

bor@itsrm1:~/tmp%> gzcat /muenchen/packages/tcl/tcl7.6p2.patch.gz | sed -e 'y/a/
a/' -e 'y/b/b/' -e 'y/c/c/'
                   ^ <= cursor is here on the above line; this line is blank
bck-i-search: gzca_

Now I press ^R once more (while in incremental search) - so far nothing
happens; I press onse more:

bor@itsrm1:~/tmp%> gzcat /muenchen/packages/tcl/tcl7.6p2.patch.gz | sed -e 'y/a/
a/' -e 'y/b/b/' -e 'y/c/c/'
    | pg
bck-i-search: gzca_

Cursor is still on the second line. 

I am pretty shure, it didn't happen before 3.1.2 - I use search every now
and then. 

Thanks in advance

-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Refresh problem (Was: BUG? in histreduceblanks in 3.1.2-beta)

[Andrej Borsenkow]

On Fri, 13 Jun 1997, Andrej Borsenkow wrote:

I think, Zefram is right - te problem has something to do with "am"
capability. Here is the example of input and what ZSH outputs (catched
with truss):

the input:

bor@itsrm1:~%> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaa '
quote> bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbb '

I do return and then recall previous command. ZSH outputs:

write(10, 0x082FA92C, 212)                      = 212
   a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
   a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
   a a a a a a a a a a a a a a a a a a a a a a a a   '1B [ 0 K1B [
   0 m\r\n b b b b b b b b b b b b b b b b b b b b b b b b b b b b
   b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b
   b b b b b b b b b b b b b b b b b b b b\n b b b b b b b b b b b
   b b b b b b b b b b   '1B [ 0 K1B [ 0 m

Note, that the first line is output _without_ \n; but on the second line
ZSH outputs exactly 80 characters and then \n - if terminal really
implements "am", it gives you one more empty line.

The escapes output are (sorry, terminfo): "el" and "rmso"

It seems to be terminal-dependent, wether this effect happens. I tested on
4 terminal(emulations) - two vt-like,one ansi-like and xterm. Two have
this problem, two (including xterm) not.

hope it helps


-------------------------------------------------------------------------
Andrej Borsenkow 		Fax:   +7 (095) 252 01 05
SNI ITS Moscow			Tel:   +7 (095) 252 13 88

NERV:  borsenkow.msk		E-Mail: borsenkow.msk@sni.de
-------------------------------------------------------------------------

Refresh patch (Was: Refresh problem)

[Geoff Wing]

Andrej Borsenkow <borsenkow.msk@sni.de> typed:
:On Fri, 13 Jun 1997, Andrej Borsenkow wrote:
:bor@itsrm1:~%> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
:aaaaaaaaaaaaaaaaaaaaaaa '
:quote> bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
:bbbbbbbbbbbbbbbbbbbbbbbbbbbb '
:
:write(10, 0x082FA92C, 212)                      = 212
:   a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
:   a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
:   a a a a a a a a a a a a a a a a a a a a a a a a   '1B [ 0 K1B [
:   0 m\r\n b b b b b b b b b b b b b b b b b b b b b b b b b b b b
:   b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b
:   b b b b b b b b b b b b b b b b b b b b\n b b b b b b b b b b b
:   b b b b b b b b b b   '1B [ 0 K1B [ 0 m

Very helpful.
Try this.  It's a patch against 3.0.4, but it should work with 3.1.2:


*** zle_refresh.c.org	Mon Jun 23 15:12:47 1997
--- zle_refresh.c	Thu Jul  3 12:02:34 1997
***************
*** 575,583 ****
  	if (nllen)
  	    strncpy(p1, nl, nllen);
  	memset(p1 + nllen, ' ', winw - nllen);
! 	p1[winw] = p1[winw + 1] = '\0';
  	if (ln && nbuf[ln])
! 	    strncpy(nl, p1, winw + 2);	/* next time obuf will be up-to-date */
  	else
  	    nl = p1;		/* don't keep the padding for prompt line */
  	nllen = winw;
--- 575,584 ----
  	if (nllen)
  	    strncpy(p1, nl, nllen);
  	memset(p1 + nllen, ' ', winw - nllen);
! 	p1[winw] = '\0';
! 	p1[winw + 1] = (nllen < winw) ? '\0' : nl[winw + 1];
  	if (ln && nbuf[ln])
! 	    memcpy(nl, p1, winw + 2);	/* next time obuf will be up-to-date */
  	else
  	    nl = p1;		/* don't keep the padding for prompt line */
  	nllen = winw;


-- 
Geoff Wing [mason@primenet.com.au]   Technical Manager
  Phone    : +61-3-9818 2977         PrimeNet - Internet Consultancy
  Facsimile: +61-3-9819 3788         Web : <URL:http://www.primenet.com.au/>
  Mobile   : 0412 162 441

Re: BUG? in histreduceblanks in 3.1.2-beta

[Zefram]

It is obviously a display bug, related to long lines, and nothing to do
with HIST_REDUCE_BLANKS.  I can reproduce it: it happens when some line
other than the first screen line wraps around.  So, if $COLUMNS is 20,
the following display will work OK:

% abcdefghijklmnopqr
stuvwxyz
more lines
that don't wrap

But this gets mangled:

% a short line
a longer line that d
oes wrap

The display is OK while the text is being typed, but some types of
refresh (including a complete redraw prompted by use of `redisplay')
will introduce extra blank lines and related phenomena.

Possibly relevant data point: the terminal on which I reproduced
this does have the :am: capability.  I also know that its termcap is
definitely correct.

-zefram

Re: BUG? in histreduceblanks in 3.1.2-beta

[Geoff Wing]

On 14 Jun 1997 02:57:06 +1000, Zefram <zefram@dcs.warwick.ac.uk> wrote:
:It is obviously a display bug, related to long lines, and nothing to do
:with HIST_REDUCE_BLANKS.  I can reproduce it: it happens when some line
:other than the first screen line wraps around.  So, if $COLUMNS is 20,
:the following display will work OK:

Yes, there are a couple of display bugs (damn it) that I'll be looking for
tomorrow.  One caused a coredump on me - but at least I've got the coredump
around still so I can debug it.
-- 
Geoff Wing [mason@primenet.com.au]   Technical Manager
  Phone    : +61-3-9818 2977         PrimeNet - Internet Consultancy
  Facsimile: +61-3-9819 3788         Web : <URL:http://www.primenet.com.au/>
  Mobile   : 0412 162 441