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.