From xemacs-m  Thu Apr 10 22:59:53 1997
Received: from cs.sunysb.edu (sbcs.sunysb.edu [130.245.1.15])
	by xemacs.org (8.8.5/8.8.5) with SMTP id WAA01472
	for <xemacs-beta@xemacs.org>; Thu, 10 Apr 1997 22:59:53 -0500 (CDT)
Received: from sbkifer.cs.sunysb.edu (sbkifer.cs.sunysb.edu [130.245.1.35]) by cs.sunysb.edu (8.6.12/8.6.9) with SMTP id AAA06141; Fri, 11 Apr 1997 00:09:49 -0400
Message-Id: <199704110409.AAA06141@cs.sunysb.edu>
X-Authentication-Warning: sbcs.cs.sunysb.edu: Host sbkifer.cs.sunysb.edu didn't use HELO protocol
From: kifer@CS.SunySB.EDU (Michael Kifer)
To: David Moore <dmoore@ucsd.edu>
cc: xemacs-beta@xemacs.org
Subject: Re: key-translation-map bug: quick and dirty fix 
In-reply-to: "David Moore" of 10 Apr 1997 18:06:06 PDT
             <rvencimkqp.fsf@sdnp5.ucsd.edu> 
Date: Thu, 10 Apr 1997 23:57:03 -0400
Sender: kifer@CS.SunySB.EDU



> kifer@cs.sunysb.edu (Michael Kifer) writes:
> 
> > (I am assuming that the key-translation-map bug won't be fixed any time
> > soon, since it exists since 19.14 and maybe even earlier).
> 
> I've seen this mentioned before, but I guess I don't quite understand
> just what the bug in key-translation-map is.  Can someone explain this
> in the form of a simple set of specifications of how you think it should 
> work, and where the current version doesn't agree with it.
> 

Suppose you have something like:

(progn
  (setq test-map (make-sparse-keymap))
  (define-key test-map "\e" '(lambda () (interactive) (message "foo")))
  (use-local-map test-map)
  (define-key global-map
	      [(meta f1)] '(lambda () (interactive) (message "bar")))
  )

If you type ESC, you get "foo", if you type M-f1, you get "bar".
In other words, Meta and ESC are pretty much independent. Xemacs doesn't
translate M-f1 into ESC f1. 

On the other hand, if you eval 

(define-key key-translation-map
	    [(meta f1)] '(lambda () (interactive) (message "bar")))

then the binding of ESC in the local map gets overwritten. That is,
key-translation-map treats [(meta f1)] as ESC f1. This is inconsistent
(and it is also inconsistent with FSF, where this anomaly doesn't happen).


The other point is that the current behavior introduces unintended side
effects. For instance, the packages delbackspace.el and
x-win-xfree86.el define meta-backspace and meta-f1 in key-translation-map.
I am quite certain that the authors of these packages
didn't intend that this would change the binding for ESC in all
higher maps, even in minor mode maps, **and there is no way to
overwrite this**



	--michael  

