From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.bugs Subject: bug#5314: 23.1; Inconsistent treatment of auto-save files Date: Wed, 6 Jan 2010 02:14:37 +0000 Message-ID: <19267.61965.375000.846636@gargle.gargle.HOWL> References: <84skalg9e3.fsf@cs.bham.ac.uk> Reply-To: Uday S Reddy , 5314@debbugs.gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1262757515 26345 80.91.229.12 (6 Jan 2010 05:58:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jan 2010 05:58:35 +0000 (UTC) Cc: Uday S Reddy , 5314@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 06 06:58:27 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NSOuY-00055u-Bw for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jan 2010 06:58:26 +0100 Original-Received: from localhost ([127.0.0.1]:49086 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSOuY-0007ut-Oe for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Jan 2010 00:58:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSLU2-0003jm-Sg for bug-gnu-emacs@gnu.org; Tue, 05 Jan 2010 21:18:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSLTy-0003dx-LH for bug-gnu-emacs@gnu.org; Tue, 05 Jan 2010 21:18:50 -0500 Original-Received: from [199.232.76.173] (port=57983 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSLTy-0003de-DY for bug-gnu-emacs@gnu.org; Tue, 05 Jan 2010 21:18:46 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36178) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSLTy-0005kc-5L for bug-gnu-emacs@gnu.org; Tue, 05 Jan 2010 21:18:46 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NSLQM-0004SD-Cd; Tue, 05 Jan 2010 21:15:02 -0500 X-Loop: bug-gnu-emacs@gnu.org Mail-Followup-To: Uday S Reddy , 5314@debbugs.gnu.org Resent-From: Uday S Reddy Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jan 2010 02:15:02 +0000 Resent-Message-ID: Resent-Sender: bug-gnu-emacs@gnu.org X-Emacs-PR-Message: followup 5314 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 5314-submit@debbugs.gnu.org id=B5314.126274409317099 (code B ref 5314); Wed, 06 Jan 2010 02:15:02 +0000 Original-Received: (at 5314) by debbugs.gnu.org; 6 Jan 2010 02:14:53 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NSLQC-0004Rk-Mk for submit@debbugs.gnu.org; Tue, 05 Jan 2010 21:14:52 -0500 Original-Received: from sun60.bham.ac.uk ([147.188.128.137]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NSLQA-0004Rd-8I for 5314@debbugs.gnu.org; Tue, 05 Jan 2010 21:14:51 -0500 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1NSLQ5-0004mA-PV; Wed, 06 Jan 2010 02:14:45 +0000 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1NSLQ5-0001OR-Fc; Wed, 06 Jan 2010 02:14:45 +0000 Original-Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1NSLQ5-0003YS-KW; Wed, 06 Jan 2010 02:14:45 +0000 In-Reply-To: X-Mailer: VM 8.1.0-beta under 22.3.1 (i386-mingw-nt5.1.2600) X-Spam-Score: -3.6 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list X-Spam-Score: -3.4 (---) Resent-Date: Tue, 05 Jan 2010 21:15:02 -0500 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-Mailman-Approved-At: Wed, 06 Jan 2010 00:58:21 -0500 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:33987 Archived-At: Stefan Monnier writes: > [ Always glad to see people from my field participate in Emacs > development. ] Same here! I didn't realize it was you. Nice to know! > Could you try and provide a more precise recipe? I sent a follow-up today with more specific info, but perhaps it didn't reach you. Here it is again: ----- 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. ---- VM, being a mail client, doesn't allow typing into buffers. (set-buffer-modified-p t) is the main way of recording that changes have been made. 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.) I tried switching the order of the first two operations. Then I discovered that non-recent auto-save files were getting deleted as well. If Emacs knows enough to keep track of which auto-save files were written by "this Emacs" (as indicated in the documentation of delete-...-if-necessary), then I think it should always delete those auto-save files and nothing else. In that case, both the orders of the VM's quit routine would work fine. At the moment, neither one does! > Or maybe the old auto-save file was overwritten by a new auto-save file > before you killed the buffer? It does sound like a likely reason. > And indeed it's a problem, tho I'm not sure how to best fix it: > - We could try and rename the old auto-save file before saving the new one > and let recover-file choose among the various possible auto-save files. > - Maybe make it harder for the user to start modifying the buffer when > there's an old auto-save file (e.g. make the buffer read-only and > warn/prompt when the user tries to C-x C-q). > - Prompt just before saving the new auto-save file so the user > gets a chance to prevent the old auto-save from being overwritten. > - Disable auto-saving when there's an old auto-save file (together with > an appropriate warning, in the same way as we disable auto-saving when > the file/buffer got much smaller). VM uses the second solution. For Emacs, the last solution would be the best. In fact, I always assumed that Emacs was using the last solution. > > 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. > > I cannot reproduce this either. Do you have a recipe? Visit a file, type some stuff, run do-auto-save, eval (set-buffer-modified-p nil) and then kill the buffer. The auto-save file would still be there. > > 4. The Elisp manual descriptions for > > delete-auto-save-file-if-necessary and > > recent-auto-save-p need to be similarly modified. > > Just to be sure: do you want to change the doc because you don't like > the behavior it describes, or because it doesn't match the behavior > you see? > > We clearly would rather fix the code to match the doc if the doc > describes the behavior we want. If you can change the code to match the doc, that would be perfect. That would mean that the "this Emacs" idea has to be taken seriously. No guess work. If two concurrent Emacs sessions are editing the same file and end up over-writing each other's auto-save files, then each Emacs session should only delete the version of the auto-save file it created! It is a bit ambitious, but doable. Cheers, Uday