GNU bug report logs - #50431
revert-buffer doesn't preserve read-onlyness

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50431 in the body.
You can then email your comments to 50431 AT debbugs.gnu.org in the normal way.

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

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

From: Juri Linkov <juri <at> linkov.net>
To: bug-gnu-emacs <at> gnu.org
Subject: revert-buffer doesn't preserve read-onlyness
Date: Mon, 06 Sep 2021 18:03:09 +0300

I don't know at what moment this regression occurred,
but now M-x revert-buffer in a read-only file buffer
doesn't keep it read-only.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Mon, 06 Sep 2021 12:38:30 -0400

Juri Linkov wrote:

> I don't know at what moment this regression occurred,
> but now M-x revert-buffer in a read-only file buffer
> doesn't keep it read-only.

For me, it reverts it to whatever the permission bits on the file say.
Which is IMO the correct behaviour for revert-buffer.
Perhaps you are referring to a short-lived change from
https://debbugs.gnu.org/35166#24
which was quickly reverted?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 50431 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Tue, 07 Sep 2021 17:52:19 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> Juri Linkov wrote:
>
>> I don't know at what moment this regression occurred,
>> but now M-x revert-buffer in a read-only file buffer
>> doesn't keep it read-only.
>
> For me, it reverts it to whatever the permission bits on the file say.
> Which is IMO the correct behaviour for revert-buffer.

Yup. 

> Perhaps you are referring to a short-lived change from
> https://debbugs.gnu.org/35166#24
> which was quickly reverted?

Making revert-buffer preserve user-initiated readedness changes isn't
trivial.  We'd need to record whether the buffer is read-only because it
was read from a read-only file (and vice versa), and then use that data
point in revert-buffer (to see whether we should respect the current
readedness state or not).

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

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

From: Richard Stallman <rms <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rgm <at> gnu.org, 50431 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Wed, 08 Sep 2021 23:07:35 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Making revert-buffer preserve user-initiated readedness changes isn't
  > trivial.  We'd need to record whether the buffer is read-only because it
  > was read from a read-only file (and vice versa), and then use that data
  > point in revert-buffer (to see whether we should respect the current
  > readedness state or not).

How about just this: keep buffer-read-only unchanged?

If it differs from the file's permissions, almost certainly
the user changed it and will beglad of revert-buffer preserves it.

The other case is that the file permissions have been changed
since visiting the file.  But users won't be shocked if
revert-buffer fails to change buffer-read-only in that case,
and they will know what to do.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: rgm <at> gnu.org, 50431 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Thu, 09 Sep 2021 15:16:10 +0200

Richard Stallman <rms <at> gnu.org> writes:

> How about just this: keep buffer-read-only unchanged?
>
> If it differs from the file's permissions, almost certainly
> the user changed it and will beglad of revert-buffer preserves it.

Yes, but that's my point -- we need to store the file's permissions
somewhere so that we can see whether buffer-read-only was set/unset
because of that or not.  (Since the file's permissions may change
afterwards.)

> The other case is that the file permissions have been changed
> since visiting the file.  But users won't be shocked if
> revert-buffer fails to change buffer-read-only in that case,
> and they will know what to do.

No, people have work flows that depend on revert-buffer updating the
readedness based on the file's readedness, and this would disrupt that.
And there's no need to.  We just have to do a small bit of programming.  :-)

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

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

From: Juri Linkov <juri <at> linkov.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Thu, 09 Sep 2021 20:27:03 +0300

>> I don't know at what moment this regression occurred,
>> but now M-x revert-buffer in a read-only file buffer
>> doesn't keep it read-only.
>
> For me, it reverts it to whatever the permission bits on the file say.
> Which is IMO the correct behaviour for revert-buffer.
> Perhaps you are referring to a short-lived change from
> https://debbugs.gnu.org/35166#24
> which was quickly reverted?

Here is what I tried in Emacs versions 26.3 and 28.0.50:

1. 'C-h C-t' that visits etc/TODO in read-only view-mode
2. 'M-x revert-buffer RET yes RET'

In 26.3 there is no view-mode, but still there is a read-only indicator.
In 28.0.50 no view-mode, no read-only indicator.

3. 'C-x C-q' to enable read-only
4. again 'M-x revert-buffer RET yes RET'

In 26.3 the buffer is still read-only.
In 28.0.50 no read-only indicator.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Wed, 24 Aug 2022 13:35:06 +0200

Juri Linkov <juri <at> linkov.net> writes:

> I don't know at what moment this regression occurred,
> but now M-x revert-buffer in a read-only file buffer
> doesn't keep it read-only.

I've now fixed this in Emacs 29 -- `C-x C-q' records what the user
actually did, so we can restore that state.

If the user hasn't used that command, then reverting works as before --
it uses the permission bits on the file and updates the readedness
state.

