Re: ZLE scrolly bugfix

[Zefram <A.Main@xxxxxxxxxxxxxxxxx>]

>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