bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

Inspired by Stefan's comment at [1] I came up with this patch to set
revert-buffer-function in shell command buffers.

I have a binding for revert-buffer which is nicer to press than M-! M-p
RET or M-& M-p RET when repeatedly editing and re-running programs and
scripts.

[1]  https://emacs.stackexchange.com/questions/35421/refresh-async-shell-command-buffer

-- 
Sean Whitton

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Set-revert-buffer-function-in-shell-command-output-b.patch --]
[-- Type: text/x-diff, Size: 1545 bytes --]

From 2f121e3d540bd18bd39829545ef3b07178501958 Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhitton@spwhitton.name>
Date: Wed, 27 Jan 2021 23:18:03 -0700
Subject: [PATCH] Set revert-buffer-function in shell command output buffers

* simple.el (shell-command, shell-command-on-region): Set
revert-buffer-function in shell command output buffers.
---
 lisp/simple.el | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/lisp/simple.el b/lisp/simple.el
index e82b138b0d..24e3b4a7f5 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3991,6 +3991,9 @@ impose the use of a shell (with its need to quote arguments)."
 			  (start-process-shell-command "Shell" buffer command)))
 		  (setq mode-line-process '(":%s"))
                   (shell-mode)
+                  (setq revert-buffer-function
+                        (lambda (&rest _)
+                            (async-shell-command command (current-buffer))))
                   (set-process-sentinel proc #'shell-command-sentinel)
 		  ;; Use the comint filter for proper handling of
 		  ;; carriage motion (see comint-inhibit-carriage-motion).
@@ -4257,6 +4260,9 @@ characters."
                                              buffer))))
             ;; Report the output.
             (with-current-buffer buffer
+              (setq revert-buffer-function
+                    (lambda (&rest _)
+                      (shell-command command)))
               (setq mode-line-process
                     (cond ((null exit-status)
                            " - Error")
-- 
2.29.2

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Inspired by Stefan's comment at [1] I came up with this patch to set
> revert-buffer-function in shell command buffers.

Nice; I've applied your patch to Emacs 28.

> I have a binding for revert-buffer which is nicer to press than M-! M-p
> RET or M-& M-p RET when repeatedly editing and re-running programs and
> scripts.

Would it make sense to just define a tiny mode that just defines the `g'
command to revert and use that in these buffers?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Fri 29 Jan 2021 at 06:52AM +01, Lars Ingebrigtsen wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> Inspired by Stefan's comment at [1] I came up with this patch to set
>> revert-buffer-function in shell command buffers.
>
> Nice; I've applied your patch to Emacs 28.

Thanks for taking a look!

I realised that my patch needs to setq-local not just setq.  Indeed, my
previous patch breaks revert-buffer once you've run a shell command...

Attached is a fix.

>> I have a binding for revert-buffer which is nicer to press than M-! M-p
>> RET or M-& M-p RET when repeatedly editing and re-running programs and
>> scripts.
>
> Would it make sense to just define a tiny mode that just defines the `g'
> command to revert and use that in these buffers?

For M-!, yes, that would be useful and simple.

For M-&, the mode would need to be activated only once the command had
finished running, as otherwise 'g' should be sent to the inferior
process.  Not hard to do that either.

I take it a minor mode is more appropriate than a major mode for this?
If so, I can come up with a patch adding that to simple.el.

-- 
Sean Whitton

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-previous-commit-regarding-revert-buffer-function.patch --]
[-- Type: text/x-diff, Size: 1973 bytes --]

From 21499b416759b77a5d0ef41cb4f68932d36b9b63 Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhitton@spwhitton.name>
Date: Fri, 29 Jan 2021 00:02:08 -0700
Subject: [PATCH] ; Fix previous commit regarding revert-buffer-function

* simple.el (shell-command, shell-command-on-region): Set
revert-buffer-function buffer-locally, not globally.  Also, avoid an
unnecessary call to (current-buffer) by taking advantage of the
closure.
---
 lisp/simple.el | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lisp/simple.el b/lisp/simple.el
index 64ee042135..742fc5004d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3991,9 +3991,9 @@ impose the use of a shell (with its need to quote arguments)."
 			  (start-process-shell-command "Shell" buffer command)))
 		  (setq mode-line-process '(":%s"))
                   (shell-mode)
-                  (setq revert-buffer-function
-                        (lambda (&rest _)
-                          (async-shell-command command (current-buffer))))
+                  (setq-local revert-buffer-function
+                              (lambda (&rest _)
+                                (async-shell-command command buffer)))
                   (set-process-sentinel proc #'shell-command-sentinel)
 		  ;; Use the comint filter for proper handling of
 		  ;; carriage motion (see comint-inhibit-carriage-motion).
@@ -4260,9 +4260,9 @@ characters."
                                              buffer))))
             ;; Report the output.
             (with-current-buffer buffer
-              (setq revert-buffer-function
-                    (lambda (&rest _)
-                      (shell-command command)))
+              (setq-local revert-buffer-function
+                          (lambda (&rest _)
+                            (shell-command command)))
               (setq mode-line-process
                     (cond ((null exit-status)
                            " - Error")
-- 
2.29.2

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> I realised that my patch needs to setq-local not just setq.  Indeed, my
> previous patch breaks revert-buffer once you've run a shell command...
>
> Attached is a fix.

Heh, that explains why my Emacs was behaving so oddly.  :-)

Fix now pushed.

>> Would it make sense to just define a tiny mode that just defines the `g'
>> command to revert and use that in these buffers?
>
> For M-!, yes, that would be useful and simple.
>
> For M-&, the mode would need to be activated only once the command had
> finished running, as otherwise 'g' should be sent to the inferior
> process.  Not hard to do that either.
>
> I take it a minor mode is more appropriate than a major mode for this?
> If so, I can come up with a patch adding that to simple.el.

Since M-! and M-& use different modes (fundamental and shell), a minor
mode is probably the best, I guess.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

Hello,

On Fri 29 Jan 2021 at 08:21AM +01, Lars Ingebrigtsen wrote:

>>> Would it make sense to just define a tiny mode that just defines the `g'
>>> command to revert and use that in these buffers?
>>
>> For M-!, yes, that would be useful and simple.
>>
>> For M-&, the mode would need to be activated only once the command had
>> finished running, as otherwise 'g' should be sent to the inferior
>> process.  Not hard to do that either.
>>
>> I take it a minor mode is more appropriate than a major mode for this?
>> If so, I can come up with a patch adding that to simple.el.
>
> Since M-! and M-& use different modes (fundamental and shell), a minor
> mode is probably the best, I guess.

I was thinking about this some more and now I'm not so sure.  Do we
really want exactly one letter key not to be self-inserting in those
buffers?

Currently the command output is editable in ordinary ways, so it would
be reasonable to edit the command output by typing something, then kill
some text after you've edited it, and put it elsewhere.

This sort of thing could be pretty annoying if you happened to want to
type the letter 'g' and thereby reran the command ..

How about binding C-c C-r instead of g?  The mnemonic would be
Reexecute.  In *Async Shell Command* buffers this already has an
inherited binding but I don't believe it is one that does anything
useful in those buffers, so should be fine to override.

An alternative would be to put the whole buffer in special-mode, which
would bind 'g', and make shell command output more like M-x compile
buffers.  Could have a defcustom to turn this off.

-- 
Sean Whitton

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> This sort of thing could be pretty annoying if you happened to want to
> type the letter 'g' and thereby reran the command ..

Indeed -- I was thinking about the `M-!' case only, and whether we'd
want to change the mode of the resulting buffer to a new mode that
inherits from `special-mode' (and `special-mode' defines the `g'
keystroke already).

That's not appropriate for `M-&', I guess, which is in `shell-mode'...
but is that a good mode for command output, really?

> How about binding C-c C-r instead of g?  The mnemonic would be
> Reexecute.  In *Async Shell Command* buffers this already has an
> inherited binding but I don't believe it is one that does anything
> useful in those buffers, so should be fine to override.
>
> An alternative would be to put the whole buffer in special-mode, which
> would bind 'g', and make shell command output more like M-x compile
> buffers.  Could have a defcustom to turn this off.

Indeed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Juri Linkov]

> How about binding C-c C-r instead of g?  The mnemonic would be
> Reexecute.  In *Async Shell Command* buffers this already has an
> inherited binding but I don't believe it is one that does anything
> useful in those buffers, so should be fine to override.

To avoid all possible conflicts, this looks harmless: 'C-c g'.

bug#46151: [External] : bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Drew Adams]

> To avoid all possible conflicts, this looks harmless: 'C-c g'.

Apologies; I'm not following this thread.
I just happened to notice this message.

(elisp) `Key Binding Conventions' says this:

 Don't define 'C-c LETTER' as a key in Lisp programs.  Sequences
 consisting of 'C-c' and a letter (either upper or lower case) are
 reserved for users; they are the *only* sequences reserved for
 users, so do not block them.

So `C-c g' should be a no-no, no?

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Michael Welsh Duggan]

Juri Linkov <juri@linkov.net> writes:

>> How about binding C-c C-r instead of g?  The mnemonic would be
>> Reexecute.  In *Async Shell Command* buffers this already has an
>> inherited binding but I don't believe it is one that does anything
>> useful in those buffers, so should be fine to override.
>
> To avoid all possible conflicts, this looks harmless: 'C-c g'.

Except key sequences consisting of `C-c' followed by a letter are
reserved for user-defined bindings.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Michael Welsh Duggan <mwd@md5i.com> writes:

>> To avoid all possible conflicts, this looks harmless: 'C-c g'.
>
> Except key sequences consisting of `C-c' followed by a letter are
> reserved for user-defined bindings.

Indeed.

This reminds me that I've often found it odd that there's no global
binding for `revert-buffer' -- I think there should be, because it's
such a useful command.

Sean suggested `C-c C-r', which is nicely mnemonic, and is natural as a
non-complicated alternative to `C-c C-f' when trying to reload a file
(since `C-c C-f' has a lot of annoying DWIM stuff going on).

We can't use `C-c C-g', I guess, since we try to avoid keystrokes that
involve `C-g' (since `C-g' should reliably quit), but that would also be
a natural keystroke, since `revert-buffer' is bound to `g' in
`special-mode'.

Any opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Juri Linkov]

> We can't use `C-c C-g', I guess, since we try to avoid keystrokes that
> involve `C-g' (since `C-g' should reliably quit), but that would also be
> a natural keystroke, since `revert-buffer' is bound to `g' in
> `special-mode'.
>
> Any opinions?

What about 'C-x g'?  I know Drew will complain about wasting 
precious keybinding.  Then maybe put it on an existing prefix map?
For example, on 'M-g'.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This reminds me that I've often found it odd that there's no global
> binding for `revert-buffer' -- I think there should be, because it's
> such a useful command.
>
> Sean suggested `C-c C-r', which is nicely mnemonic, and is natural as a
> non-complicated alternative to `C-c C-f' when trying to reload a file
> (since `C-c C-f' has a lot of annoying DWIM stuff going on).
>
> We can't use `C-c C-g', I guess, since we try to avoid keystrokes that
> involve `C-g' (since `C-g' should reliably quit), but that would also be
> a natural keystroke, since `revert-buffer' is bound to `g' in
> `special-mode'.
>
> Any opinions?

(info "(elisp) Key Binding Conventions") says C-c [^[:alpha:]] is
reserved for major modes (paraphrasing).  IIUC this binding for
revert-buffer would be global, so the C-x map would make more sense?  I
think?

C-x g would make the most sense under that assumption; unfortunately
magit-status has been using that for years now…

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> (info "(elisp) Key Binding Conventions") says C-c [^[:alpha:]] is
> reserved for major modes (paraphrasing).  IIUC this binding for
> revert-buffer would be global, so the C-x map would make more sense?  I
> think?
>
> C-x g would make the most sense under that assumption; unfortunately
> magit-status has been using that for years now…

Oh, yeah, I was thinking of `C-x C-r' and not `C-c C-r', but that's
unfortunately taken.

Hm...  the `C-x' map is pretty heavily populated.  Let's see what's
free...

C-x C-a
C-x C-y

Wow, those are the only `C-x C-<something>' not bound of the
alphabetical keys.  Neither seem extremely mnemonic for "revert"...

Perhaps `C-x C-a' for "aaargh, reload that file already!"

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Tomas Nordin]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
>
>> (info "(elisp) Key Binding Conventions") says C-c [^[:alpha:]] is
>> reserved for major modes (paraphrasing).  IIUC this binding for
>> revert-buffer would be global, so the C-x map would make more sense?  I
>> think?
>>
>> C-x g would make the most sense under that assumption; unfortunately
>> magit-status has been using that for years now…
>
> Oh, yeah, I was thinking of `C-x C-r' and not `C-c C-r', but that's
> unfortunately taken.
>
> Hm...  the `C-x' map is pretty heavily populated.  Let's see what's
> free...
>
> C-x C-a
> C-x C-y
>
> Wow, those are the only `C-x C-<something>' not bound of the
> alphabetical keys.  Neither seem extremely mnemonic for "revert"...
>
> Perhaps `C-x C-a' for "aaargh, reload that file already!"

Am I confused or did this discussion drift away from something specific
to shell command output buffers to something global always?

What was wrong with C-c C-r ? Maybe that existing binding in shell mode
('comint-show-output')? But if this new binding could be restricted to
those output buffers it might be ok? I mean, in those buffers it seems
to me that 'comint-show-output' (C-c C-r) do the same as
'beginning-of-buffer' (M-<).

--
Tomas

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Kévin Le Gouguec]

Tomas Nordin <tomasn@posteo.net> writes:

> Am I confused or did this discussion drift away from something specific
> to shell command output buffers to something global always?

Right, sorry; FWIW I'm not in a hurry to have a global binding for
revert-buffer (I've already bound it to C-c b g).  I was merely thinking
out loud about the implications of adding one.

(tl;dr "C-c map ⇒ unorthodox; C-x g ⇒ magit-status")

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Michael Welsh Duggan]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <mwd@md5i.com> writes:
>
>>> To avoid all possible conflicts, this looks harmless: 'C-c g'.
>>
>> Except key sequences consisting of `C-c' followed by a letter are
>> reserved for user-defined bindings.
>
> Indeed.
>
> This reminds me that I've often found it odd that there's no global
> binding for `revert-buffer' -- I think there should be, because it's
> such a useful command.
>
> Sean suggested `C-c C-r', which is nicely mnemonic, and is natural as a
> non-complicated alternative to `C-c C-f' when trying to reload a file
> (since `C-c C-f' has a lot of annoying DWIM stuff going on).

I've had `C-c r' as (revert-buffer t t) in my personal init file for
years.  (So I obviously agree with the mnemonic.)

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#46151: [External] : bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Drew Adams]

> This reminds me that I've often found it odd that there's no global
> binding for `revert-buffer' -- I think there should be, because it's
> such a useful command.

Yes, very useful.

Dunno whether we need to bind it to a key by
default, however.  Users who use it a lot will
bind it themselves.  And it already has various
(different) bindings in different modes.  And
for modes where it makes no sense, well, it
makes no sense. ;-)

If we do sacrifice another new key binding for
it then it should preferably not be a key that's
repeatable.

(Personally, because key `F5' does that on MS
Windows, I bind `F5' to it.  But yes, that wastes
a repeatable key.  Is `F5' used beyond MS Windows,
e.g. for web browsers on other platforms?)

> Sean suggested `C-c C-r', which is nicely mnemonic, and is natural as a
> non-complicated alternative to `C-c C-f' when trying to reload a file
> (since `C-c C-f' has a lot of annoying DWIM stuff going on).

`C-r' is conventionally an opposite to `C-s'
(e.g. for search).  It's best to save `C-r'
for some (future or 3rd-party) need where
there's an opposite action that can be bound
to `C-s'.

As an example, my code binds `C-x / C-s' and
`C-x / C-r' to commands that search forward
and backward within defined zones.

> We can't use `C-c C-g', I guess, since we try to avoid keystrokes that
> involve `C-g' (since `C-g' should reliably quit), but that would also
> be a natural keystroke, since `revert-buffer' is bound to `g' in
> `special-mode'.
> 
> Any opinions?

Overall, my opinion is to NOT bind it by default.
Yes, it's useful.

But it's also easy to do with `M-x revert'.  (And
then repeat that as a previous command, as needed.)

And it has many existing bindings, for modes where
it's used frequently.

bug#46151: [External] : bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Drew Adams]

> What about 'C-x g'?  I know Drew will complain about wasting
> precious keybinding.  Then maybe put it on an existing prefix map?
> For example, on 'M-g'.

Yep.  I gave my general opinion.  But yeah, I
don't think we need to sacrifice a key for this.

