sqrkl@csvax.liv.ac.uk (07/06/88)
In article <23571@teknowledge-vaxc.ARPA>, mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: > > How fast does it (Maculator) go WITHOUT xon/xoff? Emacs uses ^S for > "incremental search", and ^Q for "quote" (to allow you to insert control > chars into your buffer). > I find it amazing that an editor (does Emacs deserve such an accolade ?) in these so-called modern times actually uses CTRL-Q and CTRL-S as commands. This has me dumbfounded (for a change !) and it serves anyone right who uses Emacs. All minis/mainframes I know of (no doubt there are exceptions) support XON/XOFF as a matter of course and you WOULD be foolish to run a terminal emulator at high speeds without XON/XOFF active. Richard K. Lloyd, ****** This is a VAX 11/780 running VAX/VMS V4.5 ****** Computer Science Dept., * JANET : SQRKL@UK.AC.LIV.CSVAX * Liverpool University, * UUCP : {backbone}!mcvax!ukc!mupsy!liv-cs!SQRKL * Merseyside, England, * Internet : SQRKL%csvax.liv.ac.uk@cunyvm.cuny.edu * Great Britain. ******************************************************* "My opinions and those of the University of Liverpool are completely unrelated, so I'M THE CULPRIT if you feel offended by the above message - I just can't help moaning about Atari STs, PCs or clones, U**X, C, IBM mainframes, the list is endless..."
cloos@batcomputer.tn.cornell.edu (James H. Cloos Jr.) (07/08/88)
In article <3918@csvax.liv.ac.uk> sqrkl@csvax.liv.ac.uk writes: |In article <23571@teknowledge-vaxc.ARPA>, | mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: |> |> How fast does it (Maculator) go WITHOUT xon/xoff? Emacs uses ^S for |> "incremental search", and ^Q for "quote" (to allow you to insert control |> chars into your buffer). |> |I find it amazing that an editor (does Emacs deserve such an accolade ?) |in these so-called modern times actually uses CTRL-Q and CTRL-S as commands. |This has me dumbfounded (for a change !) and it serves anyone right who |uses Emacs. All minis/mainframes I know of (no doubt there are exceptions) |support XON/XOFF as a matter of course and you WOULD be foolish to run a |terminal emulator at high speeds without XON/XOFF active. Furthermore, the thing everybody seems to be missing is that it is trivial to remap the functions that are at ^Q and ^S to other keys. ^\, ^`, and ^/ are some of the otherwise unbound keys that can be used to replace ^Q and ^S. Most of the Emacsen here at Cornell have default mapings that take into consideration the fact that ^Q and ^S are unavailable. The problem is not with Emacsen, but rahter with users/compilers who don't use the features of Emacsen such as user definable key bindings and compilation-time defineable default key bindings. -JimC -- batcomputer!cloos@cornell.UUCP |James H. Cloos, Jr.|#include <disclaimer.h> cloos@batcomputer.tn.cornell.EDU|B7 Upson, Cornell U|#include <cute_stuff.h> cloos@tcgould.tn.cornell.EDU |Ithaca, NY 14853 |"Entropy isn't what cloos@crnlthry.BITNET | +1 607 272 4519 | it used to be."
gillies@p.cs.uiuc.edu (07/08/88)
ORIGINAL emacs uses ^X^S for SAVE FILE! Ever hit ^S and waited 5
minutes for your file to save? After a while, you say, "geez, what's
taking emacs so long???", then you realize you just stopped screen
output! Talk about frustrating/confusing.
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gilliesjimc@iscuva.ISCS.COM (Jim Cathey) (07/08/88)
In article <3918@csvax.liv.ac.uk> sqrkl@csvax.liv.ac.uk writes: >I find it amazing that an editor (does Emacs deserve such an accolade ?) >in these so-called modern times actually uses CTRL-Q and CTRL-S as commands. >This has me dumbfounded (for a change !) and it serves anyone right who >uses Emacs. All minis/mainframes I know of (no doubt there are exceptions) >support XON/XOFF as a matter of course and you WOULD be foolish to run a >terminal emulator at high speeds without XON/XOFF active. I find it amazing that in these so-called modern times that everyone and their dog adopted Teletype's paper-tape reader control codes (DC1 and DC3) as flow control! Emacs (and related editors) have been around since before this widespread 'adoption'. Some of us object violently to the attitude that DC1 and DC3 _must_ be used for flow control even when we don't want them or need them. After all, not _all_ terminals are too damned slow to keep up at 9600 baud -- just DEC's! (Dare to tread where the ADM3 has been [19200 baud with no flow]! For the record, I've written a terminal emulator for a bit-mapped graphics machine of power O(mac) that keeps up just dandy at 9600 baud, and yes, I use it with Emacs daily.) Supporting XON/XOFF is one thing. Requiring it is another. The really sick thing about all this is the pervasiveness of the XON/XOFF/7-bit-only mindset -- to the point of some Ethernet connections being unable to be anything else. Witness rlogin (TCP/IP) over Ethernet. Suuuure you need XON/XOFF over a packetized, guaranteed delivery system. Better clear that high bit too -- it could be dangerous! +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ Member: Society For The Preservation Of Binary Comm Paths.
kennel@minnie.cognet.ucla.edu (Matthew Kennel) (07/09/88)
In article <3918@csvax.liv.ac.uk> sqrkl@csvax.liv.ac.uk writes: >In article <23571@teknowledge-vaxc.ARPA>, > mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) writes: >> >> How fast does it (Maculator) go WITHOUT xon/xoff? Emacs uses ^S for >> "incremental search", and ^Q for "quote" (to allow you to insert control >> chars into your buffer). >> >I find it amazing that an editor (does Emacs deserve such an accolade ?) >in these so-called modern times actually uses CTRL-Q and CTRL-S as commands. >This has me dumbfounded (for a change !) and it serves anyone right who >uses Emacs. All minis/mainframes I know of (no doubt there are exceptions) >support XON/XOFF as a matter of course and you WOULD be foolish to run a >terminal emulator at high speeds without XON/XOFF active. > >Richard K. Lloyd, ****** This is a VAX 11/780 running VAX/VMS V4.5 ****** I quote from the INSTALL file of our gnu emacs distribution: ---begin quotation--- C-s/C-q flow control is bad for Emacs editors because it takes away C-s and C-q as user commands. Since editors do not output long streams of text without user commands, there is no need for a user-issuable "stop output" command in an editor; therefore, a properly designed flow control mechanism would transmit all possible input characters without interference. Designing such a mechanism is easy, for a person with at least half a brain. There are three possible reasons why flow control could be taking place: 1) Terminal has not been told to disable flow control 2) Insufficient padding for the terminal in use 3) Some sort of terminal concentrator or line switch is responsible First of all, many terminals have a set-up mode which controls whether they generate flow control characters. This must be set to "no flow control" in order for Emacs to work. Sometimes there is an escape sequence that the computer can send to turn flow control off and on. If so, perhaps the termcap `ti' string should turn flow control off, and the `te' string should turn it on. Once the terminal has been told "no flow control", you may find it needs more padding. The amount of padding Emacs sends is controlled by the termcap entry for the terminal in use, and by the output baud rate as known by the kernel. The shell command `stty' will print your output baud rate; `stty' with suitable arguments will set it if it is wrong. Setting to a higher speed causes increased padding. If the results are wrong for the correct speed, there is probably a problem in the termcap entry. You must speak to a local Unix wizard to fix this. Perhaps you are just using the wrong terminal type. For terminals that lack a "no flow control" mode, sometimes just giving lots of padding will prevent actual generation of flow control codes. You might as well try it. If you are really unlucky, your terminal is connected to the computer through a concentrator which sends flow control to the computer, or it insists on sending flow control itself no matter how much padding you give it. You are screwed! You should replace the terminal or concentrator with a properly designed one. In the mean time, some drastic measures can make Emacs semi-work. One drastic measure to ignore C-s and C-q, while sending enough padding that the terminal will not really lose any output. Ignoring C-s and C-q can be done by using keyboard-translate-table to map them into an undefined character such as C-^ or C-\. Sending lots of padding is done by changing the termcap entry. An even more drastic measure is to make Emacs understand flow control. Do (set-input-mode nil t). Emacs will then interpret C-s and C-q as flow control commands. You will lose the ability to use them for Emacs commands. Also, as a consequence of using CBREAK mode, the terminal's Meta-key, if any, will not work, and C-g will be liable to cause a loss of output which will produce garbage on the screen. You can use keyboard-translate-table to map two other input characters (such as C-^ and C-\) into C-s and C-q, so that you can still search and quote. I have no intention of ever redisigning the Emacs command set for the assumption that terminals use C-s/C-q flow control. This flow control technique is a bad design, and terminals that need it are bad merchandise and should not be purchased. If you can get some use out of GNU Emacs on inferior terminals, I am glad, but I will not make Emacs worse for properly designed systems for the sake of inferior systems. * Control-S and Control-Q commands are ignored completely. For some reason, your system is using brain-damaged ^S/^Q flow control despite Emacs's attempts to turn it off. Perhaps your terminal is connected to the computer through a concentrator that wants to use flow control. You should first try to tell the concentrator not to use flow control. If you succeed in this, try making the terminal work without flow control, as described in the preceding section. If that line of approach is not successful, map some other characters into C-s and C-q using keyboard-translate-table. I suggest C-^ and C-\. ----end quotation----- "So, there it is." matt k (kennel@cognet.ucla.edu)
earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/09/88)
In article <1717@iscuva.ISCS.COM> jimc@iscuva.ISCS.COM (Jim Cathey) writes: >In article <3918@csvax.liv.ac.uk> sqrkl@csvax.liv.ac.uk writes: ... >>support XON/XOFF as a matter of course and you WOULD be foolish to run a >>terminal emulator at high speeds without XON/XOFF active. I predict that Richard Lloyd will shut up when he figures out how to write code which will keep up with the serial ports on a Mac. Until then, we have to put up with pompous statements like this, and I don't think there is anything we can do about it except for praying for his timely growth out of his present unenlightened state. >The really sick thing about all this is the pervasiveness of the >XON/XOFF/7-bit-only mindset -- to the point of some Ethernet connections being >unable to be anything else. Witness rlogin (TCP/IP) over Ethernet. Suuuure >you need XON/XOFF over a packetized, guaranteed delivery system. Better clear >that high bit too -- it could be dangerous! This does not appear to be the fault of the Ethernet connection in most cases, but rather that rlogin allows flow control to be handled locally. The point is that XON/XOFF is not needed over the Ethernet, but might be needed at the local end, especially if you are using a DEC terminal or VT100 Maculator! I don't know why rlogin normally strips the high bit, but it can be told not to do so on the command line. I think the 7-bit deal is really ASCII parochialism, but the XON/XOFF stuff is there because most users are not in a state of enlightenment comparable to ours and actually WANT it! Here are some "power-user" tips for rlogin/telnet. Please do not release them to the uninitiated! To disable XON/XOFF before using rlogin, try "stty stop \\200." This disables flow control completely. If you want to use the high bit through rlogin, use "rlogin <host> -8." If you plan on doing file transfers and such through the rlogin, better to do "stty raw" first. If using VMS as the local host, use "set term/passall" before the rlogin. If all else fails, read the man page. > Member: Society For The Preservation Of Binary Comm Paths. The paths are there, but they are hidden from all but us wizards. Earle Horton "You are in a maze of twisty little passages, all alike."
earleh@eleazar.dartmouth.edu (Earle R. Horton) (07/10/88)
In article <9177@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) (me) writes: >To disable XON/XOFF before using rlogin, try "stty stop \\200." ... >If all else fails, read the man page. I screwed up here, and also failed to follow my own advice about the man page. Stty, and nearly all UNIX programs, are too stupid to realize that a "char" is usually 8 or more bits wide. The correct way to disable flow control when using Ethernet rlogin is to disable flow control locally by "stty stop undef." This works on UNIX systems, and equivalents most certainly exist for other systems. Sorry for any inconvenience this may have caused. Earle Horton "You are in a maze of twisty little passages, all alike."