From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sun, 10 Sep 2000 18:25:00 +0200
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Message-ID: <20000910182500.A4897@cackle.proxima.alt.za>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [9fans] The VT saga
Topicbox-Message-UUID: 05a53986-eac9-11e9-9e20-41e7f4b1d025

There was no follow up on VT implementation errors.  I fixed one of
these, leaving two for some other occasion.

This one was particular annoying as it caused progressively smaller
portions of the screen to get updated, the closer one got to the middle
of the screen, the more obvious its effect became.

In /sys/src/cmd/vt/main.c, the draw() call in scroll() has ly-sy
as the endpoint of the scrolled rectangle.  It should instead be
ly+1.  I'm not sure how the ly-sy got in there, but it does explain
the effect mentioned above.  As you scroll the bottom of the screen
from locations progressively closer to the middle (by either deleting
or inserting a line), the effect is diminished by the "-sy" factor,
where "sy" is y-coordinate of the line at which scroll is intended
to start.  Scroll should not occur at all, when the source line is
below the middle (I'm not going to try this, it seems consistent with
my recollections).

I can't seem to be able to pinpoint where clearing to end of line
fails.  It seems responsible for the bottom line not being cleared,
but apparently only when it is the only line being cleared.  I'd
hazard that it is precisely when _one_ line is being zapped that the
process fails, it is coincidental that this is most obvious on the
bottom line, wait a minute...

Yep, it's the clear to EOP that needs fixing (maybe - opinion sought
on this): in vt.c, I took the "+1" out of the clear to EOP start
point, and the problem seems to have been cured: MUTT now removes the
status line once it no longer applies.

That leaves a lingering highlight: in "less", the filename is highlit
at the end of the first screen; pressing space causes the highlight to
be applied to the line next displayed _over_ the "prompt".  Pity this
is not a feature :-) as it makes a nice indicator of where the
previous screen ended (does anyone remember which NetNews reader - was
it TIN? - used underline to this end?), unfortunately, it affects
trailing highlights in a somewhat arbitrary fashion.

++L