We've had `revert-buffer' since Day One.  There's
no special reason why there's more need for a
default binding for it now.  And available keys
are much rarer now than they were way back closer
to the Big Bang.

`revert-buffer' is useless in many buffers. That's
maybe one reason it has no default binding.  And
for modes where it's very useful and commonly used
it already has a binding.  IOW, the Emacs approach
has been to let the mode decide whether to bind a
key for it, presumably based on how useful it is
in that mode.

bug#46151: [External] : bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Drew Adams]

> Hm...  the `C-x' map is pretty heavily populated.  Let's see what's
> free...
> 
> C-x C-a
> C-x C-y
> 
> Wow, those are the only `C-x C-<something>' not bound of the
> alphabetical keys.  Neither seem extremely mnemonic for "revert"...
> 
> Perhaps `C-x C-a' for "aaargh, reload that file already!"

IMO, `C-x' should in general be left alone - left
for users and 3rd-party libraries.

Each time I look for something free on `C-x' (as
a user or for a library) I end up finding out that
there's some Emacs standard library that binds a
key I might have thought was free.  I have to load
standard libraries (Org, project) that I don't use,
just to see whether they diminish the `C-x' space etc.

I had a zillion keys bound on prefix key `C-x p'
(for Bookmark+), because that was free years ago.
Then you decided to give that prefix key to "Project" 
(saying explicitly, BTW that you "don't need" to pay
any heed to the fact that Drew uses that prefix key,
which is of course true).  And on and on it goes.
I choose to use prefix `C-x /' for zones.el, but
tomorrow I may find that some part of Emacs has been
given that key.

Users and 3rd-party libraries should really start to
take precedence now, IMHO.  Emacs should try not to
bind any more keys by default - starting with `C-x'.
And certainly for things like `revert-buffer', which
have survived for 35 years without a default binding.
YAGNI.

The days of virgin territory for pioneers to grab
are over. ;-)  And sometimes there are actually
indigenous 3rd parties already living there...

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

Hello,

On Sun 31 Jan 2021 at 08:37AM +01, Lars Ingebrigtsen wrote:

> This reminds me that I've often found it odd that there's no global
> binding for `revert-buffer' -- I think there should be, because it's
> such a useful command.
>
> Sean suggested `C-c C-r', which is nicely mnemonic, and is natural as a
> non-complicated alternative to `C-c C-f' when trying to reload a file
> (since `C-c C-f' has a lot of annoying DWIM stuff going on).

Well, C-c C-r is major mode territory, right?  So would not be suitable
for a global binding.

> Any opinions?

The C-x g suggestion from Juri seems the most reasonable so far.

To be honest I am inclined to agree with Drew that the command is not
worth a global binding.  Most people probably use it infrequently enough
in buffers where it does not have a local binding that they can just
access it with M-x, and those who do use it more frequently than average
can add a personal binding like C-c r.

-- 
Sean Whitton

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

Hello,

On Sat 30 Jan 2021 at 07:18AM +01, Lars Ingebrigtsen wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> This sort of thing could be pretty annoying if you happened to want to
>> type the letter 'g' and thereby reran the command ..
>
> Indeed -- I was thinking about the `M-!' case only, and whether we'd
> want to change the mode of the resulting buffer to a new mode that
> inherits from `special-mode' (and `special-mode' defines the `g'
> keystroke already).
>
> That's not appropriate for `M-&', I guess, which is in `shell-mode'...
> but is that a good mode for command output, really?

I think it's in shell-mode to facilitate interacting with the command
while it is running -- for example, using C-c C-c to sent SIGINT, and
also just typing into STDIN.

So we're talking about switching the major-mode at the point the command
exits, which seems like it could cause frustration -- imagine the
command finishes up just while you're typing into the buffer and you
happen to type 'g' ...

>> How about binding C-c C-r instead of g?  The mnemonic would be
>> Reexecute.  In *Async Shell Command* buffers this already has an
>> inherited binding but I don't believe it is one that does anything
>> useful in those buffers, so should be fine to override.
>>
>> An alternative would be to put the whole buffer in special-mode, which
>> would bind 'g', and make shell command output more like M-x compile
>> buffers.  Could have a defcustom to turn this off.
>
> Indeed.

Thinking more, I think my C-c C-r solution is the one I prefer; anyone
else in favour of that?

-- 
Sean Whitton

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Juri Linkov]

> Am I confused or did this discussion drift away from something specific
> to shell command output buffers to something global always?
>
> What was wrong with C-c C-r ? Maybe that existing binding in shell mode
> ('comint-show-output')? But if this new binding could be restricted to
> those output buffers it might be ok? I mean, in those buffers it seems
> to me that 'comint-show-output' (C-c C-r) do the same as
> 'beginning-of-buffer' (M-<).

I often need to revert the diff buffer to update it after changing
source files.  But in diff-mode C-c C-r is bound to diff-reverse-direction.
So C-c C-r can't be a universal binding in all modes that support
revert-buffer.  FWIW, I bound revert-buffer to the global C-z r.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Dmitry Gutov]

On 29.01.2021 09:21, Lars Ingebrigtsen wrote:
>> I take it a minor mode is more appropriate than a major mode for this?
>> If so, I can come up with a patch adding that to simple.el.
> Since M-! and M-& use different modes (fundamental and shell), a minor
> mode is probably the best, I guess.

Maybe have them use the same mode? The purpose of those buffers seems 
the same, just the methods they reach there are a bit different.

And if the common mode will be derived from shell-mode, why not use RET?

Its current shell-mode's binding doesn't seem useful there.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

Hello,

On Mon 01 Feb 2021 at 01:31AM +02, Dmitry Gutov wrote:

> On 29.01.2021 09:21, Lars Ingebrigtsen wrote:
>>> I take it a minor mode is more appropriate than a major mode for this?
>>> If so, I can come up with a patch adding that to simple.el.
>> Since M-! and M-& use different modes (fundamental and shell), a minor
>> mode is probably the best, I guess.
>
> Maybe have them use the same mode? The purpose of those buffers seems
> the same, just the methods they reach there are a bit different.
>
> And if the common mode will be derived from shell-mode, why not use RET?
>
> Its current shell-mode's binding doesn't seem useful there.

I think that this would have the same problem as 'g': since the buffers
are freely-editable text, just trying to type something might result in
a surprise re-execution of the command.

-- 
Sean Whitton

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Dmitry Gutov]

On 01.02.2021 02:08, Sean Whitton wrote:
> I think that this would have the same problem as 'g': since the buffers
> are freely-editable text, just trying to type something might result in
> a surprise re-execution of the command.

Fair enough.

But following that logic, having a easy global binding for revert-buffer 
(such as 'C-x g' or even 'C-c C-r') is likely to be dangerous.

It could still be possible for command output buffers, if we switch them 
to a special-mode derivative. Just how important is the ability to 
freely edit those buffers? Compared to being able to easily re-run the 
command.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

Hello,

On Mon 01 Feb 2021 at 04:08AM +02, Dmitry Gutov wrote:

> On 01.02.2021 02:08, Sean Whitton wrote:
>> I think that this would have the same problem as 'g': since the buffers
>> are freely-editable text, just trying to type something might result in
>> a surprise re-execution of the command.
>
> Fair enough.
>
> But following that logic, having a easy global binding for revert-buffer
> (such as 'C-x g' or even 'C-c C-r') is likely to be dangerous.

Sorry, I don't follow -- my point is that SPC and g are usually
self-inserting, so without having any intention of doing anything other
than typing text, you could trigger a reexecution of the command.  C-x g
and C-c C-r do not have that property.

> It could still be possible for command output buffers, if we switch
> them to a special-mode derivative. Just how important is the ability
> to freely edit those buffers? Compared to being able to easily re-run
> the command.

Well, they need to be editable while the command is running as you can
send text to process' STDIN that way.

Having them suddenly stop being editable when the command dies has the
same problem as above if the user happens to be typing 'g' a moment
after the command dies.

-- 
Sean Whitton

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> So we're talking about switching the major-mode at the point the command
> exits, which seems like it could cause frustration -- imagine the
> command finishes up just while you're typing into the buffer and you
> happen to type 'g' ...

Yeah, that wouldn't be good.

> Thinking more, I think my C-c C-r solution is the one I prefer; anyone
> else in favour of that?

I think a global `revert-buffer' binding is the way to go.  How to
reload a file is something that comes up all the time, so I think it is
high time it got bound.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: [External] : bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Drew Adams]