I considered only heeding the user-set readedness state if it was
different from the default one -- that is, if the user used the `C-x
C-q' command twice, then readedness state would not be preserved by
reverting, but I think that's too subtle.

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Wed, 24 Aug 2022 20:12:50 +0300

>> I don't know at what moment this regression occurred,
>> but now M-x revert-buffer in a read-only file buffer
>> doesn't keep it read-only.
>
> I've now fixed this in Emacs 29 -- `C-x C-q' records what the user
> actually did, so we can restore that state.
>
> If the user hasn't used that command, then reverting works as before --
> it uses the permission bits on the file and updates the readedness
> state.
>
> I considered only heeding the user-set readedness state if it was
> different from the default one -- that is, if the user used the `C-x
> C-q' command twice, then readedness state would not be preserved by
> reverting, but I think that's too subtle.

I confirm that now the read-only status is restored,
but reverting loses view-mode:

  C-h C-t  -- note "View" on the mode-line;
  C-x x g  -- "View" is lost.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Thu, 25 Aug 2022 16:03:54 +0200

Juri Linkov <juri <at> linkov.net> writes:

> I confirm that now the read-only status is restored,
> but reverting loses view-mode:
>
>   C-h C-t  -- note "View" on the mode-line;
>   C-x x g  -- "View" is lost.

Hm, yes.  Reverting a buffer disables all the minor modes?

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Thu, 25 Aug 2022 21:02:00 +0300

>> I confirm that now the read-only status is restored,
>> but reverting loses view-mode:
>>
>>   C-h C-t  -- note "View" on the mode-line;
>>   C-x x g  -- "View" is lost.
>
> Hm, yes.  Reverting a buffer disables all the minor modes?

Maybe minor modes should be restored after reverting?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Thu, 25 Aug 2022 21:55:29 +0300

> Cc: 50431 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 25 Aug 2022 21:02:00 +0300
> 
> >> I confirm that now the read-only status is restored,
> >> but reverting loses view-mode:
> >>
> >>   C-h C-t  -- note "View" on the mode-line;
> >>   C-x x g  -- "View" is lost.
> >
> > Hm, yes.  Reverting a buffer disables all the minor modes?
> 
> Maybe minor modes should be restored after reverting?

Only the minor modes that are automatically turned on when visiting
the file.  Reverting should produce the same effect as killing the
buffer and then visiting the file anew, nothing more, nothing less.

For that reason, I'm not sure the change that preserves the read-only
status across reverts is correct.  At the very least, it should be an
opt-in feature, IMO.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Thu, 25 Aug 2022 22:35:31 +0300

>> >> but reverting loses view-mode:
>> >>
>> >>   C-h C-t  -- note "View" on the mode-line;
>> >>   C-x x g  -- "View" is lost.
>> >
>> > Hm, yes.  Reverting a buffer disables all the minor modes?
>>
>> Maybe minor modes should be restored after reverting?
>
> Only the minor modes that are automatically turned on when visiting
> the file.  Reverting should produce the same effect as killing the
> buffer and then visiting the file anew, nothing more, nothing less.

In the above example, `C-h C-t' `C-x x g' doesn't preserve the same state
as visiting the file anew with `C-h C-t'.

> For that reason, I'm not sure the change that preserves the read-only
> status across reverts is correct.  At the very least, it should be an
> opt-in feature, IMO.

It was a regression when reverting stopped to preserve the read-only status
that worked in older versions.  OTOH, in older versions reverting didn't
preserve the minor modes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: larsi <at> gnus.org, 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Fri, 26 Aug 2022 08:34:09 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: larsi <at> gnus.org,  50431 <at> debbugs.gnu.org
> Date: Thu, 25 Aug 2022 22:35:31 +0300
> 
> >> Maybe minor modes should be restored after reverting?
> >
> > Only the minor modes that are automatically turned on when visiting
> > the file.  Reverting should produce the same effect as killing the
> > buffer and then visiting the file anew, nothing more, nothing less.
> 
> In the above example, `C-h C-t' `C-x x g' doesn't preserve the same state
> as visiting the file anew with `C-h C-t'.
> 
> > For that reason, I'm not sure the change that preserves the read-only
> > status across reverts is correct.  At the very least, it should be an
> > opt-in feature, IMO.
> 
> It was a regression when reverting stopped to preserve the read-only status
> that worked in older versions.

IMO, that was a mistake.  It violates the notion of "reverting", at
least in my book.

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

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 50431 <at> debbugs.gnu.org
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Fri, 26 Aug 2022 10:17:24 +0300

>> >> Maybe minor modes should be restored after reverting?
>> >
>> > Only the minor modes that are automatically turned on when visiting
>> > the file.  Reverting should produce the same effect as killing the
>> > buffer and then visiting the file anew, nothing more, nothing less.
>>
>> In the above example, `C-h C-t' `C-x x g' doesn't preserve the same state
>> as visiting the file anew with `C-h C-t'.
>>
>> > For that reason, I'm not sure the change that preserves the read-only
>> > status across reverts is correct.  At the very least, it should be an
>> > opt-in feature, IMO.
>>
>> It was a regression when reverting stopped to preserve the read-only status
>> that worked in older versions.
>
> IMO, that was a mistake.  It violates the notion of "reverting", at
> least in my book.

Maybe a new user option could define how to revert, with possible values:

1. keep the initial read-only status and minor modes;
2. keep the current read-only status and minor modes.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50431 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Fri, 26 Aug 2022 12:41:40 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > Hm, yes.  Reverting a buffer disables all the minor modes?
>> 
>> Maybe minor modes should be restored after reverting?

I'm not sure how useful that'd be in general.  view-mode is slightly
special here because people use that selectively with the intent of "I'm
not really editing this one file", though.

> Only the minor modes that are automatically turned on when visiting
> the file.  Reverting should produce the same effect as killing the
> buffer and then visiting the file anew, nothing more, nothing less.
>
> For that reason, I'm not sure the change that preserves the read-only
> status across reverts is correct.  At the very least, it should be an
> opt-in feature, IMO.

If a user has made an explicit readedness choice for a buffer, then
preserving that over a revert is probably what they want.  (Especially
with auto-reverting.)  But if we get complaints, we can add a user
option.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 50431 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Fri, 26 Aug 2022 13:48:23 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Juri Linkov <juri <at> linkov.net>,  50431 <at> debbugs.gnu.org
> Date: Fri, 26 Aug 2022 12:41:40 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > For that reason, I'm not sure the change that preserves the read-only
> > status across reverts is correct.  At the very least, it should be an
> > opt-in feature, IMO.
> 
> If a user has made an explicit readedness choice for a buffer, then
> preserving that over a revert is probably what they want.

Or not.  It could be an accident as well.

"Reverting" has a specific meaning: re-read the file from disk as if
it were visited anew.  If the user wants to make additional
adjustments, they will need to readjust.  I don't see why the
read-only status should be exempt from this logic.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Juri Linkov <juri <at> linkov.net>
Cc: "larsi <at> gnus.org" <larsi <at> gnus.org>,
 "50431 <at> debbugs.gnu.org" <50431 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#50431: revert-buffer doesn't preserve
 read-onlyness
Date: Fri, 26 Aug 2022 16:10:02 +0000

> > >> Maybe minor modes should be restored after reverting?
> > >
> > It was a regression when reverting stopped to preserve
> > the read-only status that worked in older versions.
> 
> IMO, that was a mistake.  It violates the notion of
> "reverting", at least in my book.

Yes, there can be different notions of reverting.

In the file-visiting case, it generally means and
should mean, IMO) respecting the current state of
the file on disk.  That might not be the last
state of an unmodified buffer visiting the file.

Nor non-file buffers it can mean different things
depending on the mode or whatever.  It's really
whatever state/behavior `revert-buffer-function'
defines.

