Re: Modified keypad keys

[Stefan Monnier]

> Not sure about shift.  It's used to toggle the layout of the keypad
> at the system level.  Also `shift-select-mode' comes into play.
> So without adding `shift' to these remappings, when e.g.
> `kp-7' self-inserts `7', `S-kp-7' selects the region
> to the beginning of the line.

I'm not sure I understand.  By `S-kp-7' do you mean "Emacs sees the
event S-kp-7" or "I press the key 7 on the numeric keypad while pressing
shift at the same time"?
I can't see why Emacs would move to the beginning of line in response to
the S-kp-7 event, unless you've added bindings on your own, but I can
imagine that pressing that numeric-keypad-7 with shift might end up
sending to Emacs some different event such as `S-home', which would
behave like you describe.  If that's the case then adding shift among
the modifiers in your code would simply not affect your case (but it
would still be useful for other keyboards).

>> So that's a total of 27 * 32 entries.  Makes this function-key-map alist
>> pretty long, if you ask me.

> An alternative is to do as suggested in the comments:

> ;; X11R6 distinguishes these keys from the non-kp keys.
> ;; Make them behave like the non-kp keys unless otherwise bound.
> ;; FIXME: rather than list such mappings for every modifier-combination,
> ;;   we should come up with a way to do it generically, something like
> ;;   (define-key function-key-map [*-kp-home] [*-home])

> I guess `*' should be a symbol like `shift', so it would be possible
> also use this notation:

> (define-key function-key-map [(* kp-home)] [(* home)])

The XEmacs [(foo bar)] notation is turned internally into the [foo-bar]
notation, so once we support [*-kp-home], we can extend that rewrite to
also support [(* kp-home)].

BTW, my current take on how to do the above, is to add "functional
keymaps", i.e. keymaps that are described by a function.  That function
would probably take 2 args: the first being the method invoked and the
second being the method's arg(s).  One of the methods would be `lookup',
another would be `map' (for map-keymap), not sure what else would
be needed.
And so far the best representation I could come up with is (keymap . FUN).

Such keymaps would be very useful for function-key-map, especially if we
change function-key-map to apply itself repeatedly (i.e. to re-apply
function-key-map to the key sequence after applying function-key-map).
With this, it should be possible to move many of the hardcoded
remappings ("remap `S-key' to `key' if `S-key' is unbound", "drop
down-mouse-N if unbound", ...) from the read_key_sequence monster to
simple function-key-map entries.


        Stefan