mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (11/02/88)
Thanks to everyone who responded and informed me the function of ^O; however, the question was more specifically "why?". In a rhetorical vein, why does EMACS, in general, use standard control characters as application dependent function characters? Why would any application?
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (11/02/88)
Thanks for the information. Unlike a preacher in an electronic ministry, I will not request that you keep those cards and letters coming. This discussion has reminded me of a song that was popular in my father's youth: "If You Knew What the Gnu Knew" As I recall there were several key changes in that ditty.
SRA@XX.LCS.MIT.EDU (Rob Austein) (11/04/88)
Date: Tuesday, 1 November 1988 18:01-EST
From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett)
Thanks to everyone who responded and informed me the function of
^O; however, the question was more specifically "why?". In a
rhetorical vein, why does EMACS, in general, use standard control
characters as application dependent function characters? Why
would any application?
Ancient history, mostly.
Keep in mind that the original EMACS was a set of TECO macros (hence
the name Editor MACroS) on the MIT Incompatible Timesharing System.
ITS has a long tradition of doing nonstandard things with control
characters, eg, to most ITS programs other than EMACS (which has so
many commands that RMS had to use every possible key combination):
^C = EOF;
^D = Discard (punt the line currently being entered);
^S = Shutup (stop tty output);
^Q = Quote (quote the next character).
You expect conformity on a system where the command processor is a
souped-up assembly language debugger?
--Robdavid@ms.uky.edu (David Herron -- One of the vertebrae) (11/04/88)
The flippant response (to the question about why any application
would use funny characters) is that if the system doesn't allow
interaction with a terminal using the entire character set, then
that system is brain-dead. (A notable instance is PR1ME which is
fine except there is no way short of calling some really-really-
really-really low-level kernal routines to get a ^J to be read
by a program).
The non-flippant reasponse is "why not?". Also, what's so standard
about, for instance, ^O. Yeah some operating systems use that for
special purposes, but nowhere near all of them. What's so "standard"
about ^S/^Q (another pair which causes headaches for emacs). For
one thing it's not standard, but it's also rather braindead to have
a system which uses in-band signaling to do flow control. Not only
is it slow and error prone, it decreases the "bandwidth".
I don't mean to inflame anybody, and I apologize if I have.
--
<-- David Herron; an MMDF guy <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- Controlled anarchy -- the essence of the net.roy@phri.UUCP (Roy Smith) (11/05/88)
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) writes: > why does EMACS, in general, use standard control characters as > application dependent function characters? I am sure there will be many answers to this. Before we get off to the races on this topic, may I remind people that we run the risk of getting into emacs religious wars. And, as most people can tell you, one very good way to generate lots of traffic and accomplish absolutely nothing in the process is to get involved in a emacs religious war. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
bzs@pinocchio.UUCP (Barry Shein) (11/05/88)
From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) >Thanks to everyone who responded and informed me the function of ^O; however, >the question was more specifically "why?". In a rhetorical vein, why does >EMACS, in general, use standard control characters as application dependent >function characters? Why would any application? On the system EMACS was developed (ITS) ^O was not a "standard control character", at least not in the way you seem to think of it, flushing output. I am sure one motivation for moving it with its (ITS?) original commands to other systems was to make life easier for users moving to those systems. EMACS was originally written in TECO, an editor which could parse and run line noise in useful and mysterious ways. So, backwards compatability is one reason. Another was mnemonic value (^O == Open Line.) Another is it's not clear that there was ever any strong motivation to preserve or interpret meaning for characters oriented towards line mode when in a full-screen editor. Full-screen editors like EMACS tended to grab the full character set (in fact, Emacs grabbed more than the full character set, 9-bits.) Another is that ^O is SHIFT-IN in ASCII, which means to change character sets or some such thing, is that what you had in mind as a more correct interpretation? It might be its use as flush output which is questionable. Better: Control-O on Emacs was not intended to be, particularly, ASCII 0xF. There was an intention in the original design to use other extended character sets and Control would be just another prefix bit, quite unlike the common usage we all know and love. If none of this is satisfying perhaps you can suggest what you are looking for as an explanation. -Barry Shein, ||Encore||
jim@eda.com (Jim Budler) (11/05/88)
In article <10521@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >The flippant response (to the question about why any application >would use funny characters) is that if the system doesn't allow [deleted] >The non-flippant reasponse is "why not?". Also, what's so standard >about, for instance, ^O. Yeah some operating systems use that for >special purposes, but nowhere near all of them. What's so "standard" [but somewhere near a lot of them] >about ^S/^Q (another pair which causes headaches for emacs). For >one thing it's not standard, but it's also rather braindead to have >a system which uses in-band signaling to do flow control. Not only >is it slow and error prone, it decreases the "bandwidth". OK, I'll give you ^O, but g-d d--n it ^S/^Q, if not a NIC, IEEE, OSI or any organisation approved *standard* predates by YEARS any implementation of Emacs. Ignoring it's existence in a predominent portion of the existing hardware was a philosophical, or even religious choice. Who cares if the philosophical idea is that in-band signals should not be used. When Emacs was developed, they were already nearly 100% in use. The original computer terminal, the original teletype terminal, used them. The decision to ignore that, for a philisophical reason, was STUPID. Is that too mild? The decision was arogant, uncaring, stupid, assinine, wanton, petty, and many other adjectives. For instance: I have a 19.2K modem. My computer cannot take input at that rate. I have two choices. Use vi, or set my interface rate below my modem rate. F**k. When they developed emacs they could have chosen other keys. They cannot have *not* known the majority of the world was using ^S/^Q at that time. Sitting back and saying hardware, please note that, I said hardware, including terminals, data concentrators, modems was brain dead for using in band signals so therefor Emacs will ignore this reality and force you to buy better hardware is AROGANT, STUPID, ELITEST, ACADEMIC, IVORY TOWER, ASSININE,... My G*D! Hardware predating the computers Emacs was developed on used ^S/^Q for the exact purpose hardware is using it for today. Are the only standards we work from those that are blessed by ARPA. Western Union was here BEFORE ARPA. ARPA doesn't even call them standards, they call them 'Request For Comment'. Now days they don't even call them that, someone might comment. Now they call them 'IDEAS'. I like Emacs. But when I run into the *frequent* situation where the hardware doesn't allow it, I don't say 'Damn hardware', I say ******* ******* Stallman. He was WRONG. The use of ^S/^Q was WELL ESTABLISHED, even if no standards body had bothered to write it up. They probably didn't think it needed, because any ******* would notice it was prevalent. Like I said, I'll grudgingly give you ^O, but I wont give you ^S/^Q. Why grudgingly? Because people who write *portable* code observe things that effect their *portable* code. ^O is common on *many* operating systems, it's called flush output. It was wrong!!!!!!!! I don't care if it is in band, I mean, gag me with a spoon, 7 bit is stupid, too. Send me flames. That way I'll know the UUCP links are working. -- uucp: {decwrl,uunet}!eda!jim Jim Budler internet: jim@eda.com EDA Systems, Inc.
bzs@pinocchio.UUCP (Barry Shein) (11/06/88)
Er, calm down, it's rather easy to bind ^O or ^S/^Q key functions to other keystrokes in all the emacs's I know of, for the latter a special note is even included spelling this out (and a function built in to make sure this works correctly, (set-input-mode nil t), GNU EMACS.) Also, for what it's worth, your complaint about ^S/^Q is in the wrong direction. It's not the host sending it to you when downloading, it's you sending it as keystrokes to the host. But that's ok, the point is the same, many terminals couldn't take 9600b anyhow and would send ^S/^Q, same for some network terminal muxes. I agree with you (at least in spirit) about the ^S/^Q thing but being as it's resettable easily I really don't think about it much. -Barry Shein, ||Encore||
thomas@uplog.se (Thomas Hameenaho) (11/08/88)
In article <266@eda.com> jim@eda.com (Jim Budler) writes: >In article <10521@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: <text deleted> >For instance: I have a 19.2K modem. My computer cannot take input >at that rate. I have two choices. Use vi, or set my interface rate >below my modem rate. F**k. When they developed emacs they could >have chosen other keys. I don't particularly like the Emacs use of ^S/^Q either. We have however learned to live with it, we use hardware handshake! This is really a big win anytime. If you have a 19.2Kbaud modem I'll bet it can handle hardware handshake. Most machines also handles it provided one use enough wires in the cables between the modem and computer. -- Real life: Thomas Hameenaho Email: thomas@uplog.{se,uucp} Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406 Box 1218 Fax: +46 18 132039 S - 751 42 Uppsala, Sweden
henry@utzoo.uucp (Henry Spencer) (11/09/88)
In article <8811012301.AA08441@ETN-WLV.EATON.COM> mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) writes: >...more specifically "why?". In a rhetorical vein, why does >EMACS, in general, use standard control characters as application dependent >function characters? Why would any application? Basically, because it is very useful for an application which can involve text entry to have command characters which cannot be mistaken for text. This avoids the need to have some sort of mode switch to distinguish text from commands. Users quite reasonably tend to feel that all printable ASCII characters are legitimate text, so a command character must be a control character, or a sequence thereof. Moreover, commands get typed a lot, so it's got to be something simple, preferably a single keypress. The ASCII standards give most of the control characters quite specific meanings; in particular, communications systems are **NOT** guaranteed to be transparent to a lot of them. Perhaps unfortunately, most real communications hardware is pretty transparent. This is a bit less true than it used to be -- XON/XOFF in particular is a lot more common than it was ten years ago -- but is still accurate overall. So it is very tempting to use ASCII control characters as command characters, and there is little incentive to hardware manufacturers to provide better alternatives. (There is no reason why holding down control and hitting O should not send something like ESC O, which networks *are* required to be pretty much transparent to, but existing keyboards don't do that.) It's an awkward decision for people writing interactive software, text editors in particular. -- The Earth is our mother. | Henry Spencer at U of Toronto Zoology Our nine months are up. |uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jim@eda.com (Jim Budler) (11/11/88)
In article <330@uplog.se> thomas@uplog.UUCP (Thomas Hameenaho) writes: >In article <266@eda.com> jim@eda.com (Jim Budler) writes: >>In article <10521@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: [text deleted, some of my own bitches] >I don't particularly like the Emacs use of ^S/^Q either. We have however >learned to live with it, we use hardware handshake! This is really a big win >anytime. If you have a 19.2Kbaud modem I'll bet it can handle hardware >handshake. Most machines also handles it provided one use enough wires >in the cables between the modem and computer. Well, it's ( or was ) like this. My mac can provide hardware handshake, provided I use the write terminal emulator. Now it can throttle the modem at this end, but what about the other end? Well as a result of my posting here I have learned of another option to stty that Sun provides, NOT in the manual, by the way. Guy Harris told me of the 'crtscts' option to stty. Now my terminal <-> [19.2k] <-> Sun {emacs} is solved. Thank you, Usenet News. There are even advantages to complaining here. jim -- uucp: {decwrl,uunet}!eda!jim Jim Budler internet: jim@eda.com EDA Systems, Inc.