bug#49869: Revert buffer? Yes/No/Maybe

bug#49869: Revert buffer? Yes/No/Maybe

[Juri Linkov]

There is a new short keybinding to revert the current buffer -
just 3 keys: 'C-x x g'.  But then it asks for a confirmation
with 4 keys: 'y e s RET' that is even longer than the command keys.
This defeats the purpose of having the short key sequence.
Does 'C-x x g' really need a confirmation?

I propose to revert the buffer immediately after typing 'C-x x g'.

bug#49869: Revert buffer? Yes/No/Maybe

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> There is a new short keybinding to revert the current buffer -
> just 3 keys: 'C-x x g'.  But then it asks for a confirmation
> with 4 keys: 'y e s RET' that is even longer than the command keys.
> This defeats the purpose of having the short key sequence.
> Does 'C-x x g' really need a confirmation?
>
> I propose to revert the buffer immediately after typing 'C-x x g'.

I think I agree...  if the buffer hasn't been changed.  So we could bind
it to a new command, like revert-buffer-command, that would call
revert-buffer with NOCONFIRM if the buffer hasn't been edited?

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

bug#49869: Revert buffer? Yes/No/Maybe

[Andreas Schwab]

On Aug 04 2021, Juri Linkov wrote:

> There is a new short keybinding to revert the current buffer -
> just 3 keys: 'C-x x g'.  But then it asks for a confirmation
> with 4 keys: 'y e s RET' that is even longer than the command keys.
> This defeats the purpose of having the short key sequence.
> Does 'C-x x g' really need a confirmation?

I don't see why confirmation should depend on how the command is
executed.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#49869: Revert buffer? Yes/No/Maybe

[Gregory Heytings]

>> There is a new short keybinding to revert the current buffer - just 3 
>> keys: 'C-x x g'.  But then it asks for a confirmation with 4 keys: 'y e 
>> s RET' that is even longer than the command keys. This defeats the 
>> purpose of having the short key sequence. Does 'C-x x g' really need a 
>> confirmation?
>>
>> I propose to revert the buffer immediately after typing 'C-x x g'.
>
> I think I agree...  if the buffer hasn't been changed.  So we could bind 
> it to a new command, like revert-buffer-command, that would call 
> revert-buffer with NOCONFIRM if the buffer hasn't been edited?
>

What about:

