bug#50431: revert-buffer doesn't preserve read-onlyness

bug#50431: revert-buffer doesn't preserve read-onlyness

[Juri Linkov]

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.

bug#50431: revert-buffer doesn't preserve read-onlyness

[Glenn Morris]

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?

bug#50431: revert-buffer doesn't preserve read-onlyness

[Lars Ingebrigtsen]

Glenn Morris <rgm@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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Richard Stallman]

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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Lars Ingebrigtsen]

Richard Stallman <rms@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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Juri Linkov]

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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Lars Ingebrigtsen]

Juri Linkov <juri@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.

bug#50431: revert-buffer doesn't preserve read-onlyness

[Juri Linkov]

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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Lars Ingebrigtsen]

Juri Linkov <juri@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?

bug#50431: revert-buffer doesn't preserve read-onlyness

[Juri Linkov]

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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Eli Zaretskii]

> Cc: 50431@debbugs.gnu.org
> From: Juri Linkov <juri@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.

bug#50431: revert-buffer doesn't preserve read-onlyness

[Juri Linkov]

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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: larsi@gnus.org,  50431@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.

bug#50431: revert-buffer doesn't preserve read-onlyness

[Juri Linkov]

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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Drew Adams]

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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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.

bug#50431: revert-buffer doesn't preserve read-onlyness

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Juri Linkov <juri@linkov.net>,  50431@debbugs.gnu.org
> Date: Fri, 26 Aug 2022 12:41:40 +0200
> 
> Eli Zaretskii <eliz@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.

bug#50431: revert-buffer doesn't preserve read-onlyness

[Drew Adams]

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

bug#50431: revert-buffer doesn't preserve read-onlyness

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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.