Date: 13 Mar 1986 12:49:33 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Re: XON XOFF and EMACS
To: mcvax!delphi!mdc@seismo.ARPA
Cc: KFL@MIT-MC.ARPA, DEVON@MIT-MC.ARPA, rms@MIT-PREP.ARPA

  From: mcvax!delphi!mdc@seismo.CSS.GOV
  Date: Thu, 13 Mar 86 13:47:42 MET
  To: Dan Hoey <hoey@nrl-aic.ARPA>

    1.  Sending ^P^S/^P^Q doesn't work very cleanly, because your terminal
     may want to do flow control between ^P and the following character.

  I agree.
  May be the flow control strategies of the terminal/device driver
  can avoid the problem, if they do some form of look ahead.

I think it is a bad idea to infer data based on timing.  This locks
you out of interesting communications possiblities like networks,
error-correcting modems, etc.  Each step of the communications chain
may be passing XONs and XOFFs back and forth, and some of them are
sure to come right after the ^P.

    You need some sort of sequence that avoids ^S and ^Q entirely.

  So ^Q and ^S can be substituted only with other ASCII chars.
  And the problem is there again .

Not so!  For instance, have (keyboard) Control-S send (ascii) ESC ' S,
C-Q send ESC ' Q, and the Esc key send ESC ' [ if you like.  There's
plenty of space in ASCII code, you just need to usurp another
character.  The reason I have chosen ESC here is that it has already
been usurped by ANSI escape sequences.  (I think these sequences ' are
unused and follow the form of the standard, but there are many more
available if I am wrong.)  The terminal driver can then use ^S and ^Q
for flow control, convert the above escape sequences into ^S/^Q/ESC,
and pass all other escape sequences transparently to the application.
Another possibility is to have the other escape sequences converted
into some sort of magic cookie to signify the function key that was
pressed.

The driver should also be able to optionally pass a magic cookie to
indicate the XON/XOFF flow control.  This is so that the application
program can know that it's output is stopped, and possibly avoid
queueing more stuff up.  This is important when the application is
TELNET or some other virtual terminal program.  There are a bunch more
interesting cookies that could be sent from the driver, like ``user is
flushing output, don't bother to format it'' or ``user wants to talk
to TELNET, rather than through it''.  There has been work in designing
transparent protocols for this stuff, but most terminal drivers and
most keyboards aren't smart enough.

Dan