(defun revert-buffer-short-confirm (&optional args)
   (interactive (list (not current-prefix-arg)))
   (cl-letf (((symbol-function 'yes-or-no-p) 'y-or-n-p))
     (revert-buffer args)))

(global-set-key (kbd "C-x x g") 'revert-buffer-short-confirm)

?

bug#49869: Revert buffer? Yes/No/Maybe

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 04 Aug 2021 11:45:18 +0300
> 
> There is a new short keybinding to revert the current buffer -
> just 3 keys: 'C-x x g'.  But then it asks for a confirmation
> with 4 keys: 'y e s RET' that is even longer than the command keys.
> This defeats the purpose of having the short key sequence.
> Does 'C-x x g' really need a confirmation?

It's quite a drastic measure, so I think it does need a confirmation.
E.g., if the changes you revert exceed the value of undo-limit, you
could really lose your edits.

Since we now have the use-short-answers option, why is it a problem to
have to confirm, if you could make it a single key?

bug#49869: Revert buffer? Yes/No/Maybe

[Gregory Heytings]

>> There is a new short keybinding to revert the current buffer - just 3 
>> keys: 'C-x x g'.  But then it asks for a confirmation with 4 keys: 'y e 
>> s RET' that is even longer than the command keys. This defeats the 
>> purpose of having the short key sequence. Does 'C-x x g' really need a 
>> confirmation?
>
> It's quite a drastic measure, so I think it does need a confirmation. 
> E.g., if the changes you revert exceed the value of undo-limit, you 
> could really lose your edits.
>
> Since we now have the use-short-answers option, why is it a problem to 
> have to confirm, if you could make it a single key?
>

I had forgotten about use-short-answers, it makes the proposed solution 
even shorter:

(defun revert-buffer-short-answer (&optional args)
   (interactive (list (not current-prefix-arg)))
   (let ((use-short-answers t))
     (revert-buffer args)))

(global-set-key (kbd "C-x x g") 'revert-buffer-short-answer)

bug#49869: Revert buffer? Yes/No/Maybe

[Eli Zaretskii]

> Date: Wed, 04 Aug 2021 12:22:09 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Juri Linkov <juri@linkov.net>, 49869@debbugs.gnu.org
> 
> (defun revert-buffer-short-answer (&optional args)
>    (interactive (list (not current-prefix-arg)))
>    (let ((use-short-answers t))
>      (revert-buffer args)))
> 
> (global-set-key (kbd "C-x x g") 'revert-buffer-short-answer)

If you propose this as something people who want this could do in
their init files, then I agree.

bug#49869: Revert buffer? Yes/No/Maybe

[Gregory Heytings]

>> (defun revert-buffer-short-answer (&optional args)
>>    (interactive (list (not current-prefix-arg)))
>>    (let ((use-short-answers t))
>>      (revert-buffer args)))
>>
>> (global-set-key (kbd "C-x x g") 'revert-buffer-short-answer)
>
> If you propose this as something people who want this could do in their 
> init files, then I agree.
>

No, I propose this as a solution to Juri's problem, instead of his 
proposed solution to "revert the buffer immediately" with C-x x g, which 
is indeed too drastic.  Something even better to take Lars' suggestion (do 
not ask confirmation when the buffer has not been modified) into account:

(defun revert-buffer-short-answer (&optional ignore-auto noconfirm preserve-modes)
   (interactive (list (not current-prefix-arg)))
   (let ((use-short-answers t)
 	(noconfirm (not (buffer-modified-p))))
     (revert-buffer ignore-auto noconfirm preserve-modes)))

bug#49869: Revert buffer? Yes/No/Maybe

[Eli Zaretskii]

> Date: Wed, 04 Aug 2021 12:37:43 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: juri@linkov.net, 49869@debbugs.gnu.org
> 
> >> (global-set-key (kbd "C-x x g") 'revert-buffer-short-answer)
> >
> > If you propose this as something people who want this could do in their 
> > init files, then I agree.
> >
> 
> No, I propose this as a solution to Juri's problem, instead of his 
> proposed solution to "revert the buffer immediately" with C-x x g, which 
> is indeed too drastic.  Something even better to take Lars' suggestion (do 
> not ask confirmation when the buffer has not been modified) into account:

I don't think we need to cater to personal preferences by adding new
commands.  The user option exists so that users could customize the
behavior to their liking without requiring us to provide a solution
for every personal taste.

bug#49869: Revert buffer? Yes/No/Maybe

[Gregory Heytings]

>> No, I propose this as a solution to Juri's problem, instead of his 
>> proposed solution to "revert the buffer immediately" with C-x x g, 
>> which is indeed too drastic.  Something even better to take Lars' 
>> suggestion (do not ask confirmation when the buffer has not been 
>> modified) into account:
>
> I don't think we need to cater to personal preferences by adding new 
> commands.  The user option exists so that users could customize the 
> behavior to their liking without requiring us to provide a solution for 
> every personal taste.
>

I don't know.  I did not ask for this, but Juri's remark (that with a 
default configuration the confirmation uses more keystrokes than the 
command itself) makes sense to me.  And setting the user option has a 
global effect, not just on this particular command.  But it's up to the 
maintainers to decide what's the right way to go.

bug#49869: Revert buffer? Yes/No/Maybe

[Juri Linkov]

> Since we now have the use-short-answers option, why is it a problem to
> have to confirm, if you could make it a single key?

The problem is that by default the length of the key sequence
when the user decides to revert the current buffer
is 7 keys:

  'C-x x g y e s RET'

With the patch provided by Gregory the default length
will be reduced to 4 keys:

  'C-x x g y'

or to 3 keys when there are no unsaved changes.

The yes/no question is still asked when revert-buffer
is called automatically - that makes sense.
But when the user decided to revert the buffer explicitly,
why require to type more keys?

bug#49869: Revert buffer? Yes/No/Maybe

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 49869@debbugs.gnu.org
> Date: Wed, 04 Aug 2021 23:43:43 +0300
> 
> > Since we now have the use-short-answers option, why is it a problem to
> > have to confirm, if you could make it a single key?
> 
> The problem is that by default the length of the key sequence
> when the user decides to revert the current buffer
> is 7 keys:
> 
>   'C-x x g y e s RET'
> 
> With the patch provided by Gregory the default length
> will be reduced to 4 keys:
> 
>   'C-x x g y'
> 
> or to 3 keys when there are no unsaved changes.

First, you can have those 4 keys if you customize use-short-answers;
no changes in Emacs are necessary.

And second, are you talking only about reverting when there are no
unsaved changes?  If so, what are the use cases when you need to do
such a thing, and why?  Perhaps such use cases justify a separate
command and key binding, like "C-x RET r" does for one such use case.

> But when the user decided to revert the buffer explicitly,
> why require to type more keys?

In general, when there are unsaved changes?  To let the user think one
last time before doing something potentially very destructive.

bug#49869: Revert buffer? Yes/No/Maybe

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think we need to cater to personal preferences by adding new
> commands.

The `C-x x g' binding is new in Emacs 28, and we can bind it to a
command that we thing is a good one.

Eli Zaretskii <eliz@gnu.org> writes:

> And second, are you talking only about reverting when there are no
> unsaved changes?  If so, what are the use cases when you need to do
> such a thing, and why?

When a file changes outside of Emacs.  It happens a lot, especially
after doing "git pull".

But...  looking at how Emacs handles this in other similar commands, I'm
not convinced that the `y e s RET' is excessive in `C-x x g': For
instance, if you `C-x C-f M-n RET' (which was the previous way to revert
the buffer (but didn't work reliably because of DWIM)), it'll also ask
you to type `y e s RET' afterwards.

So for user interface consistency, I think it might make sense to leave
`C-x x g' as is -- at least in the default case.  Perhaps there should
be a user option to customise the level of prompting here.

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

bug#49869: Revert buffer? Yes/No/Maybe

[Gregory Heytings]

>
> Perhaps there should be a user option to customise the level of 
> prompting here.
>

Like this:

(defcustom revert-buffer-short-answer nil "")

(defun revert-buffer-short-answer (&optional ignore-auto noconfirm preserve-modes)
   (interactive (list (not current-prefix-arg)))
   (if revert-buffer-short-answer
       (let ((use-short-answers t)
 	    (noconfirm (not (buffer-modified-p))))
 	(revert-buffer ignore-auto noconfirm preserve-modes))
     (revert-buffer ignore-auto noconfirm preserve-modes)))

(global-set-key (kbd "C-x x g") 'revert-buffer-short-answer)

?

bug#49869: Revert buffer? Yes/No/Maybe

[Juri Linkov]

>> The problem is that by default the length of the key sequence
>> when the user decides to revert the current buffer
>> is 7 keys:
>>
>>   'C-x x g y e s RET'
>>
>> With the patch provided by Gregory the default length
>> will be reduced to 4 keys:
>>
>>   'C-x x g y'
>>
>> or to 3 keys when there are no unsaved changes.
>
> First, you can have those 4 keys if you customize use-short-answers;
> no changes in Emacs are necessary.
>
> And second, are you talking only about reverting when there are no
> unsaved changes?  If so, what are the use cases when you need to do
> such a thing, and why?  Perhaps such use cases justify a separate
> command and key binding, like "C-x RET r" does for one such use case.

I discovered this problem while editing source code in one
Emacs instance, and updating the source file in `emacs -Q`.
To get an updated version of the file in `emacs -Q` required
typing 4 more keys after every revert.

>> But when the user decided to revert the buffer explicitly,
>> why require to type more keys?
>
> In general, when there are unsaved changes?  To let the user think one
> last time before doing something potentially very destructive.

The question was why require typing more keys
when there are no unsaved changes.

bug#49869: Revert buffer? Yes/No/Maybe

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 49869@debbugs.gnu.org
> Date: Fri, 06 Aug 2021 02:33:55 +0300
> 
> > And second, are you talking only about reverting when there are no
> > unsaved changes?  If so, what are the use cases when you need to do
> > such a thing, and why?  Perhaps such use cases justify a separate
> > command and key binding, like "C-x RET r" does for one such use case.
> 
> I discovered this problem while editing source code in one
> Emacs instance, and updating the source file in `emacs -Q`.
> To get an updated version of the file in `emacs -Q` required
> typing 4 more keys after every revert.

If this is a frequent use case, we could have a separate command for
it.

> >> But when the user decided to revert the buffer explicitly,
> >> why require to type more keys?
> >
> > In general, when there are unsaved changes?  To let the user think one
> > last time before doing something potentially very destructive.
> 
> The question was why require typing more keys
> when there are no unsaved changes.

In the use case you described, depending on the situation, you could
still be in danger of losing important parts of the buffer text, even
though you have no unsaved changes.  E.g., imagine that for some
reason the file on disk is empty or omits most of your current buffer
contents.  Wouldn't you in general want at least the check for size
differences between the two, with a request for confirmation if the
sizes differ too much?  And maybe also time stamp differences?

IOW, this use case seems to really call for a separate command with a
separate logic.  If we provide such a command, then perhaps we could
make it omit the confirmation prompt when invoked with C-u, for those
cases where you know in advance you want to revert unconditionally,
for example if it was you who made the external changes just now.

But I don't think it makes sense to tweak the general-purpose
revert-buffer command in this direction, as revert-buffer supports
many other use cases, where this kind of shortcut could produce
disastrous results.

bug#49869: Revert buffer? Yes/No/Maybe

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Like this:
>
> (defcustom revert-buffer-short-answer nil "")
>
> (defun revert-buffer-short-answer (&optional ignore-auto noconfirm preserve-modes)
>   (interactive (list (not current-prefix-arg)))
>   (if revert-buffer-short-answer
>       (let ((use-short-answers t)
> 	    (noconfirm (not (buffer-modified-p))))
> 	(revert-buffer ignore-auto noconfirm preserve-modes))
>     (revert-buffer ignore-auto noconfirm preserve-modes)))
>
> (global-set-key (kbd "C-x x g") 'revert-buffer-short-answer)

Yes, something like that looks pretty nice.  But probably under a
different name (at least for the user option) to avoid confusion with
the `revert-buffer' command.

Uhm...  I have no ideas.  :-)

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

bug#49869: Revert buffer? Yes/No/Maybe

[Juri Linkov]

>> (defcustom revert-buffer-short-answer nil "")
>>
>> (defun revert-buffer-short-answer (&optional ignore-auto noconfirm preserve-modes)
>>   (interactive (list (not current-prefix-arg)))
>>   (if revert-buffer-short-answer
>>       (let ((use-short-answers t)
>> 	    (noconfirm (not (buffer-modified-p))))
>> 	(revert-buffer ignore-auto noconfirm preserve-modes))
>>     (revert-buffer ignore-auto noconfirm preserve-modes)))
>>
>> (global-set-key (kbd "C-x x g") 'revert-buffer-short-answer)
>
> Yes, something like that looks pretty nice.  But probably under a
> different name (at least for the user option) to avoid confusion with
> the `revert-buffer' command.
>
> Uhm...  I have no ideas.  :-)

Maybe revert-buffer-quick?

bug#49869: [External] : bug#49869: Revert buffer? Yes/No/Maybe

[Drew Adams]

> > under a different name (at least for the user option)
> > to avoid confusion with the `revert-buffer' command.
> 
> Maybe revert-buffer-quick?

This is the real revert-buffer-quick.  I bind it to F5,
as that's the key for this everywhere in MS Windows.

 (defun revert-buffer-no-confirm ()
   "Revert buffer without confirmation."
   (interactive) (revert-buffer t t))

And no, we shouldn't have sacrificed `C-x g' for global
buffer reverting.  Anyone could bind such a command; no
need to waste another key by default.

bug#49869: Revert buffer? Yes/No/Maybe

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Maybe revert-buffer-quick?

Yup.  Now pushed to Emacs 28 -- it seems to have good ergonomics, but
might need more polish.

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