Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!mit-eddie!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU
Newsgroups: comp.windows.x
Subject: Re:  Meta key handling in xterm
Message-ID: <9102230925.AA00643@lightning.McRCIM.McGill.EDU>
Date: 23 Feb 91 09:25:33 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 50

> Do you use the Meta( Alt ) key with xterm?

No; I use neither the Meta key nor xterm.  However, I did just recently
have occasion to look at the relevant code.

The R4 xterm's Input() (in input.c) contains, among other things,

		if ((nbytes == 1) && eightbit) {
		    if (screen->eight_bits)
		      *string |= 0x80;	/* turn on eighth bit */
		    else
		      unparseputc (033, pty);  /* escape */
		}

The screen->eight_bits flag comes from the eightBitInput resource,
which defaults to True.  The eightbit variable is an argument; in
misc.c, the calls to Input() in HandleKeyPressed and
HanelEightBitKeyPressed are False and True respectively.

Now we look at charproc.c.  We find

	static XtActionsRec actionsList[] = { 
[...]
	    { "insert-seven-bit", HandleKeyPressed },
	    { "insert-eight-bit", HandleEightBitKeyPressed },
[...]

and elsewhere,

	static char defaultTranslations[] =
	"\
[...]
	       ~Meta<KeyPress>: 	insert-seven-bit()	\n\
	        Meta<KeyPress>: 	insert-eight-bit()	\n\
[...]

So normally, the Meta key will set the high bit on typed characters.  I
suspect what's happening is that someone (your pty driver, perhaps?) is
stripping the high bit for you, so Meta is ultimately ignored.

Try turning eightBitInput off.  This should cause Meta-modified
keystrokes to be prefixed with an escape character, which appears to be
what you want.  (For example: xterm -xrm '*eightBitInput: False'.)  I
just tried this here with the R4 xterm and it appears to work as I have
described.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu