* 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 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 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 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-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 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-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 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-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-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 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
* 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 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-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-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 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: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
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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.