> I think a global `revert-buffer' binding is the way to go.  How to
> reload a file is something that comes up all the time, so I think it is
> high time it got bound.

I disagree, for reasons given before:

1. Anyone who wants it can bind it.  (I do.)

2. It has no meaning for many modes.  By its
   very nature it is essentially mode-specific.

3. Modes where it is useful typically already
   bind it.  And they bind it to a key that
   makes sense for that particular mode.
   You just need to use `C-h m' to find out
   what the key is.

4. Given #3, if you add a global binding for
   it then there's not much point in those
   mode-specific bindings.

5. Emacs has been fine for 35+ years without
   any global binding for it.  The "Founders"
   knew what they were doing in this regard.
   (Perhaps they were thinking of some of this
   list.)

6. Emacs should impose a moratorium on itself
   NOW, to stop binding keys by default.  Just
   say NO.

   Seriously.

   The few keys that still have no default
   global bindings should be left as is, in
   general - left for users and 3rd-party code.

7. IF many users start using some binding over
   a period of years THEN Emacs can consider
   giving it a default binding.  Don't be
   prematurely "optimizing" UI in this way for
   people when there has been no popular
   request for it.

8. YAGNI.

One opinion.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Hello,

On Mon 01 Feb 2021 at 09:49AM +01, Lars Ingebrigtsen wrote:

