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#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop. Date: Wed, 2 Dec 2015 06:47:30 -0800 (PST) Message-ID: <5d12c795-e0d0-4f53-bc4d-b5162026dcb0@default> References: <20151127083837.GB1782@acm.fritz.box> <83r3jbstgq.fsf@gnu.org> <20151201121940.GA2611@acm.fritz.box> <83a8pukwdq.fsf@gnu.org> <20151201170138.GB2611@acm.fritz.box> <9d7e9acc-9c9f-4a10-afcc-989e16f8e6a5@default> <20151202123531.GB2318@acm.fritz.box> 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 1449067706 3549 80.91.229.3 (2 Dec 2015 14:48:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Dec 2015 14:48:26 +0000 (UTC) Cc: 22025@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 02 15:48:14 2015 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 1a48hZ-0002DM-BA for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Dec 2015 15:48:13 +0100 Original-Received: from localhost ([::1]:58605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a48hY-0002px-3X for geb-bug-gnu-emacs@m.gmane.org; Wed, 02 Dec 2015 09:48:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a48hT-0002pc-50 for bug-gnu-emacs@gnu.org; Wed, 02 Dec 2015 09:48:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a48hO-0007aq-VQ for bug-gnu-emacs@gnu.org; Wed, 02 Dec 2015 09:48:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a48hO-0007am-SA for bug-gnu-emacs@gnu.org; Wed, 02 Dec 2015 09:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a48hO-0004tV-HX for bug-gnu-emacs@gnu.org; Wed, 02 Dec 2015 09:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Dec 2015 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22025 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22025-submit@debbugs.gnu.org id=B22025.144906765818780 (code B ref 22025); Wed, 02 Dec 2015 14:48:02 +0000 Original-Received: (at 22025) by debbugs.gnu.org; 2 Dec 2015 14:47:38 +0000 Original-Received: from localhost ([127.0.0.1]:35893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a48gz-0004sp-4m for submit@debbugs.gnu.org; Wed, 02 Dec 2015 09:47:37 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43006) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a48gw-0004sg-FC for 22025@debbugs.gnu.org; Wed, 02 Dec 2015 09:47:35 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB2ElWbi005199 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Dec 2015 14:47:33 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tB2ElWNd031000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2015 14:47:32 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tB2ElVa3015946; Wed, 2 Dec 2015 14:47:32 GMT In-Reply-To: <20151202123531.GB2318@acm.fritz.box> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] 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: 208.118.235.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:109531 Archived-At: > > > I think (but I don't know for sure) that explicitly invoking > > > `desktop-save' is quite rare >=20 > > I and other Bookmark+ users use it all the time. We create > > desktops as bookmarks, and switch among them - any number > > of them - by "jumping" to them. >=20 > Thanks. I didn't know about this. As a matter of interest, > where is the source for Bookmark+? You can get it from MELPA or Emacs Wiki. I upload to the wiki, and it is pulled from there to MELPA (daily). The description page (with info about obtaining the files etc.) is here: http://www.emacswiki.org/emacs/BookmarkPlus Obtaining the files: http://www.emacswiki.org/emacs/BookmarkPlus#toc3 > > > "- most desktop files will be saved at Emacs shutdown, >=20 > > Are you sure? My guess is that most users who only do > > that content themselves with a single desktop file, or > > perhaps 2 or 3. Users of desktop bookmarks might have > > dozens of them. >=20 > I have just a single desktop file. The idea of having lots of them, and > switching between them is a new one to me. A big problem with the > desktop idea is that of gradually accumulating files which must be > explicitly closed at some point. I'm guessing that with lots of smaller > desktop files, you can just delete an entire desktop when you've finished > using it. I don't follow you, about closing. I don't think that having more or fewer files should have a consequence wrt deleting. And I'm not sure what you mean by being "finished using it". Desktop files are, well, files, so they are persistent (just like bookmark files). Whether you have only one or a hundred shouldn't make any difference wrt when you might be finished with it. If you don't use a file anymore (any file), you can toss it. Sorry, but I really haven't grasped what you mean here. FWIW, the Bookmark+ command that saves the current desktop as a bookmark is `bmkp-set-desktop-bookmark'. And the command that jumps to a desktop bookmark (i.e., switches to its desktop) is `bmkp-jump-desktop'. That uses function `bmkd-desktop-change-dir' to do the switch, and that is accomplished by killing the current desktop and reading the desktop file being switched to. Killing a desktop means (1) saving it, if appropriate and (2) releasing the lock. (defun bmkp-desktop-change-dir (desktop-file) ... (bmkp-desktop-kill) ; derived from `desktop-kill' (desktop-clear) (desktop-read desktop-dir)) (Again, the code needs to convert arg DESKTOP-FILE to DESKTOP-DIR, because of the way desktop.el is written.) > > Another example: >=20 > > It is an unfortunate mistake that desktop.el is written in > > such a way that it hard-codes an assumption that there is > > only one desktop file per directory. The code uses a > > desktop directory (argument or global var) everywhere, > > instead of a desktop file argument. Yet the directory is > > used only to find the file. >=20 > > The basic functions, such as `desktop-change-dir' and > > `desktop-read', assume this, so they don't take a > > DESKTOP-FILE as an optional arg. I needed to write simple > > wrapper functions for them, to let users have multiple > > desktop files in the same directory. There is no reason > > why a desktop file must be associated with a directory - > > users should be able to store the files anywhere. >=20 > Here, I begin to get a little sceptical. How will being able to store > desktop files "anywhere" actually be useful? It seems to me that the > typical desktop file of many will, in fact, be associated with a > particular directory, the directory where work is actually being done for > some particular topic. Being able to store it "anywhere" would add > complexity to desktop.el, and I don't think that extra complexity has > yet been justified. You are maybe thinking "typical" only in the sense of a user who has only one desktop file, or maybe a couple. In such a case, yes, maybe s?he has one for a given directory. But a desktop is a configuration that records lots of stuff. There is no reason that you shouldn't want to have multiple such configurations, and no reason that the configuration files should be in different directories. Where you store your desktop files is irrelevant (though the desktop.el code does not particularly facilitate this). There is no necessary connection between (1) desktop bookmarks and (2) the fact that a desktop, being a configuration of lots of stuff, is in general not related so some particular directory. It just happens that Bookmark+, unlike the vanilla case, makes it easy to switch among desktops, so the implicit fact that desktop configs could be stored anywhere is freed up. A bookmark doesn't care where a target desktop file is located - the file name stored is absolute. "The directory where work is actually being done for some particular topic" means what? Don't you use more than one directory when you work on a "topic"? Don't you move around? And even if you don't, the state of Emacs - which files you have open, in which windows/frames, what the values of given variables are, etc. changes. And you might want to record and later restore some of those states, no? IOW, even if they are in the same directory, the states are different, and what you were doing at different times is different. A desktop records window/frame configs, a set of variables, buffers, files,... - lots of stuff. Think of it as a particular _view_ of a particular state of Emacs. It doesn't matter whether your favorite views each concern a different directory or some of them concern the same directory. They are just snapshots of an Emacs session interaction (desktop) state. The idea that a desktop file is used (or is usable) only to record the _last_ state of Emacs (vars, buffers, frames, etc.) for your last Emacs session is a narrow one. Forget about Emacs a second. Have you not used desktops provided by your window manager? Even if you have used them only for different directories (one desktop per dir), surely you did not have only one desktop and use it only to record the config of the last session, before you logged out. > > FWIW, bookmark.el handles evolution of the bookmark-file > > format across 3 versions in a way that is transparent to > > users. Dunno whether the format change for desktop files is > > similar, but if it is, you might want to take a look at how > > bookmark.el handles it. Search bookmark.el for "IMPORTANT > > NOTICE" to see a description of the changes and how they are > > dealt with. >=20 > In the new desktop format, the central function `desktop-create' now has > an extra argument. Since `desktop-create' is written to the desktop > file as a function call, it has too many arguments for the old version of > desktop.el in Emacs <=3D 24.5. There is no nice and easy way to deal wit= h > this. OK. Now I guess I'll have to look at desktop.el, to see whether the changes break desktop bookmarking, and if so, adapt. ;-)