9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] The VT saga
Date: Sun, 10 Sep 2000 18:25:00 +0200	[thread overview]
Message-ID: <20000910182500.A4897@cackle.proxima.alt.za> (raw)

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



             reply	other threads:[~2000-09-10 16:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-10 16:25 Lucio De Re [this message]
2000-09-10 16:37 ` Lucio De Re
2000-09-11  9:41 lucio
2000-11-07 14:32 ` Micah Stetson
2000-11-08 22:57 presotto
2000-11-09  4:27 ` Lucio De Re
2000-11-10  1:05   ` Micah Stetson
2000-11-10  4:14     ` Lucio De Re
2000-11-10 14:37 presotto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000910182500.A4897@cackle.proxima.alt.za \
    --to=lucio@proxima.alt.za \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).