> I think a global `revert-buffer' binding is the way to go.  How to
> reload a file is something that comes up all the time, so I think it is
> high time it got bound.

Okay, here is a patch.

-- 
Sean Whitton

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Bind-revert-buffer-to-C-x-g-globally.patch --]
[-- Type: text/x-diff, Size: 2195 bytes --]

From 4e5db21270cebc6027ad991bffb6e48756f00191 Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhitton@spwhitton.name>
Date: Mon, 1 Feb 2021 10:56:49 -0700
Subject: [PATCH] Bind 'revert-buffer' to 'C-x g' globally

* lisp/bindings.el: Bind 'revert-buffer' to 'C-x g' globally.
* doc/emacs/files.texi: Replace 'M-x revert-buffer' with 'C-x g'.
* etc/NEWS: Document the change.
---
 doc/emacs/files.texi | 6 +++---
 etc/NEWS             | 3 +++
 lisp/bindings.el     | 2 ++
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index ede382c146..12ceac800e 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -927,9 +927,9 @@ Manual}).  For customizations, see the Custom group @code{time-stamp}.
 
   If you have made extensive changes to a file-visiting buffer and
 then change your mind, you can @dfn{revert} the changes and go back to
-the saved version of the file.  To do this, type @kbd{M-x
-revert-buffer}.  Since reverting unintentionally could lose a lot of
-work, Emacs asks for confirmation first.
+the saved version of the file.  To do this, type @kbd{C-x g}.  Since
+reverting unintentionally could lose a lot of work, Emacs asks for
+confirmation first.
 
   The @code{revert-buffer} command tries to position point in such a
 way that, if the file was edited only slightly, you will be at
diff --git a/etc/NEWS b/etc/NEWS
index 29499639e7..c8c9535cfb 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -233,6 +233,9 @@ search string is at least this long.  'lazy-highlight-initial-delay'
 still applies for shorter search strings, which avoids flicker in the
 search buffer due to too many matches being highlighted.
 
++++
+** 'revert-buffer' is now bound to 'C-x g' globally.
+
 \f
 * Editing Changes in Emacs 28.1
 
diff --git a/lisp/bindings.el b/lisp/bindings.el
index 43b62f9bbf..9ea188d1a0 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -1413,6 +1413,8 @@ if `inhibit-field-text-motion' is non-nil."
 
 (define-key ctl-x-map "z" 'repeat)
 
+(define-key ctl-x-map "g" #'revert-buffer)
+
 (define-key esc-map "\C-l" 'reposition-window)
 
 (define-key ctl-x-4-map "a" 'add-change-log-entry-other-window)
-- 
2.29.2

bug#46151: [External] : bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Drew Adams]

> > I think a global `revert-buffer' binding is the way to go.  How to
> > reload a file is something that comes up all the time, so I think it
> > is high time it got bound.
> 
> Okay, here is a patch.

Please don't do this.  Don't remove `C-x g' from
the little remaining virgin (non-default) key
territory.

It is not "high time" to bind this or any other
key by default.  It's high time to _desist_ from
having default Emacs taking over more territory.
It doesn't need it, and it shouldn't take it.

35 years with no global binding for `revert-buffer'.
No problem - thousands of users and hackers.  But
now, from one user request Lars decides it's "high
time"...  No need.

All proposals to sacrifice keys to default bindings
should really be discussed on emacs-devel.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Dmitry Gutov]

On 01.02.2021 07:44, Sean Whitton wrote:

> Sorry, I don't follow -- my point is that SPC and g are usually
> self-inserting, so without having any intention of doing anything other
> than typing text, you could trigger a reexecution of the command.  C-x g
> and C-c C-r do not have that property.

My point is that we could make them all, normally, not self-inserting.

>> It could still be possible for command output buffers, if we switch
>> them to a special-mode derivative. Just how important is the ability
>> to freely edit those buffers? Compared to being able to easily re-run
>> the command.
> 
> Well, they need to be editable while the command is running as you can
> send text to process' STDIN that way.

I see. I hadn't considered that scenario...

> Having them suddenly stop being editable when the command dies has the
> same problem as above if the user happens to be typing 'g' a moment
> after the command dies.

...though, come to think of it, I routinely use a Compilation-based mode 
(rspec-compilation-mode), where I need to switch to a different major 
mode temporarily for debugging and shell-like interaction, and then back 
to rspec-compilation-mode when I'm finished. That works okay.

So it wouldn't be too terrible if the major mode is switched to 
something else when the process finishes. The user will likely learn 
than quickly, and managing to type 'g' before learning it is fairly 
improbable.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Dmitry Gutov]

On 01.02.2021 10:49, Lars Ingebrigtsen wrote:
> I think a global `revert-buffer' binding is the way to go.  How to
> reload a file is something that comes up all the time, so I think it is
> high time it got bound.

My general feeling is that novice users don't often have a reason to 
call 'revert-buffer' manually (aside from major modes which already have 
a 'g' binding), and the power users generally already have some other 
command on 'C-x g' already (like magit-status or project-find-regexp).

So the target audience for that chance seems limited.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Sean Whitton]

Hello,

On Mon 01 Feb 2021 at 10:04PM +02, Dmitry Gutov wrote:

> So it wouldn't be too terrible if the major mode is switched to
> something else when the process finishes. The user will likely learn
> than quickly, and managing to type 'g' before learning it is fairly
> improbable.

The sort of thing I had in mind was the process dying unexpectedly while
you'd typing into STDIN.

-- 
Sean Whitton

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Dmitry Gutov]

On 01.02.2021 22:49, Sean Whitton wrote:
> The sort of thing I had in mind was the process dying unexpectedly while
> you'd typing into STDIN.

All right, then.

Never experienced that myself, but I guess that's what Emacs is for: 
enabling all sorts of different workflows.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

>> I think a global `revert-buffer' binding is the way to go.  How to
>> reload a file is something that comes up all the time, so I think it is
>> high time it got bound.
>
> Okay, here is a patch.

Thanks; applied to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 01.02.2021 10:49, Lars Ingebrigtsen wrote:
>> I think a global `revert-buffer' binding is the way to go.  How to
>> reload a file is something that comes up all the time, so I think it is
>> high time it got bound.
>
> My general feeling is that novice users don't often have a reason to
> call 'revert-buffer' manually (aside from major modes which already
> have a 'g' binding), and the power users generally already have some
> other command on 'C-x g' already (like magit-status or
> project-find-regexp).
>
> So the target audience for that chance seems limited.

The impetus for introducing this binding now is that we have two cases
of a non-special mode with a (very) useful `revert-buffer' binding, so
we can't use `g' there.  So it's time to give it a global binding.

But I disagree that it's not a useful general command for non-power
users: A common question is "how do I reload a file?", and we didn't
have a key binding for that.  `C-x C-f' does not reliably reload a file,
since it has DWIM stuff going on.

So giving the command a global binding fixes both these things.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Dmitry Gutov]

On 02.02.2021 10:49, Lars Ingebrigtsen wrote:

> The impetus for introducing this binding now is that we have two cases
> of a non-special mode with a (very) useful `revert-buffer' binding, so
> we can't use `g' there.  So it's time to give it a global binding.

I offered an alternative suggestion for how 'g' could work (prohibit 
free editing when the command finishes). Or perhaps some of the other 
suggestions could be taken and standardized on for similar circumstances 
('C-c C-g' might be appropriate since it's major mode specific).

I think it's a nice property that major modes that have this binding 
implement some special behavior for reverting. And all that do, have 
this binding.

But now, if a global binding is added, I worry that people might abandon 
that convention.

> But I disagree that it's not a useful general command for non-power
> users: A common question is "how do I reload a file?", and we didn't
> have a key binding for that.  `C-x C-f' does not reliably reload a file,
> since it has DWIM stuff going on.

Isn't the answer to most such questions, 'enable global-auto-revert-mode'?

I do revert buffers explicitly from time to time too (especially when 
developing or debugging certain Elisp packages), but still not often 
enough to worry about having to type 'M-x revert-buffer'.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I offered an alternative suggestion for how 'g' could work (prohibit
> free editing when the command finishes). Or perhaps some of the other
> suggestions could be taken and standardized on for similar
> circumstances ('C-c C-g' might be appropriate since it's major mode
> specific).
>
> I think it's a nice property that major modes that have this binding
> implement some special behavior for reverting. And all that do, have
> this binding.
>
> But now, if a global binding is added, I worry that people might
> abandon that convention.

I don't think modes will stop creating reversion functions, and I think
special modes will continue to bind `g' -- it's more convenient than
`C-x g', after all.  So I don't think this is much to worry about.

>> But I disagree that it's not a useful general command for non-power
>> users: A common question is "how do I reload a file?", and we didn't
>> have a key binding for that.  `C-x C-f' does not reliably reload a file,
>> since it has DWIM stuff going on.
>
> Isn't the answer to most such questions, 'enable global-auto-revert-mode'?

No, I think `global-auto-revert-mode' is something most people don't
want.  For instance, if you're looking at /var/log/exim4/mainlog in
Emacs (which I do sometimes), you do not want that to be reloaded all
the time, because that would make it difficult to get any work done in
that buffer.  But you do want to reload it occasionally.

> I do revert buffers explicitly from time to time too (especially when
> developing or debugging certain Elisp packages), but still not often
> enough to worry about having to type 'M-x revert-buffer'.

I do it quite often (both in the log file case and because I apply
patches a lot).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Dmitry Gutov]

On 03.02.2021 20:36, Lars Ingebrigtsen wrote:

>> I think it's a nice property that major modes that have this binding
>> implement some special behavior for reverting. And all that do, have
>> this binding.
>>
>> But now, if a global binding is added, I worry that people might
>> abandon that convention.
> 
> I don't think modes will stop creating reversion functions, and I think
> special modes will continue to bind `g' -- it's more convenient than
> `C-x g', after all.  So I don't think this is much to worry about.

I hope so.

OTOH, I think it might seem perfectly reasonable for some future 
maintainer to stop that practice because, after all, a handy global 
binding already exists.

For example, this bug can be considered only halfway fixed for anyone 
who uses 'C-x g' for other purposes. It's not a big deal in one 
instance, only as part of a possible future trend.

>>> But I disagree that it's not a useful general command for non-power
>>> users: A common question is "how do I reload a file?", and we didn't
>>> have a key binding for that.  `C-x C-f' does not reliably reload a file,
>>> since it has DWIM stuff going on.
>>
>> Isn't the answer to most such questions, 'enable global-auto-revert-mode'?
> 
> No, I think `global-auto-revert-mode' is something most people don't
> want.  For instance, if you're looking at /var/log/exim4/mainlog in
> Emacs (which I do sometimes), you do not want that to be reloaded all
> the time, because that would make it difficult to get any work done in
> that buffer.  But you do want to reload it occasionally.

Avoiding a feature that saves people time on account of certain rare 
buffers being more difficult seems counter-productive. It's like giving 
up on automatic transmission on account of the existence of hills.

Even if somebody doesn't want to use auto-revert is all buffers, 
toggling auto-revert-mode on only in certain ones is bound to save them 
time. Or people can explicitly disable the mode in certain buffers, like 
ones showing log files. Does 'exim4/mainlog' have a dedicated major 
mode? It can go in global-auto-revert-ignore-modes.

I can understand calling revert-buffer manually if you're editing a few 
files, but if you're working on a larger project and switch to a 
different Git branch with multiple buffers open, that's unmanageable.

Almost all editors I used have this feature on by default (except Vim, I 
guess?), so there is a consensus there.

>> I do revert buffers explicitly from time to time too (especially when
>> developing or debugging certain Elisp packages), but still not often
>> enough to worry about having to type 'M-x revert-buffer'.
> 
> I do it quite often (both in the log file case and because I apply
> patches a lot).

FWIW, I apply patches with diff-mode.

bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I can understand calling revert-buffer manually if you're editing a
> few files, but if you're working on a larger project and switch to a
> different Git branch with multiple buffers open, that's unmanageable.

People have different use cases -- that shouldn't be a surprise.  Emacs
caters to them all, but I think there was an obvious usability hole here
to be fixed for one of the use cases, so I did.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no