GNU bug report logs - #10650
view-mode inconsistencies wrt special mode-class

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Juri Linkov <juri <at> jurta.org>
Cc: Glenn Morris <rgm <at> gnu.org>, Chong Yidong <cyd <at> gnu.org>, 10650 <at> debbugs.gnu.org
Subject: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Thu, 02 Feb 2012 13:49:34 -0500

>>> Personally I think a separate variable controlling which modes are
>>> incompatible with view-mode would be better, but I'm not going to
>>> complain if the definition of special modes is extended to cover this.
>> I'm not sure exactly what's the idea with view-mode's use of special
>> mode class, but IIUC it's that we don't want to enable view-mode in
>> major modes that already have view-mode-like keybindings, which might
>> boil down to something along the lines of "major modes which use
>> suppress-keymap".
> Without using the special mode class or adding a new separate variable,
> the closest condition to match modes incompatible with view-mode would be:

>   (and (buffer-file-name)
>        (or (derived-mode-p 'special-mode)
>            (equal (keymap-parent (current-local-map)) special-mode-map)))

> What is worth to note is that these modes don't suppress the
> special-mode keymap, but inherit from it and override most of its
> key bindings.

I didn't mean to say that those modes use suppress-keymap directly, jus
that their keymap is "suppressed" which is the case for any keymap which
inherits from special-mode-map.
Here's another heuristic:

  (eq 'undefined (lookup-key (current-local-map) [remap self-insert-command]))


-- Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.