Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!chris From: chris@umcp-cs.UUCP Newsgroups: net.emacs Subject: Re: parity and Gosling Emacs Message-ID: <4915@umcp-cs.UUCP> Date: Mon, 30-Jan-84 16:20:59 EST Article-I.D.: umcp-cs.4915 Posted: Mon Jan 30 16:20:59 1984 Date-Received: Wed, 1-Feb-84 01:17:28 EST References: <650@dartvax.UUCP> Organization: Univ. of Maryland, Computer Science Dept. Lines: 49 That sounds extremely bizarre. If your shell exits when you ``stty raw'' you probably have a kernel bug or flaky hardware. Here is how parity/meta bits work (and in older versions don't work) in Gosling Emacs: There is a global variable declared in keyboard.h called MetaFlag. This is set by certain terminal drivers, notably TrmAmb.c, TrmC100.c, and, if your termcap has the flag :MT: in it, TrmTERM.c. When this is on, all eight bits of the characters read from the terminal are used. (When MetaFlag is clear, input characters are masked with 0177.) On output, no parity at all is generated. If you have the HalfBaked config.h option defined (this option is missing in later revisions of Emacs) then the terminal is kept in CBREAK mode and the Unix(tm) kernel generates parity as usual. If not, the terminal is kept in RAW mode and the output has "0 parity" (i.e. all parity bits are zero.) HalfBaked mode has two faults: while ^G can interrupt MLisp (very handy) the interruption confuses the redisplay code (there is no way around this in any version of Unix that I've seen), and on input the kernel strips the parity bit so meta keys are useless. (This is where the System III tty driver would be *very* useful!) Now, presuming that you actually have a terminal with a META key and have somehow got MetaFlag on (via :MT: or TrmAmb.c or similar), and that your Emacs was compiled without HalfBaked, the keyboard.c code takes special action when it sees the meta bit. Older versions of Gosling Emacs (#85 and earlier) have a bug here; I don't remember precisely what but it is fixed in the newer revisions. What happens in #264 is that when you type a meta key, the key is put onto the ``push-back-character stack'' and the function which gets keys (``GetKey()'') returns '\033' (escape). The next call to GetKey() notices that the character stack is not empty and returns the key. Thus "META-A" becomes "ESC-A", and so forth. A similar trick is used for the keyboard macro (^X-( and ^X-)). (In the case of the keyboard macro the characters are actually stored with the parity bit on: another bit of silliness, to avoid null strings when you use ^@ (set-mark). This is annoying when trying to edit the keyboard macro after giving it a name. As it said in the "subprocess control" section: ``This may get fixed someday if I want to think about it.'') (I hope I've been reasonably clear above. I've been editing display.c again and I think it's starting to get to me....) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relay