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