[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: