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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10650 in the body.
You can then email your comments to 10650 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: submit <at> debbugs.gnu.org
Subject: view-mode inconsistencies wrt special mode-class
Date: Mon, 30 Jan 2012 04:05:16 -0500

Package: emacs
Version: 24.0.93
Severity: minor

emacs -Q
M-x view-file RET /path/to/old/rmail/BABYL/file RET
-> "Not using View mode because the major mode is special"

but:
emacs -Q
M-x view-file-other-window RET /path/to/old/rmail/BABYL/file/RET
-> buffer opened in view mode.

This is a silly inconsistency. The test for special mode class was
already generalized (bug#5513) from view-file to view-buffer, but none
of the other view-mode commands (view-file-other-window,
view-file-other-frame, view-buffer-other-window,
view-buffer-other-frame) use view-buffer, so this doesn't affect them.

The check should probably be moved to view-mode-enter. This is used in a
handful of places outside view.el, so maybe an optional argument to
control the check will be needed.

When this is done, view-mode will treat special mode class consistently,
so it can be documented in the manual (the relation between view-mode
and special modes does not seem to documented at present). See the Emacs
24 etc/NEWS entry for view buffer.

Message #6 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Mon, 30 Jan 2012 15:10:01 -0500

I've changed my mind. I wanted to document _why_ view-file checks for a
special mode-class, but I could find no logical explanation.
This check was added here:

2003-07-09  Richard M. Stallman  <rms at gnu.org>

    * view.el (view-file): If existing buffer's major mode is
    special, don't go into view mode.

Unfortunately this just tells us _what_ was done, not why.
Emacs 22's NEWS file says:

  *** M-x view-file and commands that use it now avoid interfering
  with special modes such as Tar mode.

The only relevant thing I could find from the Emacs mailing lists around
this time was:

http://lists.gnu.org/archive/html/bug-gnu-emacs/2003-07/msg00031.html

  Problem: in dired the user hits v instead of RET on some file.zip.
  This causes lots of Zip-Archive mode keys to be overridden by view
  mode keys.

This isn't compelling to me. I agree with the only posted response:

   No, you should use RET if you want to run dired-find-file, and v if
   you want to run dired-view-file.


Anyway, it doesn't make much sense to me to steal the special mode-class
that tar-mode happens to have and start using it for view-file as well
(and it has never been documented anywhere AFAICS).

This came up before in some long thread:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4896#153

  I think the right solution should be to let the major mode say
  explicitly that it is mutually-exclusive with view-mode.


It would seem better to have some new explicit property for this, rather
than stealing special mode-class.

Message #9 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Tue, 31 Jan 2012 01:29:25 +0200

> This came up before in some long thread:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4896#153
>
>   I think the right solution should be to let the major mode say
>   explicitly that it is mutually-exclusive with view-mode.

Another thread worth to read is:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8615

> It would seem better to have some new explicit property for this, rather
> than stealing special mode-class.

Or a new user option defined in view.el with a list of modes where
view-mode should not be activated; with the default value like
`(image-mode archive-mode tar-mode)'.

Message #12 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Mon, 30 Jan 2012 19:38:03 -0500

Juri Linkov wrote:

> Or a new user option defined in view.el with a list of modes where
> view-mode should not be activated; with the default value like
> `(image-mode archive-mode tar-mode)'.

Sounds good to me.

Message #15 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Mon, 30 Jan 2012 20:49:57 -0500

Note that part of the problem here, really is `special mode-class',
which is a largely undefined concept both in terms of "what it's
supposed to mean" and "what effects does it have".


        Stefan

Message #18 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Mon, 30 Jan 2012 21:50:54 -0500

Stefan Monnier wrote:

> Note that part of the problem here, really is `special mode-class',
> which is a largely undefined concept both in terms of "what it's
> supposed to mean" and "what effects does it have".

AFAIK, the only documented meaning of special mode-class is:

If the default-value of major-mode is nil, then creating a new buffer
inherits the major-mode of the previously current buffer UNLESS that
buffer has a special mode-class, in which case the new buffer gets
fundamental mode. (Doesn't seem a very useful feature to me.)

The only other effect I am aware of it having is the one on view-mode
(which isn't documented, and seems unrelated to the previous paragraph.)

Message #21 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Tue, 31 Jan 2012 14:17:07 +0800

Glenn Morris <rgm <at> gnu.org> writes:

> AFAIK, the only documented meaning of special mode-class is:
>
> If the default-value of major-mode is nil, then creating a new buffer
> inherits the major-mode of the previously current buffer UNLESS that
> buffer has a special mode-class, in which case the new buffer gets
> fundamental mode. (Doesn't seem a very useful feature to me.)

The Lisp manual (node Basic Major Modes) says:

   Special mode is a basic major mode for buffers containing text
   that is produced specially by Emacs, rather than from a file.

That's the reason that special modes are never inherited when you make a
new buffer, even if major-mode has a nil default value.  The major mode
itself is not useful without other special "stuff" done by Emacs to
populate or process the buffer.

Unfortunately, this meaning tends to get obscured by the contents of
special-mode-map, where we've tried to "helpfully" set up keybindings
like "q" for quit-window.  But this is mostly tolerable.

I think view-file is right not to enable View mode for special mode, and
view-file-other-window/view-file-other-frame should be fixed up
similarly.  As for view-buffer, it is OK as is.

Message #24 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Tue, 31 Jan 2012 12:37:09 -0500

> The Lisp manual (node Basic Major Modes) says:
>    Special mode is a basic major mode for buffers containing text
>    that is produced specially by Emacs, rather than from a file.

Then again, doc-view-mode is a special mode even though the PDF code is
rarely if ever generated by Emacs.


        Stefan

Message #27 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Chong Yidong <cyd <at> gnu.org>, 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Wed, 01 Feb 2012 02:38:05 -0500

Stefan Monnier wrote:

>> The Lisp manual (node Basic Major Modes) says:
>>    Special mode is a basic major mode for buffers containing text
>>    that is produced specially by Emacs, rather than from a file.
>
> Then again, doc-view-mode is a special mode even though the PDF code is
> rarely if ever generated by Emacs.

I interpret special modes as being applicable to stuff where you won't
ever want to create an empty buffer and just start writing said stuff.
That covers PDFs, tar files, dired buffers, etc.

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.

Message #30 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Wed, 01 Feb 2012 16:32:23 +0800

Glenn Morris <rgm <at> gnu.org> writes:

> Stefan Monnier wrote:
>
>>> The Lisp manual (node Basic Major Modes) says:
>>>    Special mode is a basic major mode for buffers containing text
>>>    that is produced specially by Emacs, rather than from a file.
>>
>> Then again, doc-view-mode is a special mode even though the PDF code is
>> rarely if ever generated by Emacs.
>
> I interpret special modes as being applicable to stuff where you won't
> ever want to create an empty buffer and just start writing said stuff.
> That covers PDFs, tar files, dired buffers, etc.
>
> 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 changed view-buffer-other-* to behave like view-buffer.  (Could have
changed view-mode-enter instead, but that is called from other placed in
Emacs so it didn't seem worth the risk.)

Message #35 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Chong Yidong <cyd <at> gnu.org>, 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Wed, 01 Feb 2012 09:31:44 -0500

>>> The Lisp manual (node Basic Major Modes) says:
>>> Special mode is a basic major mode for buffers containing text
>>> that is produced specially by Emacs, rather than from a file.
>> Then again, doc-view-mode is a special mode even though the PDF code is
>> rarely if ever generated by Emacs.
> I interpret special modes as being applicable to stuff where you won't
> ever want to create an empty buffer and just start writing said stuff.
> That covers PDFs, tar files, dired buffers, etc.

Yes, my understanding of it also revolves around this idea.  And I think
that's what:

   If the default-value of major-mode is nil, then creating a new buffer
   inherits the major-mode of the previously current buffer UNLESS that
   buffer has a special mode-class, in which case the new buffer gets
   fundamental mode. (Doesn't seem a very useful feature to me.)

is hinting at.  Still, this notion of "special mode" seems of little
practical value since it only seems to be usable in the above case of
setting up the default major mode of a newly created buffer.

The default global value of major-mode is not nil, so in 99% of the
cases whether a mode is special will have zero effect.  I really would
be happy to declare that a nil default value for `major-mode' is not
supported any more.  So we can simply get rid of this "special
mode-class" mess.

> 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".


        Stefan

Message #38 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Chong Yidong <cyd <at> gnu.org>, 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Wed, 01 Feb 2012 12:12:03 -0500

Stefan Monnier wrote:

> The default global value of major-mode is not nil, so in 99% of the
> cases whether a mode is special will have zero effect. 

Yes, that's what I meant by saying that it doesn't seem a useful feature
to me.

> I really would be happy to declare that a nil default value for
> `major-mode' is not supported any more. So we can simply get rid of
> this "special mode-class" mess.

Fine by me, although the core functionality is already there of course
at very little cost.

> 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".

Yes, and largely by coincidence IMO many of those modes happen to
have special mode-class.

Message #41 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Wed, 01 Feb 2012 12:15:12 -0500

Chong Yidong wrote:

> I changed view-buffer-other-* to behave like view-buffer.
> (Could have changed view-mode-enter instead, but that is called from
> other placed in Emacs so it didn't seem worth the risk.)

Probably not for 24.1 indeed, but the first usage I looked at is in
files.el and it duplicates the same logic wrt mode-class:

(when (and buffer-read-only
             view-read-only
             (not (eq (get major-mode 'mode-class) 'special)))
      (view-mode-enter))

I'd guess (with no data) that most of the other callers either use
something similar, should use something similar but did not think of it,
or would not be affected if something similar were added.

Message #44 received at 10650 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Glenn Morris <rgm <at> gnu.org>, Chong Yidong <cyd <at> gnu.org>,
	10650 <at> debbugs.gnu.org
Subject: Re: bug#10650: view-mode inconsistencies wrt special mode-class
Date: Thu, 02 Feb 2012 02:40:45 +0200

>> 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.

But this heuristics is too unreliable, so explicitly declaring
incompatible modes is better.

Message #47 received at 10650 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #50 received at 10650 <at> debbugs.gnu.org (full text, mbox):

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

Why do we even care about not entering view-mode in special mode buffers
anyway? If you don't want view-mode, don't ask for it.
Is there any motivation for this feature beyond "some guy likes to press
v on everything in dired, then complain when he gets what he asked for"?

(Sorry, I seem to be going on about this far too much! ;) )

Message #53 received at 10650 <at> debbugs.gnu.org (full text, mbox):

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

> Why do we even care about not entering view-mode in special mode buffers
> anyway? If you don't want view-mode, don't ask for it.
> Is there any motivation for this feature beyond "some guy likes to press
> v on everything in dired, then complain when he gets what he asked for"?

Not just pressing v in dired, but also other cases like visiting a read-only
"special" file when `view-read-only' is non-nil, or typing `C-x C-q C-x C-q'
(both cases are handled in files.el)

Such special modes as image-mode and archive-mode don't need to activate
`view-mode' because in fact they are already "view" modes (as opposed to
"edit" modes with enabled self-inserting commands) and they bind own
keys to "view" their special (i.e. not plain text) content.

Previous Next

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