Fundamental mode vs. special mode

Fundamental mode vs. special mode

[Christoph Scholtes]

I come across a few instances where buffers are created in Fundamental
mode, for example *Shell Mode Output*. It would be convenient if those
were created in special mode, since then `q' (or `C-u q') would invoke
quit-window and bury (or kill) the buffer.

Or could we add a Fundamental mode map with a few basic commands, like
`q' (quit-window)? Special-mode could inherit from it.

WDYT?

Christoph

Re: Fundamental mode vs. special mode

[Chong Yidong]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> I come across a few instances where buffers are created in Fundamental
> mode, for example *Shell Mode Output*. It would be convenient if those
> were created in special mode, since then `q' (or `C-u q') would invoke
> quit-window and bury (or kill) the buffer.
>
> Or could we add a Fundamental mode map with a few basic commands, like
> `q' (quit-window)? Special-mode could inherit from it.

It's not a good idea to add anything to Fundamental mode.  The point of
it is to be fundamental.

Anyway, binding "q" to `quit-window' is no good; I imagine some users
expect want to be able to edit the buffer.  Same with other cases like
the *Messages* buffer.

Re: Fundamental mode vs. special mode

[martin rudalics]

 > Anyway, binding "q" to `quit-window' is no good;

IMHO binding "q" to `quit-window' is no good ANYWHERE.  I don't ever
want to be "special-mode aware" when invoking a command that does not
work exclusively in special-mode buffers.

martin

Re: Fundamental mode vs. special mode

[Juri Linkov]

>> Anyway, binding "q" to `quit-window' is no good;
>
> IMHO binding "q" to `quit-window' is no good ANYWHERE.  I don't ever
> want to be "special-mode aware" when invoking a command that does not
> work exclusively in special-mode buffers.

It's a pity that we have no standard global keybinding that is
not self-inserting as `q'.

We have on some modes `C-c C-c' to finish changes.  So it
would be logical to add `C-c C-q' to quit windows.

Re: Fundamental mode vs. special mode

[martin rudalics]

 > We have on some modes `C-c C-c' to finish changes.  So it
 > would be logical to add `C-c C-q' to quit windows.

The C-c prefix doesn't fit well with window handling.  Most of the
window commands have a C-x prefix.

martin

Re: Fundamental mode vs. special mode

[Juri Linkov]

>> We have on some modes `C-c C-c' to finish changes.  So it
>> would be logical to add `C-c C-q' to quit windows.
>
> The C-c prefix doesn't fit well with window handling.  Most of the
> window commands have a C-x prefix.

True.  Let's see existing keybindings related to `q':

C-x q   runs the command kbd-macro-query
C-x C-q runs the command toggle-read-only
C-x 0   runs the command delete-window
C-x 4 0 runs the command kill-buffer-and-window

The latest is the closest, so a possible keybinding
for `quit-window' would be `C-x 4 q'.

Re: Fundamental mode vs. special mode

[Richard Stallman]

     > We have on some modes `C-c C-c' to finish changes.  So it
     > would be logical to add `C-c C-q' to quit windows.

    The C-c prefix doesn't fit well with window handling.  Most of the
    window commands have a C-x prefix.

C-c C-LETTER is reserved for major modes.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Fundamental mode vs. special mode

[Johan Bockgård]

Chong Yidong <cyd@stupidchicken.com> writes:

> It's not a good idea to add anything to Fundamental mode.  The point of
> it is to be fundamental.

