[Top][All Lists]

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

Re: completion-list-mode-map

From: Stefan Monnier
Subject: Re: completion-list-mode-map
Date: Wed, 06 Jul 2011 08:49:56 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>>> or is there implicit inheritance of the keymap when deriving from
>>> special mode?
>> Yes, that inheritance is implicit (it's set up when the mode is
>> activated) unless the keymap already has a parent.

> I started looking into this and it looks like it is more complicated than
> I thought. I grepped for `'mode-class 'special' and got a pageful of
> hits. Some of these modes are already derived from special modes, some are
> not. Looking at the ones that are not, I am wondering if they should be.

Note: if a mode derives from special-mode, then it does not need the
(put 'foo-mode 'mode-class 'special).

> - arc-mode's mode-class is special. However, arc-mode is not derived from
> special-mode. Should it be?

The general rule should be that it is, but check that it's compatible.
Basically special-mode has a read-only buffer and some standard
key-bindings, so as long as there's no deep conflict in the key-bindings
and the mode is read-only, it should derive.
For this reason I think arc-mode should derive from special-mode.

> - comint-mode is derived from fundamental-mode, but it's mode-class is also
> special.  Should it be derived from special-mode instead?

Here on the other hand, we have some clear conflicts: comint-mode is not
read-only and can't bind `q' to quit-window and `g' to revert-buffer.
So I don't think it should inherit from special-mode.

> In other cases modes derive from special-mode already, but the key map
> parent is not set to special-mode map. For example, tar-mode.  Should the key
> map parent always be special-mode-map?

define-derived-mode will set the keymap parent to special-mode-map if
the mode's keymap doesn't already have a parent.

> What prompted me to look into this in the first place was the inconsistent
> behavior of `q'/`z' when trying to quit/kill buffers. special-mode map
> defines `q' as quit-window and `z' as kill-this-buffer, but some keymaps
> define `q' as, for example, thumbs-kill-buffer. How do we handle
> these cases?

(One of) the purposes of special-mode is to standardize key bindings, so
I think that thumbs-kill-buffer will have to go: it does something
similar to quit-window, and the differences are just an annoyance.
In other cases, the key-binding conflicts may need to be resolved by finding
new keys, rather than just ditching the old binding.


reply via email to

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