Subject: RE: [External] : Re: bug#78124: 30.1; `revert-buffer' regression

From: Drew Adams <[email-masked]>
Date: Tue, 29 Apr 2025 16:58:05 +0000

> tags 78124 notabug
> 
> > emacs -Q
> > Visit any file, say foo.el.
> > Use `C-x C-q' to make the buffer read-only.
> > M-: (revert-buffer t t)
> > The buffer should be changed back to writable, but it remains
> > read-only.  This is not the case in any prior Emacs release.
> 
> This is a (new) feature.  The behavior change was in Emacs 29, where
> we have this in NEWS:
> 
>   ** Explicitly-set read-only state is preserved when reverting a
>      buffer.
>   If you use the 'C-x C-q' command to change the read-only state of the
>   buffer and then revert it, Emacs would previously use the file
>   permission bits to determine whether the buffer should be read-only
>   after reverting the buffer.  Emacs now remembers the decision made in
>   'C-x C-q'.

It doesn't "remember the decision" made to insert or
delete chars or add text properties, or ...  What's
so special about the buffer writability state that
it needs to be preserved, rather than reflecting the
file's writability state?  What's next, automatically
keep added text properties by default?

> The change was (briefly) discussed in bug#35166.

But not in emacs-devel?  (Why not?)

> If you want back the previous behavior, you can define your own
> function that is the value of revert-buffer-restore-functions (e.g.,
> set it to nil).

Thank you for that info.

> > I bind this command to F5, so the key reverts, as on Windows:
> >
> > (defun revert-buffer-no-confirm ()
> >   "Revert buffer without confirmation."
> >   (interactive) (revert-buffer t t))
> >
> > Useless now.
> 
> You can change that trivially to restore the behavior you expect.

Wow!  So we've now abandoned the usual behavior of
requiring opt-in for non-backward-compatible behavior.

That the behavior is now user-configurable is a _good_
thing (though why not a user option?).  But it's a bad
thing that the default behavior is not the decades-old
one: fidelity to the persisted state of the file.

What did this save?  A user having to do `C-x C-q' to
make the buffer state as it corresponds to the file
read-only again?  Why shouldn't changing a buffer's
writability from that of its file have to be done
explicitly in this case, at least by default, as is
required generally?

Sure, knowledgeable users can "trivially restore" the
longstanding behavior.  I guess we can be thankful for
that, at least.  (And I am thankful to learn now how
to disable the altered behavior.)

But why wasn't the initial value of the variable nil?
Why wasn't this "don't.reflect.file.writability.state"
behavior _opt-in_, like all other don't.reflect.file
behaviors?

Even dinky little `revert-buffer-quick-short-answers'
is a user option.  Why not this variable as well?

For an end user to obtain the longstanding behavior,
s?he now needs to fiddle with Emacs Lisp in an init
file, including adding a declaration to quiet the byte
compiler: `(defvar revert-buffer-restore-functions)'.

What was the logic behind this user-unfriendly change?
Was this discussed in emacs-devel?  Sorry I missed it.

  On n'arrête pas le progrès ...
___

Doc nits, FWIW:

"Each of these functions are called" -> "is", not "are".
"Each" is singular.

"return a lambda" and "these lambdas will be called":
not conventional for our docs (or for other Lisp docs).
"Lambda expression", "lambda form", or "anonymous
function" is better.  The Elisp manual uses those terms.
(Same problem in Elisp node `Reverting'.)

"called one by one in the order of the list": just say
they're called in order; the order is obvious.  (And
the manual doesn't even bother to mention the order.)