* Fundamental mode vs. special mode
@ 2011-10-22 20:13 Christoph Scholtes
2011-10-23 7:21 ` Chong Yidong
0 siblings, 1 reply; 26+ messages in thread
From: Christoph Scholtes @ 2011-10-22 20:13 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-22 20:13 Fundamental mode vs. special mode Christoph Scholtes
@ 2011-10-23 7:21 ` Chong Yidong
2011-10-23 9:19 ` martin rudalics
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Chong Yidong @ 2011-10-23 7:21 UTC (permalink / raw)
To: Christoph Scholtes; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 7:21 ` Chong Yidong
@ 2011-10-23 9:19 ` martin rudalics
2011-10-23 13:28 ` Juri Linkov
2011-10-23 13:14 ` Johan Bockgård
2011-10-23 14:58 ` Christoph Scholtes
2 siblings, 1 reply; 26+ messages in thread
From: martin rudalics @ 2011-10-23 9:19 UTC (permalink / raw)
To: Chong Yidong; +Cc: Christoph Scholtes, emacs-devel
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 7:21 ` Chong Yidong
2011-10-23 9:19 ` martin rudalics
@ 2011-10-23 13:14 ` Johan Bockgård
2011-10-25 2:38 ` Chong Yidong
2011-10-23 14:58 ` Christoph Scholtes
2 siblings, 1 reply; 26+ messages in thread
From: Johan Bockgård @ 2011-10-23 13:14 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 9:19 ` martin rudalics
@ 2011-10-23 13:28 ` Juri Linkov
2011-10-23 18:59 ` martin rudalics
0 siblings, 1 reply; 26+ messages in thread
From: Juri Linkov @ 2011-10-23 13:28 UTC (permalink / raw)
To: martin rudalics; +Cc: Christoph Scholtes, Chong Yidong, emacs-devel
>> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 7:21 ` Chong Yidong
2011-10-23 9:19 ` martin rudalics
2011-10-23 13:14 ` Johan Bockgård
@ 2011-10-23 14:58 ` Christoph Scholtes
2011-10-24 5:11 ` Juri Linkov
2 siblings, 1 reply; 26+ messages in thread
From: Christoph Scholtes @ 2011-10-23 14:58 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 13:28 ` Juri Linkov
@ 2011-10-23 18:59 ` martin rudalics
2011-10-24 5:07 ` Juri Linkov
2011-10-24 16:39 ` Richard Stallman
0 siblings, 2 replies; 26+ messages in thread
From: martin rudalics @ 2011-10-23 18:59 UTC (permalink / raw)
To: Juri Linkov; +Cc: Christoph Scholtes, Chong Yidong, emacs-devel
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 18:59 ` martin rudalics
@ 2011-10-24 5:07 ` Juri Linkov
2011-10-24 16:39 ` Richard Stallman
1 sibling, 0 replies; 26+ messages in thread
From: Juri Linkov @ 2011-10-24 5:07 UTC (permalink / raw)
To: martin rudalics; +Cc: Christoph Scholtes, Chong Yidong, emacs-devel
>> 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'.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 14:58 ` Christoph Scholtes
@ 2011-10-24 5:11 ` Juri Linkov
2011-10-24 12:46 ` Stefan Monnier
2011-10-24 17:17 ` Alan Mackenzie
0 siblings, 2 replies; 26+ messages in thread
From: Juri Linkov @ 2011-10-24 5:11 UTC (permalink / raw)
To: Christoph Scholtes; +Cc: Chong Yidong, emacs-devel
>> 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'.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-24 5:11 ` Juri Linkov
@ 2011-10-24 12:46 ` Stefan Monnier
2011-10-24 17:17 ` Alan Mackenzie
1 sibling, 0 replies; 26+ messages in thread
From: Stefan Monnier @ 2011-10-24 12:46 UTC (permalink / raw)
To: Juri Linkov; +Cc: Christoph Scholtes, Chong Yidong, emacs-devel
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 18:59 ` martin rudalics
2011-10-24 5:07 ` Juri Linkov
@ 2011-10-24 16:39 ` Richard Stallman
1 sibling, 0 replies; 26+ messages in thread
From: Richard Stallman @ 2011-10-24 16:39 UTC (permalink / raw)
To: martin rudalics; +Cc: juri, cschol2112, cyd, emacs-devel
> 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/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-24 5:11 ` Juri Linkov
2011-10-24 12:46 ` Stefan Monnier
@ 2011-10-24 17:17 ` Alan Mackenzie
2011-10-25 4:30 ` Juri Linkov
1 sibling, 1 reply; 26+ messages in thread
From: Alan Mackenzie @ 2011-10-24 17:17 UTC (permalink / raw)
To: Juri Linkov; +Cc: Christoph Scholtes, Chong Yidong, emacs-devel
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).
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-23 13:14 ` Johan Bockgård
@ 2011-10-25 2:38 ` Chong Yidong
2011-10-25 3:51 ` Chong Yidong
0 siblings, 1 reply; 26+ messages in thread
From: Chong Yidong @ 2011-10-25 2:38 UTC (permalink / raw)
To: emacs-devel
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).
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 2:38 ` Chong Yidong
@ 2011-10-25 3:51 ` Chong Yidong
2011-10-25 12:30 ` Stefan Monnier
0 siblings, 1 reply; 26+ messages in thread
From: Chong Yidong @ 2011-10-25 3:51 UTC (permalink / raw)
To: emacs-devel
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)
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-24 17:17 ` Alan Mackenzie
@ 2011-10-25 4:30 ` Juri Linkov
2011-10-25 20:49 ` Alan Mackenzie
0 siblings, 1 reply; 26+ messages in thread
From: Juri Linkov @ 2011-10-25 4:30 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Christoph Scholtes, Chong Yidong, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 3:51 ` Chong Yidong
@ 2011-10-25 12:30 ` Stefan Monnier
2011-10-25 13:53 ` Juanma Barranquero
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2011-10-25 12:30 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 12:30 ` Stefan Monnier
@ 2011-10-25 13:53 ` Juanma Barranquero
2011-10-25 15:11 ` Paul Eggert
0 siblings, 1 reply; 26+ messages in thread
From: Juanma Barranquero @ 2011-10-25 13:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 13:53 ` Juanma Barranquero
@ 2011-10-25 15:11 ` Paul Eggert
2011-10-25 20:02 ` Stefan Monnier
0 siblings, 1 reply; 26+ messages in thread
From: Paul Eggert @ 2011-10-25 15:11 UTC (permalink / raw)
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 15:11 ` Paul Eggert
@ 2011-10-25 20:02 ` Stefan Monnier
2011-10-25 20:30 ` Alan Mackenzie
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2011-10-25 20:02 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 20:02 ` Stefan Monnier
@ 2011-10-25 20:30 ` Alan Mackenzie
2011-10-26 1:11 ` Chong Yidong
2011-10-26 11:50 ` Richard Stallman
0 siblings, 2 replies; 26+ messages in thread
From: Alan Mackenzie @ 2011-10-25 20:30 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Paul Eggert, emacs-devel
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).
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 4:30 ` Juri Linkov
@ 2011-10-25 20:49 ` Alan Mackenzie
2011-10-26 1:18 ` Chong Yidong
0 siblings, 1 reply; 26+ messages in thread
From: Alan Mackenzie @ 2011-10-25 20:49 UTC (permalink / raw)
To: Juri Linkov; +Cc: Christoph Scholtes, Chong Yidong, emacs-devel
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).
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 20:30 ` Alan Mackenzie
@ 2011-10-26 1:11 ` Chong Yidong
2011-10-26 12:11 ` Nix
2011-10-26 11:50 ` Richard Stallman
1 sibling, 1 reply; 26+ messages in thread
From: Chong Yidong @ 2011-10-26 1:11 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Paul Eggert, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 20:49 ` Alan Mackenzie
@ 2011-10-26 1:18 ` Chong Yidong
0 siblings, 0 replies; 26+ messages in thread
From: Chong Yidong @ 2011-10-26 1:18 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Juri Linkov, Christoph Scholtes, emacs-devel
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-25 20:30 ` Alan Mackenzie
2011-10-26 1:11 ` Chong Yidong
@ 2011-10-26 11:50 ` Richard Stallman
2011-10-27 2:25 ` Chong Yidong
1 sibling, 1 reply; 26+ messages in thread
From: Richard Stallman @ 2011-10-26 11:50 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: eggert, monnier, emacs-devel
> 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/
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-26 1:11 ` Chong Yidong
@ 2011-10-26 12:11 ` Nix
0 siblings, 0 replies; 26+ messages in thread
From: Nix @ 2011-10-26 12:11 UTC (permalink / raw)
To: Chong Yidong; +Cc: Alan Mackenzie, Paul Eggert, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Fundamental mode vs. special mode
2011-10-26 11:50 ` Richard Stallman
@ 2011-10-27 2:25 ` Chong Yidong
0 siblings, 0 replies; 26+ messages in thread
From: Chong Yidong @ 2011-10-27 2:25 UTC (permalink / raw)
To: rms; +Cc: Alan Mackenzie, eggert, monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-10-27 2:25 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-22 20:13 Fundamental mode vs. special mode Christoph Scholtes
2011-10-23 7:21 ` Chong Yidong
2011-10-23 9:19 ` martin rudalics
2011-10-23 13:28 ` Juri Linkov
2011-10-23 18:59 ` martin rudalics
2011-10-24 5:07 ` Juri Linkov
2011-10-24 16:39 ` Richard Stallman
2011-10-23 13:14 ` Johan Bockgård
2011-10-25 2:38 ` Chong Yidong
2011-10-25 3:51 ` Chong Yidong
2011-10-25 12:30 ` Stefan Monnier
2011-10-25 13:53 ` Juanma Barranquero
2011-10-25 15:11 ` Paul Eggert
2011-10-25 20:02 ` Stefan Monnier
2011-10-25 20:30 ` Alan Mackenzie
2011-10-26 1:11 ` Chong Yidong
2011-10-26 12:11 ` Nix
2011-10-26 11:50 ` Richard Stallman
2011-10-27 2:25 ` Chong Yidong
2011-10-23 14:58 ` Christoph Scholtes
2011-10-24 5:11 ` Juri Linkov
2011-10-24 12:46 ` Stefan Monnier
2011-10-24 17:17 ` Alan Mackenzie
2011-10-25 4:30 ` Juri Linkov
2011-10-25 20:49 ` Alan Mackenzie
2011-10-26 1:18 ` Chong Yidong
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).