Returned mail

[MAILER-DAEMON@iss.southafrica.NCR.COM MAILER-DAEMON@iss.southafrica.NCR.COM]

Your mail could not be delivered because of the following reason:


   ----- Transcript of session follows -----
Executing: /usr/lib/mail/surrcmd/smtpqer -B -C -u iss.SouthAfrica.NCR.COM!ncrlnk!ncrhub4!ncrgw1!cse.psu.edu!9fans capetown.SouthAfrica.ATTGIS.COM lynna@capetown.SouthAfrica.ATTGIS.COM
smtpqer: Binary contents cannot be sent via SMTP
server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1

   ----- Unsent message follows -----
>From ncrhub4!ncrgw1!cse.psu.edu!9fans Mon Aug 21 21:04 EDT 1995 remote from ncrlnk
Received: by ncrlnk.DaytonOH.NCR.COM; 21 Aug 95 21:04:13 EDT
Received: by ncrhub4.ATTGIS.COM; 21 Aug 95 21:04:36 EDT
Received: by ncrgw1.ATTGIS.COM; 21 Aug 95 20:58:20 EDT
Received: by colossus.cse.psu.edu id <45512>; Mon, 21 Aug 1995 20:30:26 -0400
Received: from plan9.cs.york.ac.uk ([144.32.33.120]) by colossus.cse.psu.edu with SMTP id <45552>; Mon, 21 Aug 1995 20:14:27 -0400
From:	forsyth@plan9.cs.york.ac.uk
To:	9fans@cse.psu.edu
Date:	Mon, 21 Aug 1995 19:42:36 -0400
Subject: Re: Set User (aka su)
Message-Id: <95Aug21.201427edt.45552@colossus.cse.psu.edu>
Sender: owner-9fans@cse.psu.edu
Precedence: bulk
Reply-To: 9fans@cse.psu.edu

>>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 8B=.
(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.