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?