Dunno whether we have, or should have, guidelines
for what kinds of behavior generally make sense
(or generally don't make sense) for
`revert-buffer-function'.

I certainly wouldn't expect, by default, a
file-visiting buffer to have all previously
enabled minor modes turned on, etc.  And I
wouldn't expect a buffer visiting a file whose
disk read-only status has been changed to revert
to the last read-only status of the buffer.

Reversion involves substituting some state for
the current one.  Sometimes the new state is in
some sense a restoration of a previous state
(in Emacs).  But clearly that's not the case for
revisiting a file whose state on disk has been
changed - whether content, read-only status, or
whatever.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "50431 <at> debbugs.gnu.org" <50431 <at> debbugs.gnu.org>,
 "juri <at> linkov.net" <juri <at> linkov.net>
Subject: RE: [External] : bug#50431: revert-buffer doesn't preserve
 read-onlyness
Date: Fri, 26 Aug 2022 16:24:02 +0000

> "Reverting" has a specific meaning: re-read the file from disk as if
> it were visited anew.  If the user wants to make additional
> adjustments, they will need to readjust.  I don't see why the
> read-only status should be exempt from this logic.

+1.
___

Consider Dired, which, by visiting a directory
is somewhat like visiting a file.  Dired's `g'
reverts the buffer, but that doesn't revert
all of the Dired state (markings, sort order,
hidden files, etc.).  `C-x C-v', on the other
hand, does "restore" to both revisit the file
system and restore Dired default (user) settings.

Both `g' and `C-x C-v' are useful in Dired.
Which is just another way of saying that there
can be multiple ways/kinds of "reverting".

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 50431 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#50431: revert-buffer doesn't preserve read-onlyness
Date: Sat, 27 Aug 2022 15:15:47 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Or not.  It could be an accident as well.

Anything is possible, but what's likely?

> "Reverting" has a specific meaning: re-read the file from disk as if
> it were visited anew.  If the user wants to make additional
> adjustments, they will need to readjust.  I don't see why the
> read-only status should be exempt from this logic.

Just because it's something that people do use, explicitly, to control
the buffer.  That's not the case with, say, minor modes, where people
usually switch then on from hooks or globally.

Previous Next

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