From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 21 Aug 1995 19:42:36 -0400
From: forsyth@plan9.cs.york.ac.uk forsyth@plan9.cs.york.ac.uk
Subject: Set User (aka su)
Topicbox-Message-UUID: 19c0d03e-eac8-11e9-9e20-41e7f4b1d025
Content-Type: text/plain; charset=UTF-8
Message-ID: <19950821234236.oDNQSvAu0TxHS20k28faARJyiIU0f2D9VU7WQC_ptPs@z>

>>done in fifty bytes of code in 81/2, scrolls awfully slowly
>>and does not handle resizing properly.

hmmmm, all right.  show me that code (and it's not as though i'm from Missouri).

the thing that many people want from hp -- support for the
ESC-based cursor addressing schemes -- is the bulk of hp's source code.
furthermore, the people who want that here are rarely satisfied
by hp -- they wt more more more cursor addressing codes --
specifically support for either VT320 or PC `ANSI' escape sequences.
that requires somewhat more than the code in hp.
i've been looking at this recently, so i've had to read lots of vt220 emulators,
the vt/pc emulator in the linux kernel, etc.  i don't accept this statement
at all.

also, the scrolling in hp is slow because it makes no attempt to be fast.
it has little to do with the fact that it is working as a client of 8½.
(after all, Sun's EEPROM has the screen mapped, and did you ever see
the display and scrolling time on that in the older Sparcs.  whew!)

>>made user interface incoherent (can't call sam in the same
>>window as telnet!)

i do not understand how support for cursor addressing makes the user interface
`coherent' on any of the systems that support this archaic crud.
sam is usable in an X11 xterm only because it makes a separate call back to the terminal to produce something that isn't an xterm.

there is incoherence in the plan 9 user interface, because there are several.
most obviously, the mouse handling conventions in Acme are different from those elsewhere;
perhaps the conventions will eventually converge again at a new limit.
at least it is an interesting diversion.