[no subject]

[Mark L. Miller <MILLER at MIT-AI>]

Dear Jonl,
I have been trying to understand your reply to my msg ...

    Date: 9 JAN 1980 2128-EST
    From: JONL at MIT-MC (Jon L White)

From:         MILLER@MIT-AI
Date: Sun, 1 Sep 80 11:36:28 GMT
Original-Date: 01/09/80 07:36:28 EDT
Subject: Re:  SUPER-IMAGE Output
    	There ought to be a way to OPEN a TTY file in "SUPER-IMAGE" mode, or a
        builtin "RAWTYO" function.  These would, on ITS, prefix any special
        characters with a control-P...

    I believe that the idea of the CURSORPOS function was to abstract out the
    various "terminal hacking stuff", and refer to them as symbolic arguments
    (or numeric positions) to CURSORPOS.  Indeed, the maclisp implementation 
    of CURSORPOS does the appropriate "lock-out" so that control-p codes are
    not separated from the preceeding control-P.  Shouldn't you do that too?
    namely, just add to the code for CURSORPOS in the midas listing?

I am not sure if I am misunderstanding your point, but it seems like you are
oversimplifying the problem here.  The user of LISP ought to be able -- when
necessary -- to do anything he could do from MIDAS, directly from LISP.  For
example, send strange escape codes if he knows what he is doing.  It is just
not possible for the clever author of CURSORPOS to anticipate all possible
cases and make them totally device independent.  Consider the case of what I
was actually doing: driving a printer from the auxiliary port of a CRT where
both the printer and the CRT were variable entities and where different
instantiations required different protocols.  You might add a (cursorpos 'aux)
feature, say, but then what about a terminal like a C100 which can have
many devices strung off of it on DIFFERENT aux ports?  Striving for generality
and terminal independence is nice, but sometimes you have to be allowed to
get a bit crufty to get the job done...           Regards, Mark