GNU bug report logs - #78124
30.1; `revert-buffer' regression

Previous Next

To reply to this bug, email your comments to 78124 AT debbugs.gnu.org.

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 30.1; `revert-buffer' regression
Date: Mon, 28 Apr 2025 23:20:37 +0000

I didn't find anything about this in NEWS, so I'm assuming this change
in behavior isn't intended.  And I HOPE it's not intended.

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.

Reversion should restore the state of the saved file to the buffer,
including whether the file itself is read-only.

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.

In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-23 built on
 AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.26100
System Description: Microsoft Windows 10 Pro (v10.0.2009.26100.3775)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation=aot
 --without-compress-install --with-tree-sitter CFLAGS=-O2
 prefix=/g/rel/install/emacs-30.1'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Drew Adams via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: 78124 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#78124: 30.1; `revert-buffer' regression
Date: Tue, 29 Apr 2025 08:07:47 +0200

Drew Adams via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> I didn't find anything about this in NEWS, so I'm assuming this change
> in behavior isn't intended.  And I HOPE it's not intended.
>
> 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 describes the effect of…

  [NEWS]
  ** New variable 'revert-buffer-restore-functions'.
  It helps to preserve various states after reverting the buffer.

  [files.el]
  (defvar revert-buffer-restore-functions '(revert-buffer-restore-read-only)
    "Functions to preserve any state during `revert-buffer'.
    …")

… if I am not mistaken?

> Reversion should restore the state of the saved file to the buffer,
> including whether the file itself is read-only.
>
> 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.
>
> In GNU Emacs 30.1 (build 2, x86_64-w64-mingw32) of 2025-02-23 built on
>  AVALON
> Windowing system distributor 'Microsoft Corp.', version 10.0.26100
> System Description: Microsoft Windows 10 Pro (v10.0.2009.26100.3775)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 78124 <at> debbugs.gnu.org
Subject: Re: bug#78124: 30.1; `revert-buffer' regression
Date: Tue, 29 Apr 2025 09:22:29 +0300

tags 78124 notabug
thanks

> Date: Mon, 28 Apr 2025 23:20:37 +0000
> From:  Drew Adams via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> I didn't find anything about this in NEWS, so I'm assuming this change
> in behavior isn't intended.  And I HOPE it's not intended.
> 
> 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'.

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

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

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "78124 <at> debbugs.gnu.org" <78124 <at> debbugs.gnu.org>,
 Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Subject: RE: [External] : Re: bug#78124: 30.1; `revert-buffer' regression
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.)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 78124 <at> debbugs.gnu.org, kevin.legouguec <at> gmail.com
Subject: Re: bug#78124: 30.1; `revert-buffer' regression
Date: Tue, 29 Apr 2025 21:29:21 +0300

> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "78124 <at> debbugs.gnu.org" <78124 <at> debbugs.gnu.org>,
>         Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Tue, 29 Apr 2025 16:58:05 +0000
> 
> What's so special about the buffer writability state that it needs
> to be preserved, rather than reflecting the file's writability
> state?

The general agreement was that it is a better default.

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

Thanks, I made these changes.

Previous Next

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