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