* bug#10650: view-mode inconsistencies wrt special mode-class
@ 2012-01-30 9:05 Glenn Morris
2012-01-30 20:10 ` Glenn Morris
2012-01-31 1:49 ` Stefan Monnier
0 siblings, 2 replies; 17+ messages in thread
From: Glenn Morris @ 2012-01-30 9:05 UTC (permalink / raw)
To: 10650
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-01-30 9:05 bug#10650: view-mode inconsistencies wrt special mode-class Glenn Morris
@ 2012-01-30 20:10 ` Glenn Morris
2012-01-30 23:29 ` Juri Linkov
2012-01-31 1:49 ` Stefan Monnier
1 sibling, 1 reply; 17+ messages in thread
From: Glenn Morris @ 2012-01-30 20:10 UTC (permalink / raw)
To: 10650
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10650: view-mode inconsistencies wrt special mode-class
2012-01-30 9:05 bug#10650: view-mode inconsistencies wrt special mode-class Glenn Morris
2012-01-30 20:10 ` Glenn Morris
@ 2012-01-31 1:49 ` Stefan Monnier
2012-01-31 2:50 ` Glenn Morris
1 sibling, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2012-01-31 1:49 UTC (permalink / raw)
To: Glenn Morris; +Cc: 10650
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
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10650: view-mode inconsistencies wrt special mode-class
2012-01-31 1:49 ` Stefan Monnier
@ 2012-01-31 2:50 ` Glenn Morris
2012-01-31 6:17 ` Chong Yidong
0 siblings, 1 reply; 17+ messages in thread
From: Glenn Morris @ 2012-01-31 2:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10650
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.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-01-31 2:50 ` Glenn Morris
@ 2012-01-31 6:17 ` Chong Yidong
2012-01-31 17:37 ` Stefan Monnier
0 siblings, 1 reply; 17+ messages in thread
From: Chong Yidong @ 2012-01-31 6:17 UTC (permalink / raw)
To: Glenn Morris; +Cc: 10650
Glenn Morris <rgm@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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-01-31 6:17 ` Chong Yidong
@ 2012-01-31 17:37 ` Stefan Monnier
2012-02-01 7:38 ` Glenn Morris
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2012-01-31 17:37 UTC (permalink / raw)
To: Chong Yidong; +Cc: 10650
> 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
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10650: view-mode inconsistencies wrt special mode-class
2012-01-31 17:37 ` Stefan Monnier
@ 2012-02-01 7:38 ` Glenn Morris
2012-02-01 8:32 ` Chong Yidong
2012-02-01 14:31 ` Stefan Monnier
0 siblings, 2 replies; 17+ messages in thread
From: Glenn Morris @ 2012-02-01 7:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, 10650
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-02-01 7:38 ` Glenn Morris
@ 2012-02-01 8:32 ` Chong Yidong
2012-02-01 17:15 ` Glenn Morris
2012-02-01 14:31 ` Stefan Monnier
1 sibling, 1 reply; 17+ messages in thread
From: Chong Yidong @ 2012-02-01 8:32 UTC (permalink / raw)
To: Glenn Morris; +Cc: 10650
Glenn Morris <rgm@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.)
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-02-01 8:32 ` Chong Yidong
@ 2012-02-01 17:15 ` Glenn Morris
0 siblings, 0 replies; 17+ messages in thread
From: Glenn Morris @ 2012-02-01 17:15 UTC (permalink / raw)
To: Chong Yidong; +Cc: 10650
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-02-01 7:38 ` Glenn Morris
2012-02-01 8:32 ` Chong Yidong
@ 2012-02-01 14:31 ` Stefan Monnier
2012-02-01 17:12 ` Glenn Morris
2012-02-02 0:40 ` Juri Linkov
1 sibling, 2 replies; 17+ messages in thread
From: Stefan Monnier @ 2012-02-01 14:31 UTC (permalink / raw)
To: Glenn Morris; +Cc: Chong Yidong, 10650
>>> 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
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10650: view-mode inconsistencies wrt special mode-class
2012-02-01 14:31 ` Stefan Monnier
@ 2012-02-01 17:12 ` Glenn Morris
2012-02-02 0:40 ` Juri Linkov
1 sibling, 0 replies; 17+ messages in thread
From: Glenn Morris @ 2012-02-01 17:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, 10650
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-02-01 14:31 ` Stefan Monnier
2012-02-01 17:12 ` Glenn Morris
@ 2012-02-02 0:40 ` Juri Linkov
2012-02-02 18:49 ` Stefan Monnier
1 sibling, 1 reply; 17+ messages in thread
From: Juri Linkov @ 2012-02-02 0:40 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, 10650
>> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread* bug#10650: view-mode inconsistencies wrt special mode-class
2012-02-02 0:40 ` Juri Linkov
@ 2012-02-02 18:49 ` Stefan Monnier
2012-02-02 20:03 ` Glenn Morris
0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2012-02-02 18:49 UTC (permalink / raw)
To: Juri Linkov; +Cc: Chong Yidong, 10650
>>> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-02-02 18:49 ` Stefan Monnier
@ 2012-02-02 20:03 ` Glenn Morris
2012-02-02 21:11 ` Juri Linkov
0 siblings, 1 reply; 17+ messages in thread
From: Glenn Morris @ 2012-02-02 20:03 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, 10650
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! ;) )
^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#10650: view-mode inconsistencies wrt special mode-class
2012-02-02 20:03 ` Glenn Morris
@ 2012-02-02 21:11 ` Juri Linkov
0 siblings, 0 replies; 17+ messages in thread
From: Juri Linkov @ 2012-02-02 21:11 UTC (permalink / raw)
To: Glenn Morris; +Cc: Chong Yidong, 10650
> 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.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-02-02 21:11 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-30 9:05 bug#10650: view-mode inconsistencies wrt special mode-class Glenn Morris
2012-01-30 20:10 ` Glenn Morris
2012-01-30 23:29 ` Juri Linkov
2012-01-31 0:38 ` Glenn Morris
2012-01-31 1:49 ` Stefan Monnier
2012-01-31 2:50 ` Glenn Morris
2012-01-31 6:17 ` Chong Yidong
2012-01-31 17:37 ` Stefan Monnier
2012-02-01 7:38 ` Glenn Morris
2012-02-01 8:32 ` Chong Yidong
2012-02-01 17:15 ` Glenn Morris
2012-02-01 14:31 ` Stefan Monnier
2012-02-01 17:12 ` Glenn Morris
2012-02-02 0:40 ` Juri Linkov
2012-02-02 18:49 ` Stefan Monnier
2012-02-02 20:03 ` Glenn Morris
2012-02-02 21:11 ` Juri Linkov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).