From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stuart D. Herring" Newsgroups: gmane.emacs.devel Subject: Re: A few questions about desktop.el Date: Thu, 4 May 2006 09:27:10 -0700 (PDT) Message-ID: <36957.128.165.123.132.1146760030.squirrel@webmail.lanl.gov> References: <58643.128.165.123.132.1146179153.squirrel@webmail.lanl.gov> <877j55gb6p.fsf@jurta.org> <4458C031.5060201@soem.dk> Reply-To: herring@lanl.gov NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1146760067 19013 80.91.229.2 (4 May 2006 16:27:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 May 2006 16:27:47 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 04 18:27:43 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fbgfp-0001Wv-CV for ged-emacs-devel@m.gmane.org; Thu, 04 May 2006 18:27:29 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fbgfo-0000eH-Pb for ged-emacs-devel@m.gmane.org; Thu, 04 May 2006 12:27:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fbgfd-0000dA-5r for emacs-devel@gnu.org; Thu, 04 May 2006 12:27:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fbgfc-0000cB-Cu for emacs-devel@gnu.org; Thu, 04 May 2006 12:27:16 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fbgfc-0000c8-3k for emacs-devel@gnu.org; Thu, 04 May 2006 12:27:16 -0400 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FbggF-0003Sm-KU for emacs-devel@gnu.org; Thu, 04 May 2006 12:27:55 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailwasher-b.lanl.gov (8.12.11.20060308/8.12.11/(ccn-5)) with ESMTP id k44GRCp6005882 for ; Thu, 4 May 2006 10:27:12 -0600 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay1.lanl.gov (8.12.11.20060308/8.12.11/(ccn-5)) with ESMTP id k44GRBhp005977; Thu, 4 May 2006 10:27:11 -0600 Original-Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11.20060308/8.12.11) with ESMTP id k44GRBwO009226; Thu, 4 May 2006 10:27:11 -0600 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id k44GRALX009224; Thu, 4 May 2006 09:27:10 -0700 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to herring@lanl.gov using -f Original-Received: from 128.165.123.132 (SquirrelMail authenticated user 196434); by webmail.lanl.gov with HTTP; Thu, 4 May 2006 09:27:10 -0700 (PDT) In-Reply-To: <4458C031.5060201@soem.dk> Original-To: "Lars Hansen" User-Agent: SquirrelMail/1.4.3a-11.EL3 X-Mailer: SquirrelMail/1.4.3a-11.EL3 X-Priority: 3 (Normal) Importance: Normal X-PMX-Version: 4.7.1.128075 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53917 Archived-At: > I like the idea of using the standard locking mechanism, but I don't > like to mark an unmodified buffer as modified. > > I think the desktop file should be locked as soon as we know it is going > to be changed when Emacs exits, i.e. when desktop-save-mode is turned > on. And if desktop-save-mode is turned off, the desktop file should be > unlocked if its buffer is unmodified. So maybe lock-buffer should have > an optional parameter LOCK-UNMODIFIED to make it usable in such cases (I > take it this is an after-the-release discussion.) So what happens if you turn desktop-save-mode off, another Emacs loads, locks, overwrites, and unlocks the file, and then you turn desktop-save-mode back on? (The desktop file's buffer (if it is made to have one) will always be unmodified unless the user explicitly finds it and changes it; desktop does not use a buffer as some sort of "scratch pad" whose state of modification would reflect the state of the abstract desktop.) Besides, someone could have a "standard desktop" that they load frequently but save rarely, and so never have desktop-save-mode turned on. Then they might occasionally improve on or update the standard, and issue an explicit (desktop-save) which would take place without the protections of file locking. In short, I don't think it's reasonable to "know it is going to be changed when Emacs exits", because settings can change and it might even get changed before Emacs exits (due to `desktop-save' or even `desktop-change-dir'). >> [timestamp check suggestion] > > This is pleasingly simple, but then the question would be asked when > Emacs is exited rather than when it is started. IMHO, the question > should be asked as soon as the problem is detected, i.e. when the second > Emacs is started (if desktop-save-mode is turned on). My patch does this (as I mentioned in my reply to Juri); it also does what you ask, although without the standard file-lock mechanism. A separate lock file is maintained which identifies (by PID) the owner of the desktop file. Then the second Emacs will see the file and complain about it (regardless of the setting of `desktop-save-mode', for the reasons of no-precognition mentioned above), although the user is allowed the option of proceeding anyway (at which point it's up to the modification dates to attempt a peaceful resolution later). I encourage the testing of my patch to see if its behavior is close enough to everyone's idea of safe, correct, vigilant, and intuitive. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.