[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11303: Whitespace mode causes auto-save to malfunction
From: |
Eli Zaretskii |
Subject: |
bug#11303: Whitespace mode causes auto-save to malfunction |
Date: |
Fri, 16 Jul 2021 15:00:56 +0300 |
> 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.