Redefine the `special-mode-map'

Redefine the `special-mode-map'

[Alexander Shukaev]

Hello everyone,

I'd like to redefine the `special-mode-map'. Accordingly, in the very
beginning of my Emacs configuration I've added the following code:

    (let ((keymap (make-sparse-keymap)))
      (suppress-keymap keymap)
      (define-key keymap (kbd "q") #'quit-window)
      (define-key keymap (kbd "r") #'revert-buffer)
      (setq special-mode-map keymap))

I assume that all the modes which are either derived from `special-mode' or
have `special-mode-map' as a parent to their respective maps should indeed
inherit the above key bindings.

However, this is not the case. [C-h][b] shows that the above code had no
effect and that the default value of `special-mode-map' was still used as a
parent to construct child maps. In contrast, to complicate things,
[C-h][v]special-mode-map shows that `special-mode-map' contains all the
above changes. So what is going on? How to solve this problem?

Thanks and regards,
Alexander

Re: Redefine the `special-mode-map'

[Alex Kost]

Alexander Shukaev (2015-01-09 07:26 +0300) wrote:

> Hello everyone,
>
> I'd like to redefine the `special-mode-map'. Accordingly, in the very
> beginning of my Emacs configuration I've added the following code:
>
>     (let ((keymap (make-sparse-keymap)))
>       (suppress-keymap keymap)
>       (define-key keymap (kbd "q") #'quit-window)
>       (define-key keymap (kbd "r") #'revert-buffer)
>       (setq special-mode-map keymap))
>
> I assume that all the modes which are either derived from `special-mode' or
> have `special-mode-map' as a parent to their respective maps should indeed
> inherit the above key bindings.
>
> However, this is not the case. [C-h][b] shows that the above code had no
> effect and that the default value of `special-mode-map' was still used as a
> parent to construct child maps. In contrast, to complicate things,
> [C-h][v]special-mode-map shows that `special-mode-map' contains all the
> above changes. So what is going on? How to solve this problem?

The problem is you set the whole map variable to a new value.  If you
really need to "kill" all the bindings there, you may do it like this:

  (setcdr special-mode-map nil)

And then use your:

  (define-key special-mode-map (kbd "q") #'quit-window)
  ...

But do not set `special-mode-map' to another value.

-- 
Alex

Re: Redefine the `special-mode-map'

[Alexander Shukaev]

>
> But do not set `special-mode-map' to another value.
>
​
Why not? Could you expand? Previously I've been doing the same with other
keymaps. For instance, I redefined the `undo-tree-map' in the same manner
and it takes effect just fine. This problem only shows up with standard
keymaps, i.e. I see the problem not only with `special-mode-map', but with
`button-buffer-map', `tabulated-list-map', and etc. What would be the
reason for that and what is the difference from `undo-tree-map'?​

Re: Redefine the `special-mode-map'

[Alexander Shukaev]

​Furthermore, `setq' ​is used in order to prevent `defvar' to set the
default value in `simple.el'. This is the normal way to customize variables
prior loading their corresponding features. I've checked and in my case
`setq' is indeed run before `simple.el' is loaded. Once again, I did the
same with `undo-tree-map' customization and it worked.

On the contrary, for completeness, your recipe with `setcdr' seems to
require wrapping it in `with-eval-after-load':

(with-eval-after-load 'simple
  (setcdr special-mode-map nil)
  ...)


doesn't it?

Re: Redefine the `special-mode-map'

[Dmitry Gutov]

On 01/09/2015 05:53 PM, Alexander Shukaev wrote:

> Why not? Could you expand?

That's no use. `set-keymap-parent' takes values as arguments, not keymap 
names. So it some keymap already set `special-mode-map' as its parent, 
the original value has been captured.

Re: Redefine the `special-mode-map'

[Alexander Shukaev]

>
> That's no use. `set-keymap-parent' takes values as arguments, not keymap
> names. So it some keymap already set `special-mode-map' as its parent, the
> original value has been captured.
>

​
Hey Dmitry,

And how about the fact that `setq' ​is called before `simple.el' is loaded
what should effectively prevent `defvar' from setting the default value at
all?​

Re: Redefine the `special-mode-map'

[Michael Heerdegen]

Alexander Shukaev <haroogan@gmail.com> writes:

> And how about the fact that `setq' ​is called before `simple.el' is
> loaded

AFAICT if you do this setq in your init file simple.el has already been
loaded.  At least that's what I see here.

Re: Redefine the `special-mode-map'

[Alexander Shukaev]

>
> AFAICT if you do this setq in your init file simple.el has already been
> loaded.  At least that's what I see here.
>

​Could you describe the test case which you believe proves it?​

Re: Redefine the `special-mode-map'

[Dmitry Gutov]

On 01/09/2015 09:54 PM, Alexander Shukaev wrote:

> ​Could you describe the test case which you believe proves it?​

emacs -Q
M-: (featurep 'simple) RET

simple.el is one of the preloaded files (search for "preload" in 
http://www.gnu.org/software/emacs/manual/html_node/elisp/Building-Emacs.html), 
and read lisp/loadup.el.

Re: Redefine the `special-mode-map'

[Alexander Shukaev]

>
> emacs -Q
> M-: (featurep 'simple) RET
>

​This does not prove whether `simple.el' is loaded during Emacs
initialization (`init.el') when `setq' is called there. The following test
really shows it:

(with-eval-after-load 'simple
  (message "after: %s" xxx))

(setq xxx "Hello, World!")
(message "before: %s" xxx)

​In fact, this will throw an error that `xxx' is void. It means that indeed
`simple.el' is loaded even before `init.el' is run (and not because of the
call to `setq'). Interesting...

Huge thanks to everyone for shedding some light on my issue.

Kind regards,
Alexander

Re: Redefine the `special-mode-map'

[Michael Heerdegen]

Alexander Shukaev <haroogan@gmail.com> writes:

> ​Could you describe the test case which you believe proves it?​

I've put

  (setq xxx (featurep 'simple))

at the very beginning of .emacs and found xxx bound to t after
restarting.