emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: Rebinding international characters


From: Stefan
Subject: Re: Rebinding international characters
Date: 06 Aug 2004 16:50:25 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

> No it would be more complex than that.  With my scheme, prefix
> bindings in `function-key-map' should override regular non-prefix
> bindings, otherwise the problems persist.  Well, anyway, now (while

Right.  What you're saying is that escape sequences for text-terminals
should be handled more like key-translation-map than function-key-map
(i.e. they should not be overridable by a normal binding).

I think of it as key-function-map being weak, so what needs to happen is to
make those function key sequence bindings stronger.

I tend to agree.

Actually key-translation-map is only very rarely used, and I suspect it's
because noone really knows what to use it for.  At least I never understood
the separation between key-translation-map and function-key-map (even after
recently asking RMS about it).

Other problems with the current system:
- if function-key-map is used to map an escape sequence to kp-home,
  you can't use function-key-map's weak binding to home (the
  output of function-key-map is not passed through it again).
- you can't do a mapping of kp-home -> home that also automatically maps all
  its possible modifier combinations (i.e. M-kp-home -> M-home, ...).

Also the current system's choice to favor a normal binding has the following
trade-off:
- OT1H for key-remap bindings like `C-x 8 e ^ -> ê' or `ESC [ 2 1 ~ -> f10'
  this has the advantage that bindings like ESC ESC ESC or C-x C-x can be
  executed immediately instead of having to wait to see if the last C-x or
  ESC is the beginning of a special sequence.
- OTOH we have the problem that a key that generates `ESC $ b' might trigger
  an unrelated binding such as M-$ (or under a typical terminal, hitting
  ESC ESC F10 will trigger ESC ESC ESC and leave you with a [21~ in the
  buffer (or even [21~] if you bind [ to skeleton-pair-insert-maybe like
  me)).
I'm not sure the current choice is the best.  Maybe it would be better to
make the key-remap bindings stronger and thus solve the M-$ problems,
at the cost of waiting for more input when a binding ends in ESC or C-x.
Of course, in such a case it would be advisable to get rid of key-remappings
that start with C-x (bindings that end in ESC are rather infrequent and by
key-remapping ESC ESC to ESC, we would be able to get ESC ESC ESC by
hitting ESC ESC ESC ESC).  I think the C-x 8 binding can be turned off
by default now that we have the latin-1 input methods.  So the only
remaining key-remapping that starts with C-x would be the C-x @ thingies
which we could maybe move somewhere else.

I think the best way to do such a thing would be to add a new key-remap step
*before* function-key-map and then use it for all those text-terminal escape
sequences and for encoded-kbd.  The kp-home -> home thingies would of course
stay in function-key-map.

Anyway, this is post-21.4.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]