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

Previous Next

Full log

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

Previous Next

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