[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5314: Acknowledgement (23.1; Inconsistent treatment of auto-save fil

From: Stefan Monnier
Subject: bug#5314: Acknowledgement (23.1; Inconsistent treatment of auto-save files)
Date: Wed, 06 Jan 2010 11:08:43 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

> The following sequence seems to always return t
>   (progn (set-buffer-modified-p t) (recent-auto-save-p))

Yes, that's a problem.  Thanks for tracking it down.  I'm looking at the
corresponding code and see from where the problem comes.

I should have a patch for it shortly.  It's kind of a delicate issue
because both the buffer-modified-p data as well as the
recent-auto-save-p data are kept implicitly, basically by checking
timestamps corresponding to the last (auto)save.  That means that
set-buffer-modified-p has to fiddle with those timestamps and lie about
"when" the save took place.  And since there are several such timestamps
involved, a lie at one place can result in odd behaviors elsewhere, as
you're seeing.

> VM's quit routine had the following series of operations:

>       (set-buffer-modified-p nil)
>       (delete-auto-save-file-if-necessary)
>       (kill-buffer (current-buffer)))

> This might have worked in some old version of Emacs.  But, at present,
> the delete-..-if-necessary doesn't do anything because the buffer has
> been set to be unmodified.  (This is reasonable behaviour for the
> delete-..-if-necessary function, but it doesn't follow from the
> documented description of it.)

Indeed delete-auto-save-file-if-necessary claims that it only deletes it
"if the file was written by this Emacs since the last real save", but in
reality (set-buffer-modified-p nil) is mistaken for a "real save"
(because it internally works by setting the "last save timestamp").

A real good fix to make it work reliably and obey the doc may take time.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]