From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#17873: 24.4.50; `desktop-save' Date: Sun, 29 Jun 2014 19:10:24 -0700 (PDT) Message-ID: <7504f7f4-9af6-468a-96bc-f92518f9b85d@default> References: <87ha332qul.fsf@mail.jurta.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1404094292 14296 80.91.229.3 (30 Jun 2014 02:11:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Jun 2014 02:11:32 +0000 (UTC) Cc: 17873@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 30 04:11:24 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X1R3y-0004Ec-TT for geb-bug-gnu-emacs@m.gmane.org; Mon, 30 Jun 2014 04:11:23 +0200 Original-Received: from localhost ([::1]:60162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1R3y-0001ed-DY for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Jun 2014 22:11:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1R3n-0001cz-OQ for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2014 22:11:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X1R3f-0001sG-0M for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2014 22:11:11 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X1R3e-0001sA-SU for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2014 22:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X1R3e-0003PB-Ec for bug-gnu-emacs@gnu.org; Sun, 29 Jun 2014 22:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Jun 2014 02:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17873 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17873-submit@debbugs.gnu.org id=B17873.140409423913045 (code B ref 17873); Mon, 30 Jun 2014 02:11:02 +0000 Original-Received: (at 17873) by debbugs.gnu.org; 30 Jun 2014 02:10:39 +0000 Original-Received: from localhost ([127.0.0.1]:37285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1R3G-0003OK-QX for submit@debbugs.gnu.org; Sun, 29 Jun 2014 22:10:39 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:25633) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X1R3D-0003Nz-3q for 17873@debbugs.gnu.org; Sun, 29 Jun 2014 22:10:35 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5U2AS3c017731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Jun 2014 02:10:29 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5U2AQEH020210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jun 2014 02:10:27 GMT Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s5U2APUv024984; Mon, 30 Jun 2014 02:10:26 GMT In-Reply-To: <87ha332qul.fsf@mail.jurta.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:90992 Archived-At: > > Just say that if the desktop information has not changed since it > > was last saved then the file is not rewritten. >=20 > Is this how you propose to fix the docstring? ... > +If AUTO-SAVE is non-nil, compare the current desktop information > +to that in the desktop file, and if the desktop information has not > +changed since it was last saved then the file is not rewritten." Yes (assuming that is the behavior). But it is slightly better to stick with the active voice for both parts of the last sentence: ...compare... and if the desktop information has not changed since ^^^^^^^ it was last saved then do not rewrite the file. ^^^^^^^^^^^^^^ > > 2. I also have a question about the behavior: Why is writing the > > file even when the content is unchanged the default behavior? Why the > > need to specify AUTO-SAVE instead of an optional SAVE-EVEN-IF-NO-CHANGE= ? > > Is this just for backward compatibility? (Before AUTO-SAVE was > > introduced the behavior was to update the file even if the desktop > > info was not changed.) >=20 > When the user executes `M-x desktop-save RET' explicitly, the desktop > has to be saved unconditionally as expected by users, e.g. it will > update the file timestamp, and do other usual things. I see. That makes sense, I guess. But depending on what the "other usual things" are, I can see that it might be good for this to be optional (e.g. dependent on a user option). IOW, does a user who asks to save a desktop (perhaps just to make sure) necessarily care about the timestamp and those other usual things? I can see that a user might, but I can guess too that s?he might not. Perhaps the option for the case where the content has not changed could have values `always', `never', and `ask-me'. Just a thought. I suppose the desktop file size might play a role in a user's preference. > The only missing thing that `desktop-save' doesn't do yet is creating > a backup copy, but this is currently under discussion in bug#17351. FWIW, I am not following that thread. I trust that those participating in it will DTRT. But I certainly am in favor of a user being able to opt for automatic backups of desktop files (or to opt out). Probably my only concern in this regard is this: If such a feature is implemented then I hope that the backup copy for a given desktop file is related somehow to the name of the file being backed up. (This is the case for Emacs backup files in general, so I expect there won't be a problem in this regard.) I mention this because desktop.el still suffers from an ungainly design wrt desktop files: it more or less assumes there is at most one per directory. Functions such as `desktop-save' and `desktop-read' do not let you pass a file name (e.g. absolute) for the file to be saved/read - they rely on the directory name. To me, that's silly - an unnecessary design limitation (which I have pointed out before, FWIW). I use desktops in the form of desktop bookmarks, for instance, and it is quite common for multiple such bookmarks to reference desktop files located in the same directory. It's OK. I jump through a few minor hoops to get around the single-file-per-directory design/expectation. (I define save and read functions that accept a file name, for instance.) But I would not want desktops to become further cobbled by a similar assumption wrt backup files.