9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] The VT saga
@ 2000-09-11  9:41 lucio
  2000-11-07 14:32 ` Micah Stetson
  0 siblings, 1 reply; 9+ messages in thread
From: lucio @ 2000-09-11  9:41 UTC (permalink / raw)
  To: 9fans; +Cc: lucio

[-- Attachment #1: Type: text/plain, Size: 3698 bytes --]

On Sun, Sep 10, 2000 at 19:05:36 (+0200), Lucio De Re wrote:
> 
> I see there's another point of confusion.  It seems that after
> resizing (I used hide-and-restore, at first, but actual resizing
> has a similar effect), the emulator reports three columns more
> than are actually represented.
> 
I eventually tracked that one down to some wishful thinking in SSH: at
resize time, the screen text dimensions are computed directly from the
screen bitsize, which omits the margin and border values.

In the process of determining where the problem lay and how to fix it,
I changed a few bits in VT that may or may not have needed changing.
I _think_ the result is tidier, but I may have fidgetted with things
that would have been best left alone.

The rationale was that constant "INSET" could easily be identified
with "Borderwidth" (defined in draw.h) and could thus be dismissed - I
left the definition in "cons.h", but it can be removed.  I also
decided that the screen area should include the borderwidth and
simplified the "r.max" assignment accordingly, the new version is
practically identical to the original in spirit.

If opening "/dev/wctl" or writing to it does not work - note that I
removed the Borderwidth offset from the "fprint()" - then presumably
VT is expected to draw its own border, where, again "Borderwidth"
seems a useful replacement for "INSET" (I appreciate - or, better,
don't appreciate :-) - that "INSET" has value "3" while "Borderwidth"
has value "4").  More to ensure that we don't make mistakes (redundant
occurrences of constants can lead to errors, here 79/80 and 23/24 are
involved) I caused "xmax" and "ymax" to be re-evaluated.  Its only
real advantage is that now the menu entry values need to be changed in
one place (well, OK, two places).  I suppose I should go to the
trouble of calculating that first menu entry from two compile-time
constants, it would not be hard.

I did that, too, please be gentle with the criticism, I'm sure I
haven't quite got Bell Labs' philosophy down pat :-)

The changes in SSH are also pretty minute.  The rationale here is that
the environment should be queried instead of calculating the text
dimensions of the screen on resizing the window (which also occurs
when the window is restored from a HIDE command).  There is already a
facility to query the environment with a default value in the SSH
code, so it was easy to rope that into the task, thus changing things
as little as possible.

Unfortunately, that did not quite suffice, in fact it caused some
hassles, as it managed to query the environment _before_ VT got around
to changing it (VT does a deferred "resize()" rather than respond
immediately).

I added a 200ms delay between reading the "/dev/wctl" device and
notifying the remote host of the change.  I'm not sure if the
deferring in VT may linger beyond this limit, in which case it may be
essential to do deferred processing of window resizing (ouch, that
would be a bit painful!)  in SSH as well.

I take it (on faith, I haven't tested this) that the undocumented
operation of "/dev/wclt" on READ is to return the current dimension of
the window then block until a window change occurs.  I think that is
remarkably elegant: the simplicity with which one can handle window
resizing in such a situation is a thing of beauty, a masterpiece,
(insert own superlatives here)...

I see it is documented in the newer rio(4) man page; my admiration to
the inventor.

I include the changes, wdiffs based on the July 17th release, to
/sys/src/cmd/VT and /sys/src/cmd/SSH for inspection and inclusion (if
so desired) in the next release.

++L


[-- Attachment #2: Type: message/rfc822, Size: 2295 bytes --]


diff -n /mnt/wrap/sys/src/cmd/vt/main.c /sys/src/cmd/vt/main.c
/mnt/wrap/sys/src/cmd/vt/main.c:8 a /sys/src/cmd/vt/main.c:9,11
> #define		LINES	(24)		/* menu selection */
> #define		COLS	(80)
> 
/mnt/wrap/sys/src/cmd/vt/main.c:462 a /sys/src/cmd/vt/main.c:466
> 	char buf[12];
/mnt/wrap/sys/src/cmd/vt/main.c:464 a /sys/src/cmd/vt/main.c:469,470
> 		snprint (buf, sizeof(buf), "%dx%d", LINES, COLS);
> 		menu3.item[0] = buf;
/mnt/wrap/sys/src/cmd/vt/main.c:470 c /sys/src/cmd/vt/main.c:476
< 		case 0:		/* 24x80 */
---
> 		case 0:		/* LINESxCOLS */
/mnt/wrap/sys/src/cmd/vt/main.c:472,474 c /sys/src/cmd/vt/main.c:478
< 			r.max = addpt(screen->r.min,
< 				Pt(80*CW+2*XMARGIN+2*INSET,
< 				24*NS+2*YMARGIN+2*INSET));
---
> 			r.max = addpt(r.min, Pt(COLS*CW+2*(XMARGIN+Borderwidth), LINES*NS+2*(YMARGIN+Borderwidth)));
/mnt/wrap/sys/src/cmd/vt/main.c:476,479 c /sys/src/cmd/vt/main.c:480,486
< 			if(fd < 0 || fprint(fd, "resize -dx %d -dy %d\n", Dx(r)+2*Borderwidth, Dy(r)+2*Borderwidth) < 0){
< 				border(screen, r, INSET, bordercol, ZP);
< 				xmax = 79;
< 				ymax = 23;
---
> 			if(fd < 0 || fprint(fd, "resize -dx %d -dy %d\n", Dx(r), Dy(r)) < 0){
> 				// r.max = addpt(r.max, Pt(Borderwidth, Borderwidth));
> 				border(screen, r, Borderwidth, bordercol, ZP);
> 				// xmax = 79;
> 				// ymax = 23;
> 				xmax = (Dx(screen->r)-2*XMARGIN)/CW-1;
> 				ymax = (Dy(screen->r)-2*YMARGIN)/NS-1;
/mnt/wrap/sys/src/cmd/vt/main.c:577 c /sys/src/cmd/vt/main.c:584
< 	draw(screen, Rpt(pt(0, dy), pt(xmax+1, ly-sy)), screen, nil, pt(0, sy));
---
> 	draw(screen, Rpt(pt(0, dy), pt(xmax+1, ly+1)), screen, nil, pt(0, sy));
diff -n /mnt/wrap/sys/src/cmd/ssh/cmd/client_io.c /sys/src/cmd/ssh/cmd/client_io.c
/mnt/wrap/sys/src/cmd/ssh/cmd/client_io.c:302 a /sys/src/cmd/ssh/cmd/client_io.c:303
> 		sleep (200);
diff -n /mnt/wrap/sys/src/cmd/ssh/cmd/client_messages.c /sys/src/cmd/ssh/cmd/client_messages.c
/mnt/wrap/sys/src/cmd/ssh/cmd/client_messages.c:507,508 c /sys/src/cmd/ssh/cmd/client_messages.c:507,508
< 	putlong(packet, height/cheight);	/* rows */
< 	putlong(packet, width/cwidth);	/* columns */
---
> 	putlong(packet, lines = int_env("LINES", height/cheight));	/* rows */
> 	putlong(packet, cols = int_env("COLS", width/cwidth));	/* columns */

^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: [9fans] The VT saga
@ 2000-11-10 14:37 presotto
  0 siblings, 0 replies; 9+ messages in thread
From: presotto @ 2000-11-10 14:37 UTC (permalink / raw)
  To: 9fans

I have your diff but I seem to have misplaced your previous
version.  Want to send me a pointer?


^ permalink raw reply	[flat|nested] 9+ messages in thread
* Re: [9fans] The VT saga
@ 2000-11-08 22:57 presotto
  2000-11-09  4:27 ` Lucio De Re
  0 siblings, 1 reply; 9+ messages in thread
From: presotto @ 2000-11-08 22:57 UTC (permalink / raw)
  To: 9fans

if you and lucio can agree on a version, I stick it in the distribution.


^ permalink raw reply	[flat|nested] 9+ messages in thread
* [9fans] The VT saga
@ 2000-09-10 16:25 Lucio De Re
  2000-09-10 16:37 ` Lucio De Re
  0 siblings, 1 reply; 9+ messages in thread
From: Lucio De Re @ 2000-09-10 16:25 UTC (permalink / raw)
  To: 9fans mailing list

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2000-11-10 14:37 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-09-11  9:41 [9fans] The VT saga lucio
2000-11-07 14:32 ` Micah Stetson
  -- strict thread matches above, loose matches on Subject: below --
2000-11-10 14:37 presotto
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-09-10 16:25 Lucio De Re
2000-09-10 16:37 ` Lucio De Re

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).