Re: Stop modes from hijacking several global keys

[Tassilo Horn <tsdh@gnu.org>]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

Hi Nicolas,

>>> Ideally, that magic would stop the mode from hijacking M-<number>
>>> keys, and whatever it wants to bind to M-<number> would
>>> automagically be bound to `<escape> M-<number>' instead.
>>>
>>> I think at least for major-modes I can use
>>> `after-change-major-mode-hook' in combination with a function
>>> checking (key-binding (kbd "M-<number>")) and doing `local-set-key'
>>> if needed.
>
> Since minor modes have precedence of major modes, you could define
> your own minor mode with those keybindings.

I don't think that would make a difference.  Note that I want the
commands that a (major-) mode would bind to `M-<number>' to be still
available via `<escape> M-<number>', so I'd need to do what
`th/select-nth-window-ensure-keys' from my previous mail does whenever
my mode is activated.  (And for it to be a proper minor-mode, it should
undo that when it gets deactivated.)

Looking at `define-globalized-minor-mode' that basically does the same
what I did: put a function in `after-change-major-mode-hook' that
enables the minor-mode.  I've put a function there that reclaims my
keys.

And then the problem of a minor-mode that gets activated after my own
minor-mode and then again steals my keys isn't solved, too.  For that,
I'd somehow need to ensure that my own minor-mode (or currently my
gimme-back-my-keys function) is and always stays the last function run
by `after-change-major-mode-hook'.

Anyway, this is now a more or less theoretical discussion because until
now it have always been major modes stealing my keys.  And by
convention, a minor-mode shouldn't bind M-<number> anyway.

Bye,
Tassilo