bug#5541: 23.1; after upgrading to emacs-23, meta key in xterm no longer works

[Chong Yidong <cyd@stupidchicken.com>]

Thomas Dickey <dickey@his.com> writes:

>> ! Shift-paste to paste CLIPBOARD instead of PRIMARY.
>> xterm*VT100.Translations: #override \
>> 	Shift <Btn2Up>: insert-selection(CLIPBOARD)\n \
>> 	Ctrl ~Shift Meta <Key>-: smaller-vt-font() \n \
>> 	Ctrl ~Shift Meta <Key>=: larger-vt-font() \n
>
> The various key-modifier resources are all ifdef'd as a single group
> (no escape sequence is implemented to disable the feature).  I suppose
> emacs is checking the version number from xterm to decide if the feature
> is present, since there's no other indication that it's available.
>
> xterm generally doesn't know what the translations do, but it does
> check if the meta key appears in a translation.  For that, and alt,
> xterm decides to not use those in modified function-keys - to try to
> avoid odd conflicts with cases such as this translation.  (They may be
> the same key - same general effect).  But the particular combination
> caught by the translations wouldn't be seen by xterm; it only massages
> the seen keycodes.
>
> The escape sequence says xterm's sending a 3 (for alt).  Perhaps it's
> something along the lines of xterm deciding that meta isn't part of
> the modify-other-keys feature, but alt (on the same key) still is.  I
> assume that emacs is looking for 9 (meta) rather than 3 (alt), and so
> it errors out.

Thanks for the explanation.  I don't see, from this, what we can do to
detect and fix this problem automatically, so I suppose it will be up to
the user who has defined such translations to tell Emacs not to use
modify-other-keys.  I have added an entry to etc/PROBLEMS in the Emacs
source tree documenting this.