ZLE scrolly bugfix

ZLE scrolly bugfix

[Zefram]

-----BEGIN PGP SIGNED MESSAGE-----

This patch fixes a couple of problems in the new refresh code.
If the cursor gets onto the last line of the screen and there's
more text off the bottom of the screen, it's possible to have the
cursor over the <.... marker when it's really in the text hidden
under that.  Also, the cursor doesn't go onto the last position on
the screen properly on a terminal that moves the cursor onto the
next line as soon as something is written to the last column.

I fix both of these problems by having refresh() avoid putting
the cursor on the last line if possible.  If there's no more text,
obviously, it can't avoid putting the cursor there, but then it's
not a problem.

 -zefram

      Index: Src/zle_refresh.c
      ===================================================================
      RCS file: /home/zefram/usr/cvsroot/zsh/Src/zle_refresh.c,v
      retrieving revision 1.6
      diff -c -r1.6 zle_refresh.c
      *** zle_refresh.c	1996/07/16 14:27:04	1.6
      --- zle_refresh.c	1996/07/17 09:54:46
      ***************
      *** 148,158 ****
        {						\
            *s = '\0';					\
            if (++ln == winh)				\
      ! 	if (nvln != -1) {			\
      ! 	    ln--;		/* too eager */	\
        	    break;				\
      ! 	} else 					\
        	    ln = scrollwindow(0);		\
            if (!nbuf[ln])				\
        	nbuf[ln] = (char *)zalloc(winw + 1);	\
            s = (unsigned char *)nbuf[ln];		\
      --- 148,160 ----
        {						\
            *s = '\0';					\
            if (++ln == winh)				\
      ! 	if (nvln != --ln && nvln != -1)		\
        	    break;				\
      ! 	else {					\
        	    ln = scrollwindow(0);		\
      + 	    if(nvln != -1)			\
      + 		nvln -= winh - ln;		\
      + 	}					\
            if (!nbuf[ln])				\
        	nbuf[ln] = (char *)zalloc(winw + 1);	\
            s = (unsigned char *)nbuf[ln];		\
      ***************
      *** 599,606 ****
        
        	/* deleting characters - see if we can find a match series that
        	   makes it cheaper to delete intermediate characters
      ! 	   eg. oldline: hifoobar } hopefully cheaper here to delete two
      ! 	       newline: foobar	 } characters, then we have six matches */
        
        	    if (tccan(TCDEL) && nl[1] && ol[1] && (ol[1] != nl[1])) {
        		for (i = 0, p1 = ol; *p1; p1++, i++)
      --- 601,608 ----
        
        	/* deleting characters - see if we can find a match series that
        	   makes it cheaper to delete intermediate characters
      ! 	   eg. oldline: hifoobar \ hopefully cheaper here to delete two
      ! 	       newline: foobar	 / characters, then we have six matches */
        
        	    if (tccan(TCDEL) && nl[1] && ol[1] && (ol[1] != nl[1])) {
        		for (i = 0, p1 = ol; *p1; p1++, i++)

Part of this patch was brought to you by the Campaign for Real Braces[tm].

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMey6x3D/+HJTpU/hAQHZGQQAm30xD+zwAG0ZBw9GJB8H6jf86cBwZrPC
gfrI3vAsVd2wpkWPqMmzkO0brqtjqOfrqVEsCjMFe1Fkgk3O3mh8Wp1S40z7xWfS
7WphIk49qoqA4cGDsxZTdgCFWWsnq7IE4DedMfRLEsny0ex34kwdmc4xptMf/D5S
bQQqREBbUXQ=
=np0q
-----END PGP SIGNATURE-----

Re: ZLE scrolly bugfix

[Geoff Wing]

Zefram wrote:
:If the cursor gets onto the last line of the screen and there's
:more text off the bottom of the screen, it's possible to have the
:cursor over the <.... marker when it's really in the text hidden
:under that.  Also, the cursor doesn't go onto the last position on
:the screen properly on a terminal that moves the cursor onto the
:next line as soon as something is written to the last column.
:I fix both of these problems by having refresh() avoid putting
:the cursor on the last line if possible.  If there's no more text,
:obviously, it can't avoid putting the cursor there, but then it's
:not a problem.

Yep, these are bugs.  However the patch doesn't fix these properly.
In  nextline, if  nvln == winh - 1 (or --ln as you put it), then 
you would still need to scroll one line and adjust nvln.
I'll look at this (after I get some sleep).
I was thinking about breaking up scrollwindow() into scroll a single
line and scroll a half screen.

And for Zoltan and others who want to use zed to edit their stuff
and want half window scrolls, chuck "local BAUD=2400" at the top
somewhere.  Other refresh styles will have to wait till after zsh 3.0
-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"

Re: ZLE scrolly bugfix

[Zefram]

>Yep, these are bugs.  However the patch doesn't fix these properly.
>In  nextline, if  nvln == winh - 1 (or --ln as you put it), then 
>you would still need to scroll one line and adjust nvln.

That's exactly what the patch does, unless I'm misunderstanding you.
The patched code reads:

            if (++ln == winh)				\
      ! 	if (nvln != --ln && nvln != -1)		\
        	    break;				\
      ! 	else {					\
        	    ln = scrollwindow(0);		\
      + 	    if(nvln != -1)			\
      + 		nvln -= winh - ln;		\
      + 	}					\

The changed behaviour is that if we've reached the end of the screen,
we scroll UNLESS the cursor position is on screen (nvln != -1) AND it's
not on the last line (nvln != --ln).  It's that last part that's
changed -- previously it only scrolled if the cursor position wasn't
yet on screen.  The adjustment of nvln is also new -- previously it
just wasn't required, as we could never scroll with the cursor position
on screen.

Actaully, knowing how it works, that patch looks trivially simple.  Not
much to show for an hour's hacking.

>I was thinking about breaking up scrollwindow() into scroll a single
>line and scroll a half screen.

Not necessary.  The single scrolling function is perfectly adequate --
the code that calls it has no need to know how much it will scroll by.

>And for Zoltan and others who want to use zed to edit their stuff
>and want half window scrolls, chuck "local BAUD=2400" at the top
>somewhere.  Other refresh styles will have to wait till after zsh 3.0

I have to say, single-line scrolling at 9600 baud isn't great.  But
it's good to have the choice.

Anyway, for 3.1 I'd rather like `lazy' scrolling -- only scroll when
the cursor is moved to the top or bottom of the screen.  We already
have this for SINGLE_LINE_ZLE, though of course it's much simpler
there.  It would mean some fairly radical changes to some of the
refresh code, so it's probably not a good idea right now.

-zefram

Re: ZLE scrolly bugfix

[Geoff Wing]

:Actaully, knowing how it works, that patch looks trivially simple.  Not
:much to show for an hour's hacking.

Sorry, I didn't patch it properly.  Works fine (in my quick check of the
previous problem)

:I have to say, single-line scrolling at 9600 baud isn't great.  But
:it's good to have the choice.

The 9600 was an arbitrary choice.  It should probably be higher: 19200
or 38400.

:Anyway, for 3.1 I'd rather like `lazy' scrolling -- only scroll when
:the cursor is moved to the top or bottom of the screen.  We already
:have this for SINGLE_LINE_ZLE, though of course it's much simpler
:there.  It would mean some fairly radical changes to some of the
:refresh code, so it's probably not a good idea right now.

The current problem with that sort of thing is the refresh code would
need to know that the line hasn't changed radically since the last change,
eg. with ^P (up-line-or-history), ^R (history-incremental-search-backward)
type commands.  With most editors, this is implicit - the file isn't going
to change in this way.
-- 
Mason [G.C.W]  mason@werple.mira.net.au    "Hurt...Agony...Pain...LOVE-IT"