FWIW,

 -- Command: fundamental-mode
     Fundamental mode is a major mode that is not specialized for
     anything in particular.  Other major modes are defined in effect
     by comparison with this one--their definitions say what to change,
     starting from Fundamental mode.  The `fundamental-mode' function
     does _not_ run any mode hooks; you're not supposed to customize
     it.  (If you want Emacs to behave differently in Fundamental mode,
     change the _global_ state of Emacs.)

(boundp 'fundamental-mode-hook) => t

2010-04-28  Stefan Monnier  <monnier@iro.umontreal.ca>

	Make it possible to locally disable a globally enabled mode.
	* simple.el (fundamental-mode): Run fundamental-mode-hook.
	* emacs-lisp/derived.el (define-derived-mode): Use fundamental-mode
	rather than kill-all-local-variables so it runs fundamental-mode-hook.
	* emacs-lisp/easy-mmode.el (define-globalized-minor-mode):
	Use fundamental-mode-hook to run MODE-enable-in-buffers earlier, so
	that subsequent hooks get a chance to disable it.

Re: Fundamental mode vs. special mode

[Chong Yidong]

Johan Bockgård <bojohan@gnu.org> writes:

>> It's not a good idea to add anything to Fundamental mode.  The point of
>> it is to be fundamental.
>
> FWIW,
>
> 2010-04-28  Stefan Monnier  <monnier@iro.umontreal.ca>
>
> Make it possible to locally disable a globally enabled mode.
> * simple.el (fundamental-mode): Run fundamental-mode-hook.
> * emacs-lisp/derived.el (define-derived-mode): Use fundamental-mode
> rather than kill-all-local-variables so it runs fundamental-mode-hook.
> * emacs-lisp/easy-mmode.el (define-globalized-minor-mode):
> Use fundamental-mode-hook to run MODE-enable-in-buffers earlier, so
> that subsequent hooks get a chance to disable it.

Thanks for pointing this out.  I think this change is problematic.
IIUC, it introduces a nontrivial backward incompatibility: major modes
defined with define-derived-mode now run fundamental-mode-hook, and thus
behave differently from major modes that are defined directly according
to previous Emacs guidelines for major modes (which was to simply call
kill-all-local-variables).

Re: Fundamental mode vs. special mode

[Chong Yidong]

Chong Yidong <cyd@gnu.org> writes:

> I think this change is problematic.  IIUC, it introduces a nontrivial
> backward incompatibility: major modes defined with define-derived-mode
> now run fundamental-mode-hook, and thus behave differently from major
> modes that are defined directly according to previous Emacs guidelines
> for major modes (which was to simply call kill-all-local-variables).

I propose to remove the fundamental-mode-hook variable introduced in
that change, and introduce `run-mode-hooks-hook', which `run-mode-hooks'
runs before all the other hooks.  Then minor modes can use
`run-mode-hooks-hook', and the "turning off global modes" feature will
be available to non-derived modes.

=== modified file 'lisp/emacs-lisp/derived.el'
*** lisp/emacs-lisp/derived.el	2011-08-25 05:37:55 +0000
--- lisp/emacs-lisp/derived.el	2011-10-25 02:35:20 +0000
***************
*** 230,236 ****
  					; Run the parent.
  	 (delay-mode-hooks
  
! 	  (,(or parent 'fundamental-mode))
  					; Identify the child mode.
  	  (setq major-mode (quote ,child))
  	  (setq mode-name ,name)
--- 230,236 ----
  					; Run the parent.
  	 (delay-mode-hooks
  
! 	  (,(or parent 'kill-all-local-variables))
  					; Identify the child mode.
  	  (setq major-mode (quote ,child))
  	  (setq mode-name ,name)

=== modified file 'lisp/emacs-lisp/easy-mmode.el'
*** lisp/emacs-lisp/easy-mmode.el	2011-10-19 12:54:24 +0000
--- lisp/emacs-lisp/easy-mmode.el	2011-10-25 03:30:57 +0000
***************
*** 367,377 ****
  	     (progn
  	       (add-hook 'after-change-major-mode-hook
  			 ',MODE-enable-in-buffers)
! 	       (add-hook 'fundamental-mode-hook ',MODE-enable-in-buffers)
  	       (add-hook 'find-file-hook ',MODE-check-buffers)
  	       (add-hook 'change-major-mode-hook ',MODE-cmhh))
  	   (remove-hook 'after-change-major-mode-hook ',MODE-enable-in-buffers)
!            (remove-hook 'fundamental-mode-hook ',MODE-enable-in-buffers)
  	   (remove-hook 'find-file-hook ',MODE-check-buffers)
  	   (remove-hook 'change-major-mode-hook ',MODE-cmhh))
  
--- 367,377 ----
  	     (progn
  	       (add-hook 'after-change-major-mode-hook
  			 ',MODE-enable-in-buffers)
! 	       (add-hook 'run-mode-hooks-hook ',MODE-enable-in-buffers)
  	       (add-hook 'find-file-hook ',MODE-check-buffers)
  	       (add-hook 'change-major-mode-hook ',MODE-cmhh))
  	   (remove-hook 'after-change-major-mode-hook ',MODE-enable-in-buffers)
!            (remove-hook 'run-mode-hooks-hook ',MODE-enable-in-buffers)
  	   (remove-hook 'find-file-hook ',MODE-check-buffers)
  	   (remove-hook 'change-major-mode-hook ',MODE-cmhh))
  

=== modified file 'lisp/simple.el'
*** lisp/simple.el	2011-10-19 12:54:24 +0000
--- lisp/simple.el	2011-10-25 02:35:48 +0000
***************
*** 349,355 ****
  Other major modes are defined by comparison with this one."
    (interactive)
    (kill-all-local-variables)
!   (run-mode-hooks 'fundamental-mode-hook))
  
  ;; Special major modes to view specially formatted data rather than files.
  
--- 349,356 ----
  Other major modes are defined by comparison with this one."
    (interactive)
    (kill-all-local-variables)
!   (unless delay-mode-hooks
!     (run-hooks 'after-change-major-mode-hook)))
  
  ;; Special major modes to view specially formatted data rather than files.
  

=== modified file 'lisp/subr.el'
*** lisp/subr.el	2011-10-06 19:15:19 +0000
--- lisp/subr.el	2011-10-25 03:30:33 +0000
***************
*** 1527,1532 ****
--- 1527,1535 ----
  (defvar after-change-major-mode-hook nil
    "Normal hook run at the very end of major mode functions.")
  
+ (defvar run-mode-hooks-hook nil
+   "Normal hook run before `run-mode-hooks' runs the mode hooks.")
+ 
  (defun run-mode-hooks (&rest hooks)
    "Run mode hooks `delayed-mode-hooks' and HOOKS, or delay HOOKS.
  Execution is delayed if the variable `delay-mode-hooks' is non-nil.
***************
*** 1540,1546 ****
      ;; Normal case, just run the hook as before plus any delayed hooks.
      (setq hooks (nconc (nreverse delayed-mode-hooks) hooks))
      (setq delayed-mode-hooks nil)
!     (apply 'run-hooks hooks)
      (run-hooks 'after-change-major-mode-hook)))
  
  (defmacro delay-mode-hooks (&rest body)
--- 1543,1549 ----
      ;; Normal case, just run the hook as before plus any delayed hooks.
      (setq hooks (nconc (nreverse delayed-mode-hooks) hooks))
      (setq delayed-mode-hooks nil)
!     (apply 'run-hooks (cons 'run-mode-hooks-hook hooks))
      (run-hooks 'after-change-major-mode-hook)))
  
  (defmacro delay-mode-hooks (&rest body)

Re: Fundamental mode vs. special mode

[Stefan Monnier]

> I propose to remove the fundamental-mode-hook variable introduced in
> that change, and introduce `run-mode-hooks-hook', which `run-mode-hooks'
> runs before all the other hooks.

Running the hook from run-mode-hooks instead of fundamental-mode would
be better, thanks.  I don't like the run-mode-hooks-hook name, tho.
I think we should find a name that better describes when it's run.
"after-change-major-mode-but-before-other-hooks-hook" is a bit wordy, so
I'm looking for ideas.


        Stefan

Re: Fundamental mode vs. special mode

[Juanma Barranquero]

On Tue, Oct 25, 2011 at 14:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> "after-change-major-mode-but-before-other-hooks-hook" is a bit wordy

It's still nine chars shorter than
`org-agenda-check-for-timestamp-as-reason-to-ignore-todo-item' ;-)

> so I'm looking for ideas.

Perhaps something like `first-hook-after-new-major-mode-hook'.

    Juanma

Re: Fundamental mode vs. special mode

[Paul Eggert]

On 10/25/11 06:53, Juanma Barranquero wrote:
> Perhaps something like `first-hook-after-new-major-mode-hook'.

Or 'first-after-change-major-mode-hook'?  I'd rather not have
two 'hook's in the same name.

Re: Fundamental mode vs. special mode

[Stefan Monnier]

>> Perhaps something like `first-hook-after-new-major-mode-hook'.
> Or 'first-after-change-major-mode-hook'?  I'd rather not have
> two 'hook's in the same name.

Keep going guys, this is improving.
Here's my best so far: `before-major-mode-hook' (after all, it's the
hook run before the major mode's).


        Stefan

Re: Fundamental mode vs. special mode

[Alan Mackenzie]

Hi, Stefan.

On Tue, Oct 25, 2011 at 04:02:51PM -0400, Stefan Monnier wrote:
> >> Perhaps something like `first-hook-after-new-major-mode-hook'.
> > Or 'first-after-change-major-mode-hook'?  I'd rather not have
> > two 'hook's in the same name.

> Keep going guys, this is improving.
> Here's my best so far: `before-major-mode-hook' (after all, it's the
> hook run before the major mode's).

How about `new-major-mode-hook'?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Fundamental mode vs. special mode

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

>>>> Perhaps something like `first-hook-after-new-major-mode-hook'.
>>>
>>> Or 'first-after-change-major-mode-hook'?  I'd rather not have
>>> two 'hook's in the same name.
>>
>> Here's my best so far: `before-major-mode-hook' (after all, it's the
>> hook run before the major mode's).
>
> How about `new-major-mode-hook'?

I'd rather have something related to the existing hook names.  How about
`change-major-mode-after-body-hook'?  Then the sequence would be

  change-major-mode-hook
  <body>
  change-major-mode-after-body-hook
  <mode-hooks>
  after-change-major-mode-hook

Re: Fundamental mode vs. special mode

[Nix]

On 26 Oct 2011, Chong Yidong told this:
>   change-major-mode-hook
>   <body>
>   change-major-mode-after-body-hook
>   <mode-hooks>
>   after-change-major-mode-hook

Whatever it ends up getting called, I think this little snippet should
go in the docstring of all those hooks.

Re: Fundamental mode vs. special mode

[Richard Stallman]

    > Keep going guys, this is improving.
    > Here's my best so far: `before-major-mode-hook' (after all, it's the
    > hook run before the major mode's).

    How about `new-major-mode-hook'?

Why do we want this, given that there is already
change-major-mode-hook and each major mode has a hook?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Fundamental mode vs. special mode

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > Keep going guys, this is improving.
>     > Here's my best so far: `before-major-mode-hook' (after all, it's the
>     > hook run before the major mode's).
>
>     How about `new-major-mode-hook'?
>
> Why do we want this, given that there is already
> change-major-mode-hook and each major mode has a hook?

It's used in a change to define-globalized-minor-mode that allows
enabled global minor modes to be turned off locally in mode hooks.

Re: Fundamental mode vs. special mode

[Christoph Scholtes]

Chong Yidong <cyd@stupidchicken.com> writes:

> It's not a good idea to add anything to Fundamental mode.  The point of
> it is to be fundamental.

OK.

> Anyway, binding "q" to `quit-window' is no good; I imagine some users
> expect want to be able to edit the buffer.  Same with other cases like
> the *Messages* buffer.

OK. I guess to me a buffer like *Shell Mode Output* is a read-only
buffer, hence `special'. If I want to edit the output of a shell command
I can always create buffer and insert the output into it with M-1
M-!. That's what I would have to do in a shell outside Emacs, no? On the
other hand, I can see how someone might think the current behavior is an
advantage.

As a user, I feel like buffers Emacs creates, which show some kind of
status information (logs, shell output etc.), I should be able to read
and acknowledge (e.g. with `q') like other `special' buffers. It feels
like quite often I have to think about what the correct command is for
this buffer, where I feel it should be more natural from a UI point of
view.

But then again, maybe I just have spent too much time in the non-free
world with its UI paradigms. ;)

Christoph

Re: Fundamental mode vs. special mode

[Juri Linkov]

>> Anyway, binding "q" to `quit-window' is no good; I imagine some users
>> expect want to be able to edit the buffer.  Same with other cases like
>> the *Messages* buffer.
>
> OK. I guess to me a buffer like *Shell Mode Output* is a read-only
> buffer, hence `special'.

I edit buffers like *Shell Command Output* and *Messages* all the time -
to better understand the output by removing unnecessary parts, etc.

> As a user, I feel like buffers Emacs creates, which show some kind of
> status information (logs, shell output etc.), I should be able to read
> and acknowledge (e.g. with `q') like other `special' buffers.

This problem exists only for self-inserting keys like `q'.
Another annoying key that prevents editing in some
non-read-only modes is `g' (`revert-buffer').  It would be better
to find non-self-inserting keybindings for them.

Then we will have two versions (long and short) for these keybindings,
like longer `C-h m' and shorter `h' and `?' for `describe-mode',
and longer `M-<' and shorter `<' for `beginning-of-buffer'.

> It feels like quite often I have to think about what the correct
> command is for this buffer, where I feel it should be more natural
> from a UI point of view.

Perhaps there should be a clearer separation between edit and view modes.
So in edit mode (even when major mode is derived from `special-mode'),
all single key should be self-inserting.  And in view mode (including
modes derived from `special-mode') single keys like `q' and `g' are
acceptable because the buffer is read-only anyway.  Actually we already
have a keybinding to switch between edit and view modes: `C-x C-q'.

Re: Fundamental mode vs. special mode

[Stefan Monnier]

> This problem exists only for self-inserting keys like `q'.
> Another annoying key that prevents editing in some
> non-read-only modes is `g' (`revert-buffer').

Both q and g should only be used in buffers where normal editing doesn't take place.
If you find situations where this is not the case, please report them.


        Stefan

Re: Fundamental mode vs. special mode

[Alan Mackenzie]

Hello, Juri

On Mon, Oct 24, 2011 at 08:11:33AM +0300, Juri Linkov wrote:
> Perhaps there should be a clearer separation between edit and view modes.
> So in edit mode (even when major mode is derived from `special-mode'),
> all single key should be self-inserting.  And in view mode (including
> modes derived from `special-mode') single keys like `q' and `g' are
> acceptable because the buffer is read-only anyway.  Actually we already
> have a keybinding to switch between edit and view modes: `C-x C-q'.

I'm against this, on several counts.  Read-onlyness shouldn't be thought
of as a minor mode.  It's merely a property of a buffer which, e.g.,
mirrors a property in the filesystem.  The concept of "edit mode" vs.
"view mode" is far too close to "insert mode" vs. "command mode" for
comfort.

In any mode, each key-sequence should do one well established thing, not
performing alternate commands based on read-onlyness.  Exceptions should
be justified individually.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Fundamental mode vs. special mode

[Juri Linkov]

> In any mode, each key-sequence should do one well established thing, not
> performing alternate commands based on read-onlyness.  Exceptions should
> be justified individually.

But in read-only buffers, self-inserting characters are useless,
they can't do what they are intended for.  So why not allow them
to do more useful things, e.g. `q' to run `quit-window'?

Actually this is what `view-read-only' does when set to non-nil.
I don't propose to change its default value to non-nil now,
but at least it's worth thinking about.

Re: Fundamental mode vs. special mode

[Alan Mackenzie]

Hi, Juri.

On Tue, Oct 25, 2011 at 07:30:18AM +0300, Juri Linkov wrote:
> > In any mode, each key-sequence should do one well established thing, not
> > performing alternate commands based on read-onlyness.  Exceptions should
> > be justified individually.

> But in read-only buffers, self-inserting characters are useless, they
> can't do what they are intended for.  So why not allow them to do more
> useful things, e.g. `q' to run `quit-window'?

If by read-only buffers, you mean something like *info* or *Buffer
List*, then I agree with you.  But if we're talking about file buffers
which happen to be RO at the moment, then no - self-inserting characters
have the important function of beeping.

If we're going to be switching from "editing mode" to "command mode" for
self inserting keys (with C-x C-q or whatever), we might as well go the
whole hog and use vi instead.  Let's preserve the character of Emacs.

> Actually this is what `view-read-only' does when set to non-nil.
> I don't propose to change its default value to non-nil now,
> but at least it's worth thinking about.

view-mode is a distinct mode with its own distinct bindings.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Fundamental mode vs. special mode

[Chong Yidong]

Alan Mackenzie <acm@muc.de> writes:

>> But in read-only buffers, self-inserting characters are useless, they
>> can't do what they are intended for.  So why not allow them to do
>> more useful things, e.g. `q' to run `quit-window'?
>
> If by read-only buffers, you mean something like *info* or *Buffer
> List*, then I agree with you.  But if we're talking about file buffers
> which happen to be RO at the moment, then no - self-inserting
> characters have the important function of beeping.

FWIW, I agree.  For example, one might imagine visiting a file without
realizing the file is read-only, and typing `q' to insert, which ends up
quitting the window.  That would be annoying.