all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Drew Adams <drew.adams@oracle.com>
Cc: 22025@debbugs.gnu.org
Subject: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Wed, 2 Dec 2015 12:35:31 +0000	[thread overview]
Message-ID: <20151202123531.GB2318@acm.fritz.box> (raw)
In-Reply-To: <9d7e9acc-9c9f-4a10-afcc-989e16f8e6a5@default>

Hello, Drew.

On Tue, Dec 01, 2015 at 09:46:57AM -0800, Drew Adams wrote:
> > I think (but I don't know for sure) that explicitly invoking
> > `desktop-save' is quite rare

> 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.

Thanks.  I didn't know about this.  As a matter of interest, where is
the source for Bookmark+?

> > "- most desktop files will be saved at Emacs shutdown,

> 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.

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.

> And saving is independent of Emacs shutdown, logically,
> and in reality for desktop bookmarks.

> IMHO, it is a big mistake to assume that desktops are
> used only in the way provided out of the box.  This is
> one example of that.

OK.

> Another example:

> 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.

> 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.

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.

> For example:

> (defun bmkp-desktop-change-dir (desktop-file)
>   "Change to desktop saved in DESKTOP-FILE.
> Kill the desktop as specified by variables `desktop-save-mode' and
>  `desktop-save'.
> Clear the desktop and load DESKTOP-FILE."
>   (interactive (list (read-file-name "Change to desktop file: ")))
>   (unless (file-name-absolute-p desktop-file)
>     (setq desktop-file  (expand-file-name desktop-file)))
>   (let ((desktop-base-file-name (file-name-nondirectory desktop-file))
>         (desktop-dir            (file-name-directory desktop-file))
>         (desktop-restore-eager  t) ; Don't bother with lazy restore.
>         (desktop-globals-to-save
>          (bmkp-remove-if
>            (lambda (elt) (memq elt bmkp-desktop-no-save-vars))
>            desktop-globals-to-save)))
>     (bmkp-desktop-kill)
>     (desktop-clear)
>     (desktop-read desktop-dir)))

> Fiddling to bind `desktop-base-file-name' etc. is silly,
> but necessary because of the desktop.el implementation's
> assumption about desktop files.

> This is the kind of thing that can result from thinking
> things like "explicitly invoking `desktop-save' is quite
> rare".  Don't assume that the originally intended use case
> is the only one.

> This said, I don't have anything particular to say now about
> a change in desktop format or prompting the user (once only)
> about upgrading the format used.  And I haven't looked at the
> proposed change.

> 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.

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 <= 24.5.  There is no nice and easy way to deal with
this.

> HTH. 

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2015-12-02 12:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-27  8:38 bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop Alan Mackenzie
2015-11-27  9:05 ` Eli Zaretskii
2015-11-27  9:47   ` Alan Mackenzie
2015-11-27 10:23     ` Eli Zaretskii
2015-11-27 11:39       ` Alan Mackenzie
2015-11-27 12:27       ` Andy Moreton
2015-12-01 12:19   ` Alan Mackenzie
2015-12-01 15:43     ` Eli Zaretskii
2015-12-01 17:01       ` Alan Mackenzie
2015-12-01 17:46         ` Drew Adams
2015-12-02 12:35           ` Alan Mackenzie [this message]
2015-12-02 14:47             ` Drew Adams
2015-12-01 18:46         ` Eli Zaretskii
2015-12-02 11:27           ` Alan Mackenzie
2015-12-02 13:16             ` Andy Moreton
2015-12-02 13:50             ` Eli Zaretskii
2015-12-03  8:40               ` Alan Mackenzie
2015-12-03 10:30                 ` Eli Zaretskii
2016-01-15 16:18                   ` Alan Mackenzie
2016-01-15 18:31                     ` Eli Zaretskii
2016-01-18 13:37                       ` Alan Mackenzie
     [not found]                 ` <<83mvtrj02w.fsf@gnu.org>
2015-12-03 14:33                   ` Drew Adams
2015-12-03 14:57                     ` Alan Mackenzie
2015-12-03 15:35                       ` Drew Adams
2015-12-03 15:44                         ` Alan Mackenzie
2019-09-29 21:17 ` Stefan Kangas
     [not found] <<20151127083837.GB1782@acm.fritz.box>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151202123531.GB2318@acm.fritz.box \
    --to=acm@muc.de \
    --cc=22025@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.