GNU bug report logs - #5314
23.1; Inconsistent treatment of auto-save files

Previous Next

Full log

View this message in rfc822 format

From: Uday S Reddy <u.s.reddy <at> cs.bham.ac.uk>
To: 5314 <at> debbugs.gnu.org
Subject: bug#5314: Acknowledgement (23.1; Inconsistent treatment of auto-save files)
Date: Tue, 5 Jan 2010 14:29:30 +0000

I did some more testing of the functions after my initial report.  The
situation seems a lot more complex than I had imagined.

With an old auto-save file on the disk, the following sequence done on
a buffer seems to always return nil:

  (progn (insert "x") (recent-auto-save-p))

Killing the buffer in this case does not affect the old auto-save
file.

The following sequence seems to always return t

  (progn (set-buffer-modified-p t) (recent-auto-save-p))

Killing the buffer in this case deletes the old auto-save file.

So, it appears that recent-auto-save-p and kill-buffer are consistent
with each other.  But their behaviour is paradoxical with regard to
set-buffer-modified-p.

Cheers,
Uday

-------

Uday S Reddy writes:

> Hi, I am a maintainer of VM.  In trying to figure out some problems to
> do with auto-save files of VM mail buffers, I discovered that the
> current Emacs treatment of auto-save files is inconsistent.  Functions
> involved are kill-buffer, delete-auto-save-file-if-necessary and
> recent-auto-save-p.
> 
> 1. If there is an old auto-save file, and you visit the file, make
> some changes and kill the buffer without saving, then the old
> auto-save file is silently deleted.  This seems bad, because the very
> reason for killing the buffer without saving might be to compare it
> with the auto-save file.  
> 
> I think the old auto-save files should always be preserved unless the
> user does a recover-file.
> 
> Then there is the question of what kill-buffer should do if there is a
> "recent" auto-save file (as determined by recent-auto-save-p).  It
> would make sense to delete it.
> 
> 2. The inline documentation for delete-auto-save-file-if-necessary
> says "Normally delete only if the file was written by this Emacs since
> the last real save".  This gives one the impression that Emacs is
> keeping track of when the last real save was done, but in reality it
> only seems to be checking the buffer-modified-p status.  If so, a more
> accurate way to word the doc string might be
> 
> "Normally delete only if the file was written by this Emacs and the
> buffer has been modified since the last real save."
> 
> If the buffer-modified-p is nil, then even recent auto-save files seem
> to be left lying around.  This is the opposite problem of that in
> point 1.
> 
> 3. The inline documentation for recent-auto-save-p needs to be
> modified along the same lines as point 2.
> 
> 4. The Elisp manual descriptions for
> delete-auto-save-file-if-necessary and 
> recent-auto-save-p need to be similarly modified.
> 
> 5. It would be useful to mention these issues in the documentation of
> kill-buffer as well.  
> 
> Cheers,
> Uday Reddy
> 
> 
> In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
>  of 2009-07-30 on SOFT-MJASON
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (4.4)'
> 
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: ENU
>   value of $XMODIFIERS: nil
>   locale-coding-system: cp1252
>   default-enable-multibyte-characters: t
> 
> Major mode: Fundamental
> 
> Minor modes in effect:
>   savehist-mode: t
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   menu-bar-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   global-auto-composition-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
> 
> Recent input:
> SPC <return> C-s b u g C-s C-a m <return> <help-echo> 
> <down-mouse-2> <mouse-2> q C-h i u <up> <up> m <return> 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n m n e w SPC 
> SPC SPC SPC SPC 3 SPC <return> <help-echo> <help-echo> 
> <help-echo> <down-mouse-1> <mouse-1> <wheel-up> <wheel-down> 
> <wheel-up> l m l a t SPC SPC <return> u u u m e m SPC 
> <return> SPC m b u g SPC SPC <backspace> <backspace> 
> <backspace> <backspace> <backspace> <backspace> <backspace> 
> <backspace> <backspace> <backspace> g s <return> m 
> u n d e r s t SPC SPC SPC <return> SPC <backspace> 
> p SPC <backspace> SPC n SPC n SPC SPC SPC SPC SPC SPC 
> SPC SPC SPC SPC SPC SPC SPC <backspace> <backspace> 
> <backspace> <backspace> <backspace> <backspace> <backspace> 
> <backspace> <backspace> <backspace> <backspace> <backspace> 
> <backspace> M-x r e p o r t - e m a c s - b u SPC <return> 
> I n c o s <backspace> n s i s t e n t SPC t r e a t 
> m e n t SPC o f SPC a u t o SPC s a v e SPC f i l e 
> s <return> <f1> C-v C-v C-v C-x , C-n C-n C-n C-n C-p 
> C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f 
> C-f <return> C-p C-p C-p C-f C-f C-f C-f C-f C-b C-k 
> u d r C-a C-c C-c y C-n C-n C-k C-k C-c C-c y SPC SPC 
> SPC f SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC SPC 
> SPC M-x v m <return> C-g C-x b * M e SPC <return> <f1> 
> C-x . <help-echo> M-x r e p o r t = e m a <backspace> 
> <backspace> <backspace> <backspace> - e m SPC SPC 
> <return>
> 
> Recent messages:
> Generating summary... 2120
> Generating summary markers... 
> Generating summary... done
> Decoding MIME message...
> Decoding quoted-printable... done
> Decoding MIME message... done
> 2138 messages, 0 new, 605 unread, 0 deleted
> Checking for new mail for d:/Home/udr/mail/imap-cache-d0e95a10f3bde2de73bdc69e586ec456...
> Quit [2 times]
> Mark set
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.