bug#11303: Whitespace mode causes auto-save to malfunction

bug#11303: Whitespace mode causes auto-save to malfunction

[Kelly Dean]

I'm using Emacs on X on Debian 6 Stable. emacs-version says GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian.
Steps to reproduce the bug:
Delete your .emacs file.
Start X, and start Emacs with no options.
Open any writeable file, then press space, so that the buffer is modified.
Wait for the auto-save timeout. Emacs writes the auto-save file.
Press C-g.
Wait for the auto-save timeout again. Notice that Emacs does not write the auto-save file again, because the buffer hasn't changed since the last auto-save. This is the correct behavior.
Now, close Emacs, and put just the following in your .emacs file:
(global-whitespace-mode 1)
Start Emacs with no options.
Open a file, press space, wait for the timeout, press C-g, and wait for the timeout again. Notice that Emacs does write the auto-save file again, even though the buffer hasn't changed since the last auto-save. This is not the correct behavior.
This can cause various problems, for example unnecessarily spinning up a sleeping disk to write the auto-save file, and the timestamp on the auto-save file can't be relied on to show when (approximately, with accuracy determined by the value of auto-save-timeout) the buffer was last modified.

bug#11303: Whitespace mode causes auto-save to malfunction

[Kelly Dean]

This bug is reproducible on 24.1-rc1. (emacs-version reports "GNU Emacs 24.1.1 (i686-pc-linux-gnu, X toolkit, Xaw scroll bars) of 2012-06-01 on localhost")

bug#11303: Whitespace mode causes auto-save to malfunction

[Lars Ingebrigtsen]

Kelly Dean <kellydeanch@yahoo.com> writes:

> Start Emacs with no options.
> Open a file, press space, wait for the timeout, press C-g, and wait
> for the timeout again. Notice that Emacs does write the auto-save file
> again, even though the buffer hasn't changed since the last
> auto-save. This is not the correct behavior.

This problem is still present in Emacs 28.

Poking around a bit at this, it seems that it's the call to

(jit-lock-refontify (point-min) (point-max))

that makes `M-x do-auto-save' auto-save again (even if nothing has
changed except the text properties in the buffer).

I.e., doing

(put-text-property 1 3 'face 'bold)

will make the buffer eligible for auto-saving again, even if putting
those text properties into the buffer doesn't switch from unmodified to
modified.

That's pretty inconsistent behaviour, at least?  I'm guessing this stems
from text properties upping the BUF_MODIFF, but not changing the buffer
modification status.

Does this sound like the correct analysis?  If so, what can we do about
it?  (`with-silent-modifications' doesn't seem to have any effect here.)

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

bug#11303: Whitespace mode causes auto-save to malfunction

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 16 Jul 2021 13:55:44 +0200
> Cc: 11303@debbugs.gnu.org
> 
> Kelly Dean <kellydeanch@yahoo.com> writes:
> 
> > Start Emacs with no options.
> > Open a file, press space, wait for the timeout, press C-g, and wait
> > for the timeout again. Notice that Emacs does write the auto-save file
> > again, even though the buffer hasn't changed since the last
> > auto-save. This is not the correct behavior.
> 
> This problem is still present in Emacs 28.
> 
> Poking around a bit at this, it seems that it's the call to
> 
> (jit-lock-refontify (point-min) (point-max))
> 
> that makes `M-x do-auto-save' auto-save again (even if nothing has
> changed except the text properties in the buffer).
> 
> I.e., doing
> 
> (put-text-property 1 3 'face 'bold)
> 
> will make the buffer eligible for auto-saving again, even if putting
> those text properties into the buffer doesn't switch from unmodified to
> modified.
> 
> That's pretty inconsistent behaviour, at least?  I'm guessing this stems
> from text properties upping the BUF_MODIFF, but not changing the buffer
> modification status.
> 
> Does this sound like the correct analysis?  If so, what can we do about
> it?  (`with-silent-modifications' doesn't seem to have any effect here.)

The OP's recipe includes C-g, which could mean we lack an
unwind-protect somewhere, and the buffer stays modified due to changes
in faces.

The fact that changes in faces cause the buffer become eligible for
auto-saving is not a bug, IMO, it's a feature.

bug#11303: Whitespace mode causes auto-save to malfunction

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The OP's recipe includes C-g, which could mean we lack an
> unwind-protect somewhere, and the buffer stays modified due to changes
> in faces.

The C-g isn't necessary to reproduce the issue.

> The fact that changes in faces cause the buffer become eligible for
> auto-saving is not a bug, IMO, it's a feature.

It's pretty annoying when using whitespace-mode -- which changes the
text properties all the time when you move around in the buffer (without
modifying the buffer).  It's not really that much of an issue elsewhere,
where font lock changes usually only happen when you actually edit the
buffer.

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

bug#11303: Whitespace mode causes auto-save to malfunction

[Lars Ingebrigtsen]

Kelly Dean <kellydeanch@yahoo.com> writes:

> Notice that Emacs does write the auto-save file
> again, even though the buffer hasn't changed since the last
> auto-save. This is not the correct behavior.

I've now fixed this in Emacs 29.  The problem wasn't limited to
whitespace mode, but all modes that do font locking.

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