GNU bug report logs - #46151
28.0.50; Set revert-buffer-function in shell command output buffers

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46151 in the body.
You can then email your comments to 46151 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Set revert-buffer-function in shell command output buffers
Date: Wed, 27 Jan 2021 23:22:53 -0700

[Message part 1 (text/plain, inline)]

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

[0001-Set-revert-buffer-function-in-shell-command-output-b.patch (text/x-diff, attachment)]

Message #10 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Fri, 29 Jan 2021 06:52:06 +0100

Sean Whitton <spwhitton <at> 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

Message #13 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Fri, 29 Jan 2021 00:05:37 -0700

[Message part 1 (text/plain, inline)]

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

> Sean Whitton <spwhitton <at> 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

[0001-Fix-previous-commit-regarding-revert-buffer-function.patch (text/x-diff, attachment)]

Message #16 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Fri, 29 Jan 2021 08:21:39 +0100

Sean Whitton <spwhitton <at> 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

Message #19 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Fri, 29 Jan 2021 11:32:58 -0700

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

Message #22 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sat, 30 Jan 2021 07:18:15 +0100

Sean Whitton <spwhitton <at> 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

Message #25 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sat, 30 Jan 2021 20:36:51 +0200

> 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'.

Message #28 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>, Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,
 "46151 <at> debbugs.gnu.org" <46151 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#46151: 28.0.50; Set revert-buffer-function in
 shell command output buffers
Date: Sat, 30 Jan 2021 21:01:05 +0000

> 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?

Message #31 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 46151 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sat, 30 Jan 2021 23:02:51 -0500

Juri Linkov <juri <at> 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 <at> md5i.com)

Message #34 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Welsh Duggan <mwd <at> md5i.com>
Cc: Sean Whitton <spwhitton <at> spwhitton.name>, 46151 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 08:37:47 +0100

Michael Welsh Duggan <mwd <at> 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

Message #37 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#46151: 28.0.50;
 Set revert-buffer-function in shell command output buffers
Date: Sun, 31 Jan 2021 10:46:15 +0100

Lars Ingebrigtsen <larsi <at> 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…

Message #40 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>, 46151 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 11:20:11 +0200

> 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'.

Message #43 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 10:54:46 +0100

Kévin Le Gouguec <kevin.legouguec <at> 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

Message #46 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Tomas Nordin <tomasn <at> posteo.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Kévin Le Gouguec
 <kevin.legouguec <at> gmail.com>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 11:48:05 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Kévin Le Gouguec <kevin.legouguec <at> 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

Message #49 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Tomas Nordin <tomasn <at> posteo.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 14:06:00 +0100

Tomas Nordin <tomasn <at> 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")

Message #52 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 Sean Whitton <spwhitton <at> spwhitton.name>, 46151 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 11:07:58 -0500

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Michael Welsh Duggan <mwd <at> 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 <at> md5i.com)

Message #55 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Michael Welsh Duggan <mwd <at> md5i.com>
Cc: Sean Whitton <spwhitton <at> spwhitton.name>,
 "46151 <at> debbugs.gnu.org" <46151 <at> debbugs.gnu.org>, Juri Linkov <juri <at> linkov.net>
Subject: RE: [External] : bug#46151: 28.0.50; Set revert-buffer-function in
 shell command output buffers
Date: Sun, 31 Jan 2021 17:57:02 +0000

> 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.

Message #58 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 "46151 <at> debbugs.gnu.org" <46151 <at> debbugs.gnu.org>,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: RE: [External] : bug#46151: 28.0.50; Set revert-buffer-function in
 shell command output buffers
Date: Sun, 31 Jan 2021 18:03:43 +0000

> 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.

Message #61 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Kévin Le Gouguec
 <kevin.legouguec <at> gmail.com>
Cc: "46151 <at> debbugs.gnu.org" <46151 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#46151: 28.0.50; Set revert-buffer-function in
 shell command output buffers
Date: Sun, 31 Jan 2021 18:20:02 +0000

> 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...

Message #64 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Michael Welsh Duggan <mwd <at> md5i.com>
Cc: 46151 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 11:47:12 -0700

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

Message #67 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 11:50:26 -0700

Hello,

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

> Sean Whitton <spwhitton <at> 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

Message #70 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Tomas Nordin <tomasn <at> posteo.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 46151 <at> debbugs.gnu.org,
 Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 23:35:56 +0200

> 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.

Message #73 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Mon, 1 Feb 2021 01:31:25 +0200

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.

Message #76 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 17:08:31 -0700

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

Message #79 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Mon, 1 Feb 2021 04:08:33 +0200

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.

Message #82 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Sun, 31 Jan 2021 22:44:35 -0700

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

Message #85 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Mon, 01 Feb 2021 09:49:46 +0100

Sean Whitton <spwhitton <at> 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

Message #88 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Sean Whitton <spwhitton <at> spwhitton.name>
Cc: "46151 <at> debbugs.gnu.org" <46151 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#46151: 28.0.50; Set revert-buffer-function in
 shell command output buffers
Date: Mon, 1 Feb 2021 16:14:13 +0000

> 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.

Message #91 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Mon, 01 Feb 2021 11:00:22 -0700

[Message part 1 (text/plain, inline)]

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

[0001-Bind-revert-buffer-to-C-x-g-globally.patch (text/x-diff, attachment)]

Message #94 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "46151 <at> debbugs.gnu.org" <46151 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#46151: 28.0.50; Set revert-buffer-function in
 shell command output buffers
Date: Mon, 1 Feb 2021 19:43:11 +0000

> > 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.

Message #97 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Mon, 1 Feb 2021 22:04:54 +0200

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.

Message #100 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Mon, 1 Feb 2021 22:13:49 +0200

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.

Message #103 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Mon, 01 Feb 2021 13:49:29 -0700

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

Message #106 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Mon, 1 Feb 2021 23:30:12 +0200

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.

Message #109 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 46151 <at> debbugs.gnu.org
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Tue, 02 Feb 2021 09:44:57 +0100

Sean Whitton <spwhitton <at> 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

Message #116 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 46151 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Tue, 02 Feb 2021 09:49:14 +0100

Dmitry Gutov <dgutov <at> 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

Message #119 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Tue, 2 Feb 2021 14:38:28 +0200

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'.

Message #122 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 46151 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Wed, 03 Feb 2021 19:36:48 +0100

Dmitry Gutov <dgutov <at> 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

Message #125 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46151 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Thu, 4 Feb 2021 00:46:44 +0200

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.

Message #128 received at 46151 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 46151 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#46151: 28.0.50; Set revert-buffer-function in shell command
 output buffers
Date: Thu, 04 Feb 2021 08:51:03 +0100

Dmitry Gutov <dgutov <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.