Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site cornell.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!cornell!jqj
From: jqj@cornell.UUCP
Newsgroups: net.emacs
Subject: emacs under flow control
Message-ID: <2899@cornell.UUCP>
Date: Thu, 4-Jul-85 10:25:21 EDT
Article-I.D.: cornell.2899
Posted: Thu Jul  4 10:25:21 1985
Date-Received: Sat, 6-Jul-85 09:31:36 EDT
Sender: jqj@cornell.UUCP
Organization: Cornell Univ. CS Dept.
Lines: 25

From: jqj (J Q Johnson)

This question is specifically oriented towards GNU emacs, but is applicable
to all Emacs-like editors; it's been raised before.  The question:  what
does one do if he has to support Emacs in a flow-controlled environment?

One could of course take the attitude (as does, for example, RMS) that
XON-XOFF is a total loss and that no effort should be put into dealing with
it.  I don't have that luxury; our environment involves lots of terminals
in a complex local networking and terminal concentration topology, where
on many lines flow control cannot successfully be disabled.  So my choices
are either not to support GNU emacs or to support a flow controlled version.

But what to do about default key bindings?  The easiest solution would be
to map some underutilized input characters to ^Q and ^S at a low level.  
Perhaps ^\ => ^Q and ^] => ^S.  Unfortunately, this would mean that ^\ and ^] 
would be unavailable for their former functions.  An alternative is wholesale
reoganization of the command set to reassign the functions normally invoked
by ^S, ESC-^S, etc.  This has the disadvantage of requiring modification to
almost every package and mode (e.g. some implementations of incremental search
have hardwired '\^q' as quote character).

What have other sites done when faced with this problem?  Has any standard
arisen?  How many users would scream "bloody murder" if ^\ were mapped on
input to ^Q and ^] to ^S?