Robert> When that version of Xemacs was installed the Left Alt Robert> behaved (properly in my opinion) as Meta. It's horribly broken kludge, and is directly responsible for your predicament. Too late now, it's deeply embedded in Emacs culture. Robert> Now, the question that remains is, how do I get my left Robert> alt key functioning again as a Meta instead of Alt. [...] Robert> It may be a petty thing for me to desire this, but other Not at all. The behavior you want is not broken at all. I think it makes a lot of sense for your second modifier key to be the same across apps, whatever the apps think and whatever the keycap displays. It's just not easy to do correctly. What Mandrake does is this broken thing: http://www.xemacs.org/list-archives/xemacs-beta/200009/msg00048.html which will work for your current purpose, but is guaranteed to break some proposed features that require distinguishing Alt from Meta. If you want to be a hero, instead of making Alt synonymous with Meta as in the Mandrake patch, you could _swap_ the definitions and keep copious records of what breaks for the benefit of developers who want to provide a real fix. There will be some way at the Xt level to do this, but I'm not aware of any that you could implement in a *Translations resource. I think it would require additional code. Robert> programs (such as tinyfugue within the gnome-terminal) Robert> seen to also behave properly in regards to Meta. Are Robert> there any suggestions to fix this? A real fix requires that you either use Mandrake exclusively or don't use Mandrake at all. Mandrake enforces its keyboard policy (and other policies) by hacking application internals. The reason the behavior changed is that the Mandrake version of XEmacs is deliberately broken (by the patch above) to exhibit the behavior you are used to. In general you cannot expect non-Mandrake versions of applications to behave correctly in a Mandrake environment. It's not just XEmacs; Mandrake features prominently on all my Linux MLs for this kind of bug, way out of proportion to user base. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Hrvoje> And yet I wonder why they felt compelled to do this. Hrvoje> XEmacs is really quite reasonable about Alt/Meta Hrvoje> detection. It uses Meta when it is available, Alt when Hrvoje> it's not. Modern PCs have both. Unfortunately, the "Windows on Unix" crowd have disregarded the historical use of the Meta modifier assumed by Emacs and many other Unix apps on the PC hardware, and bind functions to Alt-<key>. Alt can't be both Alt and Meta on the same server as far as I know. Worse, the same people insist on giving the window manager extensive hotkey support, and to avoid conflicts with apps, they give the wm's functions to Meta-<key> bindings. (Which only makes sense, given the glyph on the Meta keycap on PCs.) XEmacs, of course, works best if the wm's functions are bound to Alt. I think the user interface principle of trying to use the same modifier keys across apps is reasonable. I think it's entirely reasonable of Robert to want to use the Alt key in both XEmacs and `K' applications, rather than Alt in some apps and Control and Meta in XEmacs. Unfortunately, you can't easily do that when some apps with extensive keymaps expect Alt and others expect Meta. I expect that Mandrake is trying to implement a policy like that. That doesn't justify what they did, but it explains it. This is exactly the point of (Ben's?) "X bogusly doesn't define ..." comment, I think. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."