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