jqj@cornell.UUCP (07/04/85)
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?
root@bu-cs.UUCP (Barry Shein) (07/06/85)
>Subject: emacs under flow control >Date: Thu, 4-Jul-85 10:25:21 EDT >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? > >... > >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? At Boston University we run an Ungermann/Bass broadband terminal network (you might at Cornell also if I remember correctly) and *yes*, the network assumes it owns ^S/^Q for flow control and things like mismatched ends (eg. all of our hosts are 9600, even if you come in at 1200.) Also ^P (DLE) and ^T is not very good either (^T<CR> is the default hangup tho this is user settable.) We have so far attacked this with a vengeance (not just with EMACS.) The first thing I did was 'fix' all that when I got my source copy of CCA Emacs, first making it use CBREAK correctly (current versions do, this was quite a while ago) and then re-binding keys all over the place. The big problems was when these chars were magically embedded in the software (like a check for a ^S directly in ^R Incremental Search rather than via the current binding), this sort of stuff kept haunting us (tho again, the latest CCA version seems to fix about everything, I think all I needed was to install my Keys files and we were done.) Now we are doing the same with GNU emacs, trying to use similar bindings. Yes, ^\ and ^] seem to be good replacement candidates for ^S/^Q (funny, of course we chose the exact opposite order you did.) I think it is not a major issue so long as the designers/coders keep to their 'promise' that every command is re-bindable and just kinda keep it in the back of their mind as they implement. Yes, it would be nice if there were a note for a 'standard' re-binding for flow controlled sites. I suspect this does come up quite a bit and will come up more so in the future. The real nuisance is not EMACS (which has a well worn path for fixing this) but things like XMODEM and UUCP especially people with binary only XMODEM versions for their PCs and look at us like we just killed their pet dog when we try to explain the problem. I try to give them Kermit for free if they ask. Again, it's not a huge issue but, to appeal to egos, a truly sophisticated software designer would take this kind of thing into account. Yes, let's standardize a flow controlled key bindings and try to use it. A choice of two with a mention in the manual should calm down users. Some things just aren't worth fighting, clever software adapts where it can. -Barry Shein, Boston University
wombat@ccvaxa.UUCP (07/06/85)
We had the same problem here (our terminal concentrator eats ^s and ^q), so most people unbind ^s and ^q and rebind their functions to other keys in their .emacs_pro files. The default bindings within emacs itself were left alone. As problems were noticed in system mlisp packages, we rebound things there (so everybody doesn't have to get their own copy and change the bindings). I haven't heard any complaints since we got the last ^s out of rmail. This is with a Gosling emacs; we haven't gotten around to porting GNUmacs to the Gould machines yet, so I don't know if we can get away with the same sort of thing, but I would think we could. "When you are about to die, a wombat is better than no company at all." Roger Zelazny, *Doorways in the Sand* Wombat ihnp4!uiucdcs!ccvaxa!wombat
sasaki@harvard.ARPA (Marty Sasaki) (07/06/85)
Harvard has Sytek's Localnet 20 which is severely brain damaged with
regards to flow control. If you have xon/xoff flow control enabled,
when you type an xon the local network card stops output to your
terminal and also sends the xon to the host. This means that even if
you wanted to, you couldn't do flow control right and still have
things bound to control-S.
Most of the hosts that are connected to Localnet run at 2400 baud, and
I run my terminal at 9600 baud. I turn flow control off on my local
network card, and turn it off on my terminal (vt102) as well. On very
rare occasions I will lose characters.
--
----------------
Marty Sasaki net: sasaki@harvard.{arpa,uucp}
Havard University Science Center phone: 617-495-1270
One Oxford Street
Cambridge, MA 02138daveb@rtech.UUCP (Dave Brower) (07/08/85)
> Now we are doing the same with GNU emacs, trying to use similar > bindings. Yes, ^\ and ^] seem to be good replacement candidates for > ^S/^Q (funny, of course we chose the exact opposite order you did.) I have seen just plain '\' used for the quote character, which fits nicely with the shell and the standard 'C' convention. I have also used M-/ as the forward search command, for (god-forbid) compatibility for vi users. Since I can't easily explain why 'search' isn't ctrl-s, using something standard for something seemed appropriate. > Yes, let's standardize a flow controlled key bindings and try to use it. > A choice of two with a mention in the manual should calm down users. Let's here some more proposals and conduct a poll. -dB -- {amdahl|dual|sun|zehntel}\ {ucbvax|decvax}!mtxinu---->!rtech!daveb ihnp4!{phoenix|amdahl}___/
sasaki@harvard.ARPA (Marty Sasaki) (07/08/85)
Substitute "xon" with "xoff" in my previous message about Sytek and flow
control where that makes sense. Sometimes I make stupid mistakes, usually
I manage to catch them before they go world-wide. Oh well...
--
----------------
Marty Sasaki net: sasaki@harvard.{arpa,uucp}
Havard University Science Center phone: 617-495-1270
One Oxford Street
Cambridge, MA 02138dick@tjalk.UUCP (Dick Grune) (07/08/85)
Modifying and adapting all existing programs to use ^\ for ^S on even days and for ^Q on odd days is a finite job, but doing the same for all incoming sources is a never-ending story. And don't tell me programmers should write their code to avoid the problem. Perhaps they should, but most of them won't. Many just know that a terminal is a 7-bit channel and have never seen anything else. It seems to me that the real problem lies with the 6.8-bit channel (ASCII-128 minus ^Q, ^S, ^P, ^T and ^@, or so). So I propose another Golden Rule: If a channel preempts some characters, it should provide reasonable means to transmit these characters anyway. In this case that could mean that any sequence typed as ^]X would arrive as the right-most five bits of X. For this to work, it should be in the terminal driver, which is doing funny things with NL/CR already. This is probably easier said than done, but it is a one-time finite job, and will work for all programs to come. Dick Grune Vrije Universiteit de Boelelaan 1081 1081 HV Amsterdam the Netherlands
lmcl@ukc.UUCP (L.M.McLoughlin) (07/08/85)
1) Flow control. I hacked (ie: attacked with a meat cleaver) GNUemacs
to add the function "flow". This resets the screen to run it in
cbreak mode with intrc turned off and startc/stopc set to their original
values (this was for INTERRUPT_INPUT).
Users can then add there own keyboard-translate-table to map what they
like to fill in for the missing C-S and C-Q (I use C-\ and C-])
You also have to be carefull when checking the result of select. Sometimes
it will return due to the arrival of a ^s/^q.
If there is any real interest I could post the diff's.
2) On the subject of posting diffs. I've GNU Emacs running on a machine with:
unsigned characters only
unsigned bitfields only
essentially word based
no alloca
address of first arg != an array of all args
a very strict C compiler
BSD 4.1 (I think shell in a window works OK now)
I won't claim to have all the bugs out but they are few (and
peculiar).
I've tried contacting RMS via mail but my messages seem to black hole
between here and mit-prep (I don't even get rejections).
My fixes are for 15.34, would there be any objections to me posting them
to this group? Or can RMS mail suggest an alternate path to him.hugh@hcrvx1.UUCP (Hugh Redelmeier) (07/08/85)
In article <466@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: >> ... Has any standard >>arisen? How many users would scream "bloody murder" if ^\ were mapped on >>input to ^Q and ^] to ^S? > >... Yes, ^\ and ^] seem to be good replacement candidates for >^S/^Q (funny, of course we chose the exact opposite order you did.) > >... Yes, it would be nice if >there were a note for a 'standard' re-binding for flow controlled sites. >I suspect this does come up quite a bit and will come up more so in the >future. I whole-heartedly agree about a standard. Jove uses ^^ as a substitute for ^Q, and ^\ for ^S. I am now used to this, but I think it is a mistake: ^S is a very useful function, but ^\ is hard on touch-typists because it is on different places on different keyboards. I have suggested to jove-hackers that ^] be used in place of ^\, but the response has been luke-warm. I think that they, like RMS, consider the problem to be with the terminals.
chris@umcp-cs.UUCP (Chris Torek) (07/09/85)
More Gosmacs flow control: Spencer Thomas had some stuff that allowed Xon/Xoff flow control to work while inside Emacs. I put it in my stuff and it got out to UniPress, and I think mg has put it in. (mg is busy cleaning up all the bugs, so UniPress may have a stable release out soon.) The way it works is that you (setq xon/xoff-flow-control 1) in your .emacs_pro (or in Globalpro.ml) to make ^S and ^Q do flow control things. (This *must* be done before the first call to the display code; .emacs_pro's suffice as long as you also do it before any (send-string-to-terminal)s.) The neat thing about this is that it only affects those who want it. If you don't set xon/xoff-flow-control, Emacs uses TIOCSETC to turn off the flow controlness. (You have to use TIOCSETC even if you use RAW, since 4.2 (and 4.3) BSD rlogin has a strange hack that notices this. And besides, I also put in something that lets you set half-baked-input to get 7-bit input with ^G doing interrupts, instead of making it a compile time option, so if you have that on the TIOCSETC is required too....) Of course you still have to figure out where to bind the search keys. Sigh. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
zrm@prism.UUCP (07/09/85)
Regrading Emacs and flow control: Beware the DEC vt220. Is is just slightly slower than a vt100 so carefully crafted Emacs padding incites them to send ^S. After sending ^S, the vt200 LOCKS THE KEYBOARD! It won't let you do anything until you type ^Q! The things are clearly the product of some warped vi fan.
martillo@mit-athena.UUCP (Joaquim Martillo) (07/09/85)
There is a problem with tty_pty.c which prevents raw mode notification to be passed to the local side of an rlogin connection. I have a fix for this if anyone is interested.
guy@sun.uucp (Guy Harris) (07/10/85)
> Modifying and adapting all existing programs to use ^\ for ^S on even > days and for ^Q on odd days is a finite job, but doing the same for all > incoming sources is a never-ending story. And don't tell me programmers > should write their code to avoid the problem. Perhaps they should, but most > of them won't. Many just know that a terminal is a 7-bit channel and have > never seen anything else. I don't know of any programs running under UNIX other than EMACS which assume that a user typing at a keyboard can send a ^S or ^Q to the program. (UUCP assumes an 8-bit raw datapath, but that's different.) Any program written for any DEC operating system that makes that assumption is going to fail unless it puts the terminal path into 8-bit passall mode, so such programs are probably unlikely under RT-11, RSX-11, RSTS, VMS, TOPS-[12]0, etc. You don't have to do that job for all incoming sources; most programmers don't write code that runs into the problem. > In this case that could mean that any sequence typed as ^]X would arrive > as the right-most five bits of X. For this to work, it should be in the > terminal driver, which is doing funny things with NL/CR already. > > This is probably easier said than done, but it is a one-time finite job, > and will work for all programs to come. Putting it into the terminal driver won't help. Such a solution is in the 4.xBSD terminal driver (^V is a super-quote), but that doesn't do any good if you're using a flow-controlled network to talk to your machine and the ^S/^Q disappears before it even gets to the host. Given the number of such networks, it is a finite job but not an easy one (you'll have to convince all those vendors to permit you to either disable flow control or escape the flow control characters). If more such networks appear, it's not even guaranteed to be a one-time finite job (although the rate of increase in the number of such networks might be less than the rate of increase in the number of programs which actually care whether they can receive a ^S or ^Q or not). Guy Harris
sasaki@harvard.ARPA (Marty Sasaki) (07/11/85)
The news on the Sytek Localnet isn't all bad. You can specify an
arbitrary pair of characters instead of xon and xoff for flow
control. If you are fortunate enough to have a terminal like the Ann
Arbor Ambassador, you can even change it's flow control characters,
and if you are running on UNIX you can tell UNIX about your new flow
control characters.
If you had a terminal that would let you turn xon/xoff flow control
on and off via an escape sequence, then you could modify EMACS to
turn flow control off when it starts up, and turn it back on when you
finish. Your only problem would be to get a termcap entry with enough
padding.
There is also EIA flow control, but that requires smart MUX boards
and more wires in your terminal cables.
I unfortunately have a vt102 which can't do anything that I want in
this regard and have to use VMS systems which can't remap any
character functions.
--
----------------
Marty Sasaki net: sasaki@harvard.{arpa,uucp}
Havard University Science Center phone: 617-495-1270
One Oxford Street
Cambridge, MA 02138jacobson@fluke.UUCP (David Jacobson) (07/11/85)
> I have seen just plain '\' used for the quote character, which fits > nicely with the shell and the standard 'C' convention. For users doing document preparations with TeX or LaTex '\' is probably among the 5 most frequently used characters. Making '\' the quote character would mean having to remember to strike it twice every time you wanted one. I don't object to the extra keystrokes as much as the ease of forgetting, which winds up just leaving out the '\'. -- David Jacobson
jje@pedsgd.UUCP (Jeremy Epstein) (07/12/85)
(The following is excerpted from a longer discussion): > ...I don't know of any programs running under UNIX other than EMACS which > assume that a user typing at a keyboard can send a ^S or ^Q to the program. > (UUCP assumes an 8-bit raw datapath, but that's different.) ... > > Guy Harris A number of applications programs such as spreadsheets, word processing programs, etc. use ^S and ^Q. These programs seem to come from PC environments, where (I guess) ^S and ^Q don't have their usual meanings. --Jeremy Epstein Perkin-Elmer {decvax,ucbvax}!vax135!petsd!pedsgd!jje
jqj@cornell.UUCP (J Q Johnson) (07/12/85)
A previous posting notes the problem of VT220 vs VT100 padding. This is, in fact, a more general problem. There are dozens of emulators for VT100s (and many emulators for other popular terminals). Each has its own padding requirements, but since they all have the same command set one typically uses the same "terminal type" to describe them to the operating system. So if you're using padding instead of flow control and want to be truly pessimal, you have to pad for the worst case of the worst case emulation, which can be VERY VERY slow (example: scrolling on one of the 60-line VT100 emulators like the Ergo8000 or even worse on a graphics terminal like the VT241). Don't get me wrong--I'd rather have big buffers in terminals or some oob flow control, and am not a fan of ^S/^Q; still, ^S/^Q does have its advantages. So, I'm not going to junk my flow controlled hardware, and AM going to continue to use Emacs. I'm still waiting for a consensus to develop on character remaping. So far, my impression is that most people feel that remapping ^\ to ^S and ^] to ^Q (or vice versa) is superior to ad hoc function reassignments and to using other character sequences. Until the consensus develops (keep those comments coming!) I strongly recommend that Emacs package designers NOT bind functions to ^\ or ^].
joe@emacs.uucp (Joe Chapman) (07/12/85)
<> I've not run into flow control problems while using the vt220 with CCA EMACS. You can set the point at which the vt220 decides to send an XOFF in the communications setup menu; if you set this to ``No XOFF'' it'll just hum right along. (Usenet public spirit over commercial considerations dept.: This also works with the Unipress/Gosling edition of Emacs.) (Disclaimer: I personally believe that the DEC vt220 is not a terminal to be tossed aside lightly. It should be thrown with great force.) -- -- Joseph Chapman decvax!cca!emacs!joe CCA Uniworks, Inc. emacs!joe@cca-unix.ARPA 20 William St. Wellesley, MA 02181 (617) 235-2600