Debian emacs21: can't bind umlaut keys
Hi,
I am using a German keyboard, but usually write languages like "Perl"
at least as often as "German" and with the standard German keyboard
layout chars like "[]{}" are difficult to reach.
Therefore, I had already long time ago written some ELisp code to
switch the binding of the umlaut keys between different sets of
keykbindings according to my current needs. Unfortunately, it is a
little tricky to refer to those keys in emacs lisp (and the exact
modalities changed a little since emacs 19).
Now after migrating my systems from Suse to Debian (Etch), my key
bindings don't work anymore and I can't figure out, what changed.
Here a minimal code snippet to illustrate the problem:
(defun latin1-to-emacs-char (char-code)
(make-char 'latin-iso8859-1 (- char-code 128)))
(setq c_ae (latin1-to-emacs-char 228))
(local-set-key (make-vector 1 c_ae) "ae")
This should bind the key labeled "ä" to instead insert "ae". technically,
it still works on emacs 21.4 in Etch ((current-local-map) indicates the
change) but the key still produces "ä".
Some side notes:
- Emacs is running in unibyte mode
- The X server or the console driver (the problem is not X-related,
on the console it's the same) produce the expected key event:
state 0x0, keycode 48 (keysym 0xe4, adiaeresis), same_screen YES,
XLookupString gives 1 bytes: (e4) "ä"
XmbLookupString gives 1 bytes: (e4) "ä"
After an extended investigation, I know now, that this problem must be
caused by some debian-specific change to emacs. I installed several
other emacsens on the same system (including a shiny new emacs 22.1
compiled from the original source) and in all other installations, the
code snippet above will redefine the "ä" key as expected.
Since I am planning to use Debian on lots of machines, I would strongly
prefer if there was some workaround for the emacs21 debian package
instead of using a self-made emacs on all machines.
Unfortunately, I can't figure out, which modification actually causes
this and what to do about it. Any ideas?
Regards,
Peter Daum
Reply to: