GNU bug report logs - #22025
Emacs 25 corrupts Emacs 24 .emacs.desktop.

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Fri, 27 Nov 2015 08:37:02 UTC

Severity: wishlist

Fixed in version 25.1

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22025 in the body.
You can then email your comments to 22025 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Fri, 27 Nov 2015 08:37:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alan Mackenzie <acm <at> muc.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 27 Nov 2015 08:37:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Fri, 27 Nov 2015 08:38:37 +0000
Hello, Emacs

Having recently saved a desktop in Emacs 24.5, run Emacs 25, allowing
desktop to load all ones files.  Exit Emacs 25.

Start Emacs 24.5 again.  The desktop fails to load.  This is a Bad
Thing.

Diagnosis
---------

Emacs 25 has read a version 206 .desktop file, but written a version 208
file on termination.  Emacs 24 cannot execute this version.

There was no yes-or-no-p asking "are you sure you want to convert your
desktop to a format incompatible with previous Emacs versions?".

Manually restoring a .desktop to version 206 is fraught with
difficulties, even for somebody (myself) who understands the issues
reasonably well, and has an old version of .desktop saved "just in
case".

Recommendation
--------------

Emacs 25, having loaded a version 206 .desktop, should save it in the
same format until the user has positively consented to it being
converted to version 208.

-- 
Alan Mackenzie (Nuremberg, Germany).




Severity set to 'wishlist' from 'normal' Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Fri, 27 Nov 2015 09:04:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Fri, 27 Nov 2015 09:06:02 GMT) Full text and rfc822 format available.

Message #10 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Fri, 27 Nov 2015 11:05:25 +0200
> Date: Fri, 27 Nov 2015 08:38:37 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> 
> Emacs 25 has read a version 206 .desktop file, but written a version 208
> file on termination.  Emacs 24 cannot execute this version.
> 
> There was no yes-or-no-p asking "are you sure you want to convert your
> desktop to a format incompatible with previous Emacs versions?".
> 
> Manually restoring a .desktop to version 206 is fraught with
> difficulties, even for somebody (myself) who understands the issues
> reasonably well, and has an old version of .desktop saved "just in
> case".
> 
> Recommendation
> --------------
> 
> Emacs 25, having loaded a version 206 .desktop, should save it in the
> same format until the user has positively consented to it being
> converted to version 208.

This would be a nice enhancement, but it certainly isn't a bug in my
book.

Of course, if making that happen is relatively easy, it would be good
to have such a compatibility mode.  Patches welcome.

I marked it wishlist.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Fri, 27 Nov 2015 09:46:01 GMT) Full text and rfc822 format available.

Message #13 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Fri, 27 Nov 2015 09:47:18 +0000
Hello, Eli.

On Fri, Nov 27, 2015 at 11:05:25AM +0200, Eli Zaretskii wrote:
> > Date: Fri, 27 Nov 2015 08:38:37 +0000
> > From: Alan Mackenzie <acm <at> muc.de>

> > Emacs 25 has read a version 206 .desktop file, but written a version 208
> > file on termination.  Emacs 24 cannot execute this version.

> > There was no yes-or-no-p asking "are you sure you want to convert your
> > desktop to a format incompatible with previous Emacs versions?".

> > Manually restoring a .desktop to version 206 is fraught with
> > difficulties, even for somebody (myself) who understands the issues
> > reasonably well, and has an old version of .desktop saved "just in
> > case".

> > Recommendation
> > --------------

> > Emacs 25, having loaded a version 206 .desktop, should save it in the
> > same format until the user has positively consented to it being
> > converted to version 208.

> This would be a nice enhancement, but it certainly isn't a bug in my
> book.

I couldn't disagree more.  Users should be free to update to Emacs 25,
but it shouldn't be for us to force them.

I've just lost half a morning restoring my .desktop to the earlier
format.  Most users wouldn't be able to do this.

I think we are enormously cavalier with the .desktop file - no backup of
any type (such as .emacs.desktop~) is kept, and should there be trouble
reading .desktop, it is difficult to exit Emacs without having this
.desktop overwritten.

> Of course, if making that happen is relatively easy, it would be good
> to have such a compatibility mode.  Patches welcome.

I will work on this.

> I marked it wishlist.

I really wish you hadn't.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Fri, 27 Nov 2015 10:25:01 GMT) Full text and rfc822 format available.

Message #16 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Fri, 27 Nov 2015 12:23:10 +0200
> Date: Fri, 27 Nov 2015 09:47:18 +0000
> Cc: 22025 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > This would be a nice enhancement, but it certainly isn't a bug in my
> > book.
> 
> I couldn't disagree more.  Users should be free to update to Emacs 25,
> but it shouldn't be for us to force them.

??? How's this forcing an upgrade?  The issue won't exist until the
user, out of their free will, starts Emacs 25.

> I've just lost half a morning restoring my .desktop to the earlier
> format.  Most users wouldn't be able to do this.

I'm sorry for the time you've lost.  I've learned a long time ago to
back up my desktop file each time I experiment with a different
version of Emacs without using the -Q switch.

> I think we are enormously cavalier with the .desktop file - no backup of
> any type (such as .emacs.desktop~) is kept, and should there be trouble
> reading .desktop, it is difficult to exit Emacs without having this
> .desktop overwritten.

Maybe having backups for it would be a good and safe measure, indeed.
At least as an option.  Does anyone see any reasons why not?

> > Of course, if making that happen is relatively easy, it would be good
> > to have such a compatibility mode.  Patches welcome.
> 
> I will work on this.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Fri, 27 Nov 2015 11:38:01 GMT) Full text and rfc822 format available.

Message #19 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Fri, 27 Nov 2015 11:39:16 +0000
Hello, Eli.

On Fri, Nov 27, 2015 at 12:23:10PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 27 Nov 2015 09:47:18 +0000
> > Cc: 22025 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > > This would be a nice enhancement, but it certainly isn't a bug in my
> > > book.

> > I couldn't disagree more.  Users should be free to update to Emacs 25,
> > but it shouldn't be for us to force them.

> ??? How's this forcing an upgrade?  The issue won't exist until the
> user, out of their free will, starts Emacs 25.

Because people will "just try out" Emacs 25.  That's what I always do
with new Emacsen.  Then before deciding to upgrade, they find that their
.emacs.desktop won't work in their accustomed setups any longer (which
is a horrible surprise), effectively forcing them to upgrade.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Fri, 27 Nov 2015 12:30:03 GMT) Full text and rfc822 format available.

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Fri, 27 Nov 2015 12:27:54 +0000
On Fri 27 Nov 2015, Eli Zaretskii wrote:

>> I think we are enormously cavalier with the .desktop file - no backup of
>> any type (such as .emacs.desktop~) is kept, and should there be trouble
>> reading .desktop, it is difficult to exit Emacs without having this
>> .desktop overwritten.
>
> Maybe having backups for it would be a good and safe measure, indeed.
> At least as an option.  Does anyone see any reasons why not?

I add this to desktop-save-hook to avoid problems with lost or corrupted
desktop files:

  (defun ajm:backup-desktop-file ()
    "Save a backup of the desktop file."
    (let* ((version-control     t)
           (delete-old-versions t)
           (kept-new-versions   8)
           (kept-old-versions   2)
           (file   (desktop-full-file-name))
           (names  (find-backup-file-name file))
           (backup (pop names)))
      (when (and (file-exists-p file) backup)
        (copy-file file backup nil t)
        (message "Saved backup of desktop file '%s' as '%s'." file backup)
        (mapc #'delete-file names))))

Doubtless this is hacky and could be improved, but it seems to work for me.

>> > Of course, if making that happen is relatively easy, it would be good
>> > to have such a compatibility mode.  Patches welcome.
>> 
>> I will work on this.

I haven't checked recently, but this worked for me the last time I used
emacs-25 desktop files with emacs-24:

  (when (< emacs-major-version 25)
    (defun ajm:fixup-desktop-create-buffer (args)
      "Fixup for emacs-24 to use emacs-25 desktop files."
      (let ((nargs (length args)))
        (if (> nargs 10)
            (butlast args (- nargs 10))
          args)))
    (advice-add 'desktop-create-buffer :filter-args
                'ajm:fixup-desktop-create-buffer))

With that advice installed, both emacs versions can read either version
of desktop file. If emacs-24 reads a version 208 desktop file and then
saves a version 206 desktop file, then there may be minor information
loss.

    AndyM





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Tue, 01 Dec 2015 12:18:02 GMT) Full text and rfc822 format available.

Message #25 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Tue, 1 Dec 2015 12:19:41 +0000
On Fri, Nov 27, 2015 at 11:05:25AM +0200, Eli Zaretskii wrote:
> > Date: Fri, 27 Nov 2015 08:38:37 +0000
> > From: Alan Mackenzie <acm <at> muc.de>

> > Emacs 25 has read a version 206 .desktop file, but written a version 208
> > file on termination.  Emacs 24 cannot execute this version.

> > There was no yes-or-no-p asking "are you sure you want to convert your
> > desktop to a format incompatible with previous Emacs versions?".

> > Manually restoring a .desktop to version 206 is fraught with
> > difficulties, even for somebody (myself) who understands the issues
> > reasonably well, and has an old version of .desktop saved "just in
> > case".

> > Recommendation
> > --------------

> > Emacs 25, having loaded a version 206 .desktop, should save it in the
> > same format until the user has positively consented to it being
> > converted to version 208.

> This would be a nice enhancement, but it certainly isn't a bug in my
> book.

> Of course, if making that happen is relatively easy, it would be good
> to have such a compatibility mode.  Patches welcome.

OK, here is a patch.  It introduces a customizable variable,
`desktop-version-strategy' which specifies in which version (206 or 208),
the desktop file should be saved.  Until that variable is set to non-nil,
the user is prompted each time the desktop is loaded.  She is given the
opportunity at that time to customize it immediately via a `yes-or-no-p'.




diff --git a/lisp/desktop.el b/lisp/desktop.el
index 5a709b9..e5b4395 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -143,6 +143,16 @@ desktop-file-version
 Written into the desktop file and used at desktop read to provide
 backward compatibility.")
 
+(defconst desktop-native-file-version 208
+  "Format version of the current desktop package, an integer.")
+(defvar desktop-infile-version nil
+  "The format version of the current desktop file, an integer or nil.")
+;; Note: Historically, the version number is embedded in the entry for
+;; each buffer.  It is highly inadvisable for different buffer entries
+;; to have different format versions.
+(defvar desktop-outfile-version nil
+  "The format version in which the desktop file will next be written, or nil")
+
 ;; ----------------------------------------------------------------------------
 ;; USER OPTIONS -- settings you might want to play with.
 ;; ----------------------------------------------------------------------------
@@ -240,6 +250,19 @@ desktop-load-locked-desktop
   :group 'desktop
   :version "22.2")
 
+(defcustom desktop-version-strategy nil
+  "Strategy to chose format version when writing .emacs.desktop file.
+Version 206 is compatible with Emacs 22.x, 23.x and 24.x, and also with Emacs 25.x.
+Version 208 is enhanced, but incompatible with Emacs 24.x and earlier."
+  :type '(radio
+          (const :tag "Keep current format, and prompt user again when there's \
+an old format at next desktop load." nil)
+          (const :tag "Keep current format, but don't prompt the user again." t)
+          (const :tag "Save desktop file in format 206 (compatible with Emacs <= 24)." 206)
+          (const :tag "Save desktop file in format 208 (Emacs >= 25)." 208))
+  :group 'desktop
+  :version "25.1")
+
 (define-obsolete-variable-alias 'desktop-basefilename
                                 'desktop-base-file-name "22.1")
 
@@ -781,44 +804,46 @@ desktop-buffer-info
     local variables;
     auxiliary information given by `desktop-var-serdes-funs'."
   (set-buffer buffer)
-  (list
-   ;; base name of the buffer; replaces the buffer name if managed by uniquify
-   (and (fboundp 'uniquify-buffer-base-name) (uniquify-buffer-base-name))
-   ;; basic information
-   (desktop-file-name (buffer-file-name) desktop-dirname)
-   (buffer-name)
-   major-mode
-   ;; minor modes
-   (let (ret)
-     (dolist (minor-mode (mapcar #'car minor-mode-alist) ret)
-       (and (boundp minor-mode)
-            (symbol-value minor-mode)
-            (let* ((special (assq minor-mode desktop-minor-mode-table))
-                   (value (cond (special (cadr special))
-                                ((functionp minor-mode) minor-mode))))
-              (when value (cl-pushnew value ret))))))
-   ;; point and mark, and read-only status
-   (point)
-   (list (mark t) mark-active)
-   buffer-read-only
-   ;; auxiliary information
-   (when (functionp desktop-save-buffer)
-     (funcall desktop-save-buffer desktop-dirname))
-   ;; local variables
-   (let ((loclist (buffer-local-variables))
-	 (ll nil))
-     (dolist (local desktop-locals-to-save)
-       (let ((here (assq local loclist)))
-	 (cond (here
-		(push here ll))
-	       ((member local loclist)
-		(push local ll)))))
-     ll)
-   (mapcar (lambda (record)
-	     (let ((var (car record)))
-	       (list var
-		     (funcall (cadr record) (symbol-value var)))))
-	   desktop-var-serdes-funs)))
+  `(
+    ;; base name of the buffer; replaces the buffer name if managed by uniquify
+    ,(and (fboundp 'uniquify-buffer-base-name) (uniquify-buffer-base-name))
+    ;; basic information
+    ,(desktop-file-name (buffer-file-name) desktop-dirname)
+    ,(buffer-name)
+    ,major-mode
+    ;; minor modes
+    ,(let (ret)
+       (dolist (minor-mode (mapcar #'car minor-mode-alist) ret)
+         (and (boundp minor-mode)
+              (symbol-value minor-mode)
+              (let* ((special (assq minor-mode desktop-minor-mode-table))
+                     (value (cond (special (cadr special))
+                                  ((functionp minor-mode) minor-mode))))
+                (when value (cl-pushnew value ret))))))
+    ;; point and mark, and read-only status
+    ,(point)
+    ,(list (mark t) mark-active)
+    ,buffer-read-only
+    ;; auxiliary information
+    ,(when (functionp desktop-save-buffer)
+       (funcall desktop-save-buffer desktop-dirname))
+    ;; local variables
+    ,(let ((loclist (buffer-local-variables))
+           (ll nil))
+       (dolist (local desktop-locals-to-save)
+         (let ((here (assq local loclist)))
+           (cond (here
+                  (push here ll))
+                 ((member local loclist)
+                  (push local ll)))))
+       ll)
+   ,@(when (>= desktop-outfile-version 208)
+       (list
+        (mapcar (lambda (record)
+                  (let ((var (car record)))
+                    (list var
+                          (funcall (cadr record) (symbol-value var)))))
+                desktop-var-serdes-funs)))))
 
 ;; ----------------------------------------------------------------------------
 (defun desktop--v2s (value)
@@ -1017,12 +1042,22 @@ desktop-save
 	    (desktop-release-lock)
 	  (unless (and new-modtime (desktop-owner)) (desktop-claim-lock)))
 
+        ;; What format are we going to write the file in?
+        (setq desktop-outfile-version
+              (cond
+               ((memq desktop-version-strategy '(208 206))
+                desktop-version-strategy)
+               (desktop-infile-version)
+               (desktop-outfile-version)
+               (t                    ; As yet, no desktop file exists.
+                desktop-native-file-version)))
+
 	(with-temp-buffer
 	  (insert
 	   ";; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n"
 	   desktop-header
 	   ";; Created " (current-time-string) "\n"
-	   ";; Desktop file format version " desktop-file-version "\n"
+	   ";; Desktop file format version " (format "%d" desktop-outfile-version) "\n"
 	   ";; Emacs version " emacs-version "\n")
 	  (save-excursion (run-hooks 'desktop-save-hook))
 	  (goto-char (point-max))
@@ -1052,7 +1087,7 @@ desktop-save
 			    "desktop-create-buffer"
 			  "desktop-append-buffer-args")
 			" "
-			desktop-file-version)
+			(format "%d" desktop-outfile-version))
 		;; If there's a non-empty base name, we save it instead of the buffer name
 		(when (and base (not (string= base "")))
 		  (setcar (nthcdr 1 l) base))
@@ -1121,6 +1156,44 @@ desktop-first-buffer
 (defvar desktop-buffer-ok-count)
 (defvar desktop-buffer-fail-count)
 
+;; ----------------------------------------------------------------------------
+;; Instruct and prompt the user about desktop format version change.
+(defvar desktop-customize-strategy-flag nil
+  "Non-nil when the user has requested cutomization of `desktop-version-strategy'")
+
+(defun desktop-warn-about-and-prompt-for-strategy ()
+  "Warn the user that her desktop file is in an old format, and
+prompt her to customize `desktop-version-strategy'."
+  (save-window-excursion
+    (with-output-to-temp-buffer "*Desktop Format Strategy*"
+      (mapc
+       #'princ
+       `("Your desktop file appears to be in an old format "
+         ,(format "%d" desktop-infile-version)
+         ",\nwhich Emacs "
+         ,(format "%s" emacs-version)
+         " should be able to read successfully.\n\n"
+         "Until you configure Emacs to deal with this, you will be\n"
+         "prompted like this each time you load your desktop.\n\n"
+         "You can chose to preserve the original format of your desktop file,\n"
+         "always to set the format to version 206 (which dates back to Emacs 22.1)\n"
+         "or always to set it to version 208 (the new Emacs 25.x format).\n\n"
+         "BE AWARE THAT Emacs 24.x AND EARLIER CANNOT READ A VERSION 208\n"
+         "DESKTOP FILE!\n\n"
+         "Customize `desktop-version-strategy' to make this choice.\n"
+         "You can do this now (after your buffers have been loaded), or at\n"
+         "any later time.\n\n"
+         "You are recommended to set this user option to version 208 as soon\n"
+         "as you have firmly upgraded to Emacs 25.1 (or later), so as to enjoy\n"
+         "the enhancements which version 208 provides.\n")))
+
+    (setq desktop-customize-strategy-flag
+          (condition-case nil ; Prevent C-g aborting the desktop load.
+              (yes-or-no-p "Customize desktop-version-strategy now \
+\(after buffers are loaded)? ")
+            (quit nil)))
+    (kill-buffer "*Desktop Format Strategy*")))
+
 ;; FIXME Interactively, this should have the option to prompt for dirname.
 ;;;###autoload
 (defun desktop-read (&optional dirname)
@@ -1230,6 +1303,11 @@ desktop-read
 				  (set-window-next-buffers window nil))))
  	    (setq desktop-saved-frameset nil)
 	    (if desktop-autosave-was-enabled (desktop-auto-save-enable))
+
+            ;; Has the user requested to configure `desktop-version-strategy'?
+            (when desktop-customize-strategy-flag
+              (setq desktop-customize-strategy-flag nil)
+              (customize-variable 'desktop-version-strategy))
 	    t))
       ;; No desktop file found.
       (let ((default-directory desktop-dirname))
@@ -1400,6 +1478,17 @@ desktop-create-buffer
 	(desktop-buffer-read-only   buffer-readonly)
 	(desktop-buffer-misc	    buffer-misc)
 	(desktop-buffer-locals	    buffer-locals))
+
+    ;; If this is the first buffer of the session, and the user
+    ;; appears to have just updated to the current Emacs version, warn
+    ;; her about the change in the desktop file format, and prompt her
+    ;; to set `desktop-version-strategy.
+    (when (null desktop-infile-version)
+      (setq desktop-infile-version file-version)
+      (when (and (null desktop-version-strategy)
+                 (/= desktop-infile-version desktop-native-file-version))
+        (desktop-warn-about-and-prompt-for-strategy)))
+
     ;; To make desktop files with relative file names possible, we cannot
     ;; allow `default-directory' to change. Therefore we save current buffer.
     (save-current-buffer


-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Tue, 01 Dec 2015 15:44:02 GMT) Full text and rfc822 format available.

Message #28 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Tue, 01 Dec 2015 17:43:13 +0200
> Date: Tue, 1 Dec 2015 12:19:41 +0000
> Cc: 22025 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> OK, here is a patch.  It introduces a customizable variable,
> `desktop-version-strategy' which specifies in which version (206 or 208),
> the desktop file should be saved.  Until that variable is set to non-nil,
> the user is prompted each time the desktop is loaded.  She is given the
> opportunity at that time to customize it immediately via a `yes-or-no-p'.

Thanks.  I'd ask Juanma to review the patch, but I have a comment on
this design: is it really a good idea to nag the user with these
questions?  This will happen to every single Emacs user once they
upgrade to Emacs 25.1.  Do we really want that?

How about the following strategy instead: by default always save in
backward compatible way, and give the user a command (or a prefix
argument to desktop-save, perhaps) to switch to the new format?  I
think this will be nicer to our users, and will also save us
yet-another defcustom.

WDYT?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Tue, 01 Dec 2015 17:00:04 GMT) Full text and rfc822 format available.

Message #31 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Tue, 1 Dec 2015 17:01:38 +0000
Hello, Eli.

On Tue, Dec 01, 2015 at 05:43:13PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 1 Dec 2015 12:19:41 +0000
> > Cc: 22025 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > OK, here is a patch.  It introduces a customizable variable,
> > `desktop-version-strategy' which specifies in which version (206 or 208),
> > the desktop file should be saved.  Until that variable is set to non-nil,
> > the user is prompted each time the desktop is loaded.  She is given the
> > opportunity at that time to customize it immediately via a `yes-or-no-p'.

> Thanks.  I'd ask Juanma to review the patch, but I have a comment on
> this design: is it really a good idea to nag the user with these
> questions?  This will happen to every single Emacs user once they
> upgrade to Emacs 25.1.  Do we really want that?

I think we do, yes.  "Nag" might be a bit of an overstatement,
considering that the user need only be subjected to the questions once,
and is provided with an easy means of avoiding them in the future.  We
are, after all, talking about a backwards incompatible change here.

> How about the following strategy instead: by default always save in
> backward compatible way, and give the user a command (or a prefix
> argument to desktop-save, perhaps) to switch to the new format?  I
> think this will be nicer to our users, and will also save us
> yet-another defcustom.

Yes, I'm not too keen of the defcustom either.  But we could save the
desktop file in the same format it was read in, and offer facilities to
convert to the new format (or back to the old one, even).

> WDYT?

I think (but I don't know for sure) that explicitly invoking
`desktop-save' is quite rare - most desktop files will be saved at Emacs
shutdown, so a prefix argument to `desktop-save' might not be optimal.
But thinking about it again, that would be a conscious deliberate action
which couldn't be done accidentally.

I think we need some way of alerting all users to the change.  Otherwise
we could end up with lots of users never upgrading their desktops at
all, which would be a shame.  The trouble is, we also need some way of
not alerting the users too often, and then we're coming back to some
sort of variable, if not a defcustom.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Tue, 01 Dec 2015 17:48:01 GMT) Full text and rfc822 format available.

Message #34 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org
Subject: RE: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Tue, 1 Dec 2015 09:46:57 -0800 (PST)
> 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.

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

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.

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.

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.

HTH. 




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Tue, 01 Dec 2015 18:48:02 GMT) Full text and rfc822 format available.

Message #37 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Tue, 01 Dec 2015 20:46:51 +0200
> Date: Tue, 1 Dec 2015 17:01:38 +0000
> Cc: 22025 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> I think we need some way of alerting all users to the change.  Otherwise
> we could end up with lots of users never upgrading their desktops at
> all, which would be a shame.  The trouble is, we also need some way of
> not alerting the users too often, and then we're coming back to some
> sort of variable, if not a defcustom.

I think NEWS is the appropriate place to alert them to this.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Wed, 02 Dec 2015 11:26:01 GMT) Full text and rfc822 format available.

Message #40 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Wed, 2 Dec 2015 11:27:22 +0000
Hello, Eli.

On Tue, Dec 01, 2015 at 08:46:51PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 1 Dec 2015 17:01:38 +0000
> > Cc: 22025 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > I think we need some way of alerting all users to the change.  Otherwise
> > we could end up with lots of users never upgrading their desktops at
> > all, which would be a shame.  The trouble is, we also need some way of
> > not alerting the users too often, and then we're coming back to some
> > sort of variable, if not a defcustom.

> I think NEWS is the appropriate place to alert them to this.

I'm a bit wary about NEWS.  How many people actually read it thoroughly?
At each new release, I try to read NEWS, but my eyes start glazing over
before I even get half way through.

But that aside, how about the following NEWS entry (to be followed by
actual code)?


** Desktop

---
*** The desktop format version has been upgraded from 206 to 208.
Although Emacs 25.1 can read a version 206 desktop, earlier Emacsen
cannot read a version 208 desktop.  To upgrade your desktop file, you
must explicitly request the upgrade by C-u M-x desktop-save.  You are
recommended to do this as soon as you have firmly upgraded to Emacs
25.1 (or later).  Should you ever need to downgrade your desktop file
to version 206, you can do this with C-u C-u M-x desktop-save.


An additional possibility would by to nag the user with a prompt in the
echo area after loading a 206 desktop.  Something like:

You have loaded an old format desktop file.  To upgrade it, see NEWS (C-h n).

, together with a variable to disable it.  Maybe.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Wed, 02 Dec 2015 12:34:02 GMT) Full text and rfc822 format available.

Message #43 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Wed, 2 Dec 2015 12:35:31 +0000
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).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Wed, 02 Dec 2015 13:23:02 GMT) Full text and rfc822 format available.

Message #46 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Wed, 02 Dec 2015 13:16:53 +0000
On Wed 02 Dec 2015, Alan Mackenzie wrote:

> Hello, Eli.
>
> On Tue, Dec 01, 2015 at 08:46:51PM +0200, Eli Zaretskii wrote:
>> > Date: Tue, 1 Dec 2015 17:01:38 +0000
>> > Cc: 22025 <at> debbugs.gnu.org
>> > From: Alan Mackenzie <acm <at> muc.de>
>
>> > I think we need some way of alerting all users to the change.  Otherwise
>> > we could end up with lots of users never upgrading their desktops at
>> > all, which would be a shame.  The trouble is, we also need some way of
>> > not alerting the users too often, and then we're coming back to some
>> > sort of variable, if not a defcustom.
>
>> I think NEWS is the appropriate place to alert them to this.
>
> I'm a bit wary about NEWS.  How many people actually read it thoroughly?
> At each new release, I try to read NEWS, but my eyes start glazing over
> before I even get half way through.
>
> But that aside, how about the following NEWS entry (to be followed by
> actual code)?
>
>
> ** Desktop
>
> ---
> *** The desktop format version has been upgraded from 206 to 208.
> Although Emacs 25.1 can read a version 206 desktop, earlier Emacsen
> cannot read a version 208 desktop.  To upgrade your desktop file, you
> must explicitly request the upgrade by C-u M-x desktop-save.  You are
> recommended to do this as soon as you have firmly upgraded to Emacs
> 25.1 (or later).  Should you ever need to downgrade your desktop file
> to version 206, you can do this with C-u C-u M-x desktop-save.
>
> An additional possibility would by to nag the user with a prompt in the
> echo area after loading a 206 desktop.  Something like:
>
> You have loaded an old format desktop file.  To upgrade it, see NEWS (C-h n).
>
> , together with a variable to disable it.  Maybe.

Another possibility is an ELPA package for older emacsen to allow them
to read and write version 208 format desktop files.

    AndyM





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Wed, 02 Dec 2015 13:51:02 GMT) Full text and rfc822 format available.

Message #49 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Wed, 02 Dec 2015 15:50:49 +0200
> Date: Wed, 2 Dec 2015 11:27:22 +0000
> Cc: 22025 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > I think NEWS is the appropriate place to alert them to this.
> 
> I'm a bit wary about NEWS.  How many people actually read it thoroughly?
> At each new release, I try to read NEWS, but my eyes start glazing over
> before I even get half way through.

If they don't pay attention, they will stay with the old format.  Do
they lose much?

> But that aside, how about the following NEWS entry (to be followed by
> actual code)?

LGTM, thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Wed, 02 Dec 2015 14:48:02 GMT) Full text and rfc822 format available.

Message #52 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org
Subject: RE: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Wed, 2 Dec 2015 06:47:30 -0800 (PST)
> > > 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+?

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

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

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

OK.  Now I guess I'll have to look at desktop.el, to see
whether the changes break desktop bookmarking, and if so,
adapt. ;-)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Thu, 03 Dec 2015 08:39:02 GMT) Full text and rfc822 format available.

Message #55 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Thu, 3 Dec 2015 08:40:31 +0000
Hello, Eli.

On Wed, Dec 02, 2015 at 03:50:49PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 2 Dec 2015 11:27:22 +0000
> > Cc: 22025 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > > I think NEWS is the appropriate place to alert them to this.

> > I'm a bit wary about NEWS.  How many people actually read it thoroughly?
> > At each new release, I try to read NEWS, but my eyes start glazing over
> > before I even get half way through.

> If they don't pay attention, they will stay with the old format.  Do
> they lose much?

They will lose the mark ring being save.  Precisely that.  Possibly more
information will be added to buffer entries in the future (version 208
seems designed to allow that possibility whilst staying backward
compatible).

> > But that aside, how about the following NEWS entry (to be followed by
> > actual code)?

> LGTM, thanks.

OK, here is the patch.  Do you think I should solicit a review from
somebody else before I commit it to emacs-25?


Desktop: protect users against inadvertant upgrading of desktop file.

An upgraded (version 208) desktop file cannot be read in Emacs < 25.

* etc/NEWS: Add an entry about upgrading a desktop file.

* lisp/desktop.el (desktop-file-version): Amend doc string.
(desktop-native-file-version, desktop-io-file-version): new variables.
(desktop-clear): Set desktop-io-file-version to nil.
(desktop-buffer-info): make the presence of the last item on the list
conditional on (>= desktop-io-file-version 208).
(desktop-save): Add extra parameter VERSION to take user's C-u or C-u
C-u.
Amend the doc string.  Add code to determine the output file version.
(desktop-create-buffer): Set desktop-io-file-version to the input file's
version.



diff --git a/etc/NEWS b/etc/NEWS
index a18c9ce..e7439fd 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -371,6 +371,17 @@ current package keywords are recognized.  Set the new option
 It's meant for use together with `compile':
 emacs -batch --eval "(checkdoc-file \"subr.el\")"
 
+** Desktop
+
+---
+*** The desktop format version has been upgraded from 206 to 208.
+Although Emacs 25.1 can read a version 206 desktop, earlier Emacsen
+cannot read a version 208 desktop.  To upgrade your desktop file, you
+must explicitly request the upgrade, by C-u M-x desktop-save.  You are
+recommended to do this as soon as you have firmly upgraded to Emacs
+25.1 (or later).  Should you ever need to downgrade your desktop file
+to version 206, you can do this with C-u C-u M-x desktop-save.
+
 ** New function `bookmark-set-no-overwrite' bound to C-x r M.
 It raises an error if a bookmark of that name already exists,
 unlike `bookmark-set' which silently updates an existing bookmark.
diff --git a/lisp/desktop.el b/lisp/desktop.el
index 5a709b9..ee7a7ae 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -140,8 +140,15 @@
 
 (defvar desktop-file-version "208"
   "Version number of desktop file format.
-Written into the desktop file and used at desktop read to provide
-backward compatibility.")
+Used at desktop read to provide backward compatibility.")
+
+(defconst desktop-native-file-version 208
+  "Format version of the current desktop package, an integer.")
+(defvar desktop-io-file-version nil
+  "The format version of the current desktop file (an integer) or nil.")
+;; Note: Historically, the version number is embedded in the entry for
+;; each buffer.  It is highly inadvisable for different buffer entries
+;; to have different format versions.
 
 ;; ----------------------------------------------------------------------------
 ;; USER OPTIONS -- settings you might want to play with.
@@ -693,6 +700,7 @@ desktop-clear
 if different)."
   (interactive)
   (desktop-lazy-abort)
+  (setq desktop-io-file-version nil)
   (dolist (var desktop-globals-to-clear)
     (if (symbolp var)
 	(eval `(setq-default ,var nil))
@@ -781,44 +789,46 @@ desktop-buffer-info
     local variables;
     auxiliary information given by `desktop-var-serdes-funs'."
   (set-buffer buffer)
-  (list
-   ;; base name of the buffer; replaces the buffer name if managed by uniquify
-   (and (fboundp 'uniquify-buffer-base-name) (uniquify-buffer-base-name))
-   ;; basic information
-   (desktop-file-name (buffer-file-name) desktop-dirname)
-   (buffer-name)
-   major-mode
-   ;; minor modes
-   (let (ret)
-     (dolist (minor-mode (mapcar #'car minor-mode-alist) ret)
-       (and (boundp minor-mode)
-            (symbol-value minor-mode)
-            (let* ((special (assq minor-mode desktop-minor-mode-table))
-                   (value (cond (special (cadr special))
-                                ((functionp minor-mode) minor-mode))))
-              (when value (cl-pushnew value ret))))))
-   ;; point and mark, and read-only status
-   (point)
-   (list (mark t) mark-active)
-   buffer-read-only
-   ;; auxiliary information
-   (when (functionp desktop-save-buffer)
-     (funcall desktop-save-buffer desktop-dirname))
-   ;; local variables
-   (let ((loclist (buffer-local-variables))
-	 (ll nil))
-     (dolist (local desktop-locals-to-save)
-       (let ((here (assq local loclist)))
-	 (cond (here
-		(push here ll))
-	       ((member local loclist)
-		(push local ll)))))
-     ll)
-   (mapcar (lambda (record)
-	     (let ((var (car record)))
-	       (list var
-		     (funcall (cadr record) (symbol-value var)))))
-	   desktop-var-serdes-funs)))
+  `(
+    ;; base name of the buffer; replaces the buffer name if managed by uniquify
+    ,(and (fboundp 'uniquify-buffer-base-name) (uniquify-buffer-base-name))
+    ;; basic information
+    ,(desktop-file-name (buffer-file-name) desktop-dirname)
+    ,(buffer-name)
+    ,major-mode
+    ;; minor modes
+    ,(let (ret)
+       (dolist (minor-mode (mapcar #'car minor-mode-alist) ret)
+         (and (boundp minor-mode)
+              (symbol-value minor-mode)
+              (let* ((special (assq minor-mode desktop-minor-mode-table))
+                     (value (cond (special (cadr special))
+                                  ((functionp minor-mode) minor-mode))))
+                (when value (cl-pushnew value ret))))))
+    ;; point and mark, and read-only status
+    ,(point)
+    ,(list (mark t) mark-active)
+    ,buffer-read-only
+    ;; auxiliary information
+    ,(when (functionp desktop-save-buffer)
+       (funcall desktop-save-buffer desktop-dirname))
+    ;; local variables
+    ,(let ((loclist (buffer-local-variables))
+           (ll nil))
+       (dolist (local desktop-locals-to-save)
+         (let ((here (assq local loclist)))
+           (cond (here
+                  (push here ll))
+                 ((member local loclist)
+                  (push local ll)))))
+       ll)
+   ,@(when (>= desktop-io-file-version 208)
+       (list
+        (mapcar (lambda (record)
+                  (let ((var (car record)))
+                    (list var
+                          (funcall (cadr record) (symbol-value var)))))
+                desktop-var-serdes-funs)))))
 
 ;; ----------------------------------------------------------------------------
 (defun desktop--v2s (value)
@@ -983,20 +993,33 @@ desktop-save-frameset
 			    :predicate #'desktop--check-dont-save))))
 
 ;;;###autoload
-(defun desktop-save (dirname &optional release only-if-changed)
+(defun desktop-save (dirname &optional release only-if-changed version)
   "Save the desktop in a desktop file.
 Parameter DIRNAME specifies where to save the desktop file.
 Optional parameter RELEASE says whether we're done with this desktop.
 If ONLY-IF-CHANGED 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 do not rewrite the file."
+changed since it was last saved then do not rewrite the file.
+
+When called interactively, a bare command prefix, C-u, will cause
+the desktop file to be saved in format version 208 (which only
+Emacs 25.1 and later can read).  A double command prefix, C-u
+C-u, will save the file in version 206 (readable by any Emacs
+from version 22.1 onwards).  Confirmation will be requested in
+either case.  In a non-interactive call, VERSION can be given as
+either 206 or 208, and this will be accepted as the format
+version in which to save the desktop without further
+confirmation."
   (interactive (list
                 ;; Or should we just use (car desktop-path)?
                 (let ((default (if (member "." desktop-path)
                                    default-directory
                                  user-emacs-directory)))
                   (read-directory-name "Directory to save desktop file in: "
-                                       default default t))))
+                                       default default t))
+                nil
+                nil
+                current-prefix-arg))
   (setq desktop-dirname (file-name-as-directory (expand-file-name dirname)))
   (save-excursion
     (let ((eager desktop-restore-eager)
@@ -1017,12 +1040,34 @@ desktop-save
 	    (desktop-release-lock)
 	  (unless (and new-modtime (desktop-owner)) (desktop-claim-lock)))
 
+        ;; What format are we going to write the file in?
+        (setq desktop-io-file-version
+              (cond
+               ((equal version '(4))
+                (if (or (eq desktop-io-file-version 208)
+                        (yes-or-no-p "Save desktop file in format 208 \
+\(Readable by Emacs 25.1 and later only)? "))
+                    208
+                  (or desktop-io-file-version desktop-native-file-version)))
+               ((equal version '(16))
+                (if (or (eq desktop-io-file-version 206)
+                        (yes-or-no-p "Save desktop file in format 206 \
+\(Readable by all Emacs versions since 22.1)? "))
+                    206
+                  (or desktop-io-file-version desktop-native-file-version)))
+               ((memq version '(206 208))
+                version)
+               ((null desktop-io-file-version) ; As yet, no desktop file exists.
+                desktop-native-file-version)
+               (t
+                desktop-io-file-version)))
+
 	(with-temp-buffer
 	  (insert
 	   ";; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n"
 	   desktop-header
 	   ";; Created " (current-time-string) "\n"
-	   ";; Desktop file format version " desktop-file-version "\n"
+	   ";; Desktop file format version " (format "%d" desktop-io-file-version) "\n"
 	   ";; Emacs version " emacs-version "\n")
 	  (save-excursion (run-hooks 'desktop-save-hook))
 	  (goto-char (point-max))
@@ -1052,7 +1097,7 @@ desktop-save
 			    "desktop-create-buffer"
 			  "desktop-append-buffer-args")
 			" "
-			desktop-file-version)
+			(format "%d" desktop-io-file-version))
 		;; If there's a non-empty base name, we save it instead of the buffer name
 		(when (and base (not (string= base "")))
 		  (setcar (nthcdr 1 l) base))
@@ -1390,6 +1435,8 @@ desktop-create-buffer
      compacted-vars
      &rest _unsupported)
 
+  (setq desktop-io-file-version file-version)
+
   (let ((desktop-file-version	    file-version)
 	(desktop-buffer-file-name   buffer-filename)
 	(desktop-buffer-name	    buffer-name)


-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Thu, 03 Dec 2015 10:32:02 GMT) Full text and rfc822 format available.

Message #58 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>, Juanma Barranquero <lekktu <at> gmail.com>
Cc: 22025 <at> debbugs.gnu.org
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Thu, 03 Dec 2015 12:30:47 +0200
> Date: Thu, 3 Dec 2015 08:40:31 +0000
> Cc: 22025 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > If they don't pay attention, they will stay with the old format.  Do
> > they lose much?
> 
> They will lose the mark ring being save.  Precisely that.

Doesn't sound like a catastrophe to me.

> OK, here is the patch.  Do you think I should solicit a review from
> somebody else before I commit it to emacs-25?

I'd like Juanma to look at it, thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Thu, 03 Dec 2015 14:34:02 GMT) Full text and rfc822 format available.

Message #61 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Alan Mackenzie <acm <at> muc.de>, Juanma
 Barranquero <lekktu <at> gmail.com>
Cc: 22025 <at> debbugs.gnu.org
Subject: RE: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Thu, 3 Dec 2015 06:33:01 -0800 (PST)
Again, apologies for not really reading the bug thread.

Just wondering whether this format change will be mentioned
in NEWS, and what the reason for the change is.

In NEWS, I find only this when looking for "desktop":

*** Partial state of the eww buffers (the URIs and the titles of the
pages visited) is now preserved in the desktop file.

Is that it?  Does just _adding_ info to the file really
change the format in an incompatible way?  If so, has it
been fixed now, so that future additions (i.e., without
changes that also change the existing fields) don't result
in an incompatible change?

If this NEWS entry is in fact the announcement of the format
change, then please consider changing the wording to make
clear that this is not just a benign addition of info but
is an incompatible format change for the file.

(A priori, I have nothing against a change.  But it would
be good to know what this is about.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Thu, 03 Dec 2015 14:55:02 GMT) Full text and rfc822 format available.

Message #64 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 22025 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Thu, 3 Dec 2015 14:57:02 +0000
Hello, Drew.

On Thu, Dec 03, 2015 at 06:33:01AM -0800, Drew Adams wrote:
> Again, apologies for not really reading the bug thread.

:-)

> Just wondering whether this format change will be mentioned
> in NEWS, and what the reason for the change is.

I have written a NEWS entry for it.  The reason for the change seems to
be twofold: (i) to store the mark ring of each buffer; (ii) to allow
further information to be added later, without there being another
backward incompatible change.

> In NEWS, I find only this when looking for "desktop":

> *** Partial state of the eww buffers (the URIs and the titles of the
> pages visited) is now preserved in the desktop file.

> Is that it?

No, that's not it.  My NEWS entry will be undergoing review, together
with my patch to desktop.el, in the next few hours/days.

> Does just _adding_ info to the file really change the format in an
> incompatible way?

Yes, it does.  Once a desktop file has been upgraded to version 208, it
can no longer be read by Emacs < 25.1.

> If so, has it been fixed now, so that future additions (i.e., without
> changes that also change the existing fields) don't result in an
> incompatible change?

Yes, it has.

> If this NEWS entry is in fact the announcement of the format
> change, then please consider changing the wording to make
> clear that this is not just a benign addition of info but
> is an incompatible format change for the file.

There's a new NEWS entry in the pipeline.

> (A priori, I have nothing against a change.  But it would
> be good to know what this is about.)

The current plan is as follows: a desktop file will stay in format
version 206 (which works with any Emacs from 22.1) until the user
positively decides to upgrade it to 208, which she will do with C-u M-x
save-desktop.  If, for any reason, a desktop needs to be put back to
206, this can be done with C-u C-u M-x save-desktop.  There are
programmatic equivalents to these command options.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Thu, 03 Dec 2015 15:36:02 GMT) Full text and rfc822 format available.

Message #67 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: RE: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Thu, 3 Dec 2015 07:35:24 -0800 (PST)
That all sounds great.  Thanks for working on this and for answering
my questions about it so clearly.

> The current plan is as follows: a desktop file will stay in format
> version 206 (which works with any Emacs from 22.1) until the user
> positively decides to upgrade it to 208, which she will do with C-u M-x
> save-desktop.  If, for any reason, a desktop needs to be put back to
> 206, this can be done with C-u C-u M-x save-desktop.  There are
> programmatic equivalents to these command options.

I don't really understand why the upgrade is not automatic, but
I don't need to.

Sounds good.  Thx.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Thu, 03 Dec 2015 15:43:02 GMT) Full text and rfc822 format available.

Message #70 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 22025 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Thu, 3 Dec 2015 15:44:55 +0000
Hello, Drew.

On Thu, Dec 03, 2015 at 07:35:24AM -0800, Drew Adams wrote:
> That all sounds great.  Thanks for working on this and for answering
> my questions about it so clearly.

> > The current plan is as follows: a desktop file will stay in format
> > version 206 (which works with any Emacs from 22.1) until the user
> > positively decides to upgrade it to 208, which she will do with C-u M-x
> > save-desktop.  If, for any reason, a desktop needs to be put back to
> > 206, this can be done with C-u C-u M-x save-desktop.  There are
> > programmatic equivalents to these command options.

> I don't really understand why the upgrade is not automatic, but
> I don't need to.

But I think you should.  With an automatic upgrade, somebody "just
trying out" Emacs 25.1 would be going to get very upset on finding out
that their precious .emacs.desktop had suddenly been rendered unusable
with their current Emacs version.

This might be misinterpreted as a dirty trick to force people to upgrade
to Emacs 25.1.

> Sounds good.  Thx.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Fri, 15 Jan 2016 16:16:01 GMT) Full text and rfc822 format available.

Message #73 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Fri, 15 Jan 2016 16:18:06 +0000
Hello, Eli.

(Recap of thread: the current emacs-25 branch desktop.el silently
converts a .emacs.desktop file into version 208, which is incompatible
with the desktop.el in Emacs 24.5.  I wrote an amendment, by which such
a conversion would happen only at the explicit request of the user.
That patch was the topic of this thread back in early December.)

On Thu, Dec 03, 2015 at 12:30:47PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 3 Dec 2015 08:40:31 +0000
> > Cc: 22025 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > > If they don't pay attention, they will stay with the old format.  Do
> > > they lose much?

> > They will lose the mark ring being save.  Precisely that.

> Doesn't sound like a catastrophe to me.

> > OK, here is the patch.  Do you think I should solicit a review from
> > somebody else before I commit it to emacs-25?

> I'd like Juanma to look at it, thanks.

I asked Juanma back then to review it, but he seems to have disappeared.
I hope nothing bad has happened to him.

I do think it would be a good thing for this patch to make it into the
first pre-test version of Emacs 25.1, to save our pretesters from having
their .emacs.desktop's becoming incompatible with their main Emacs
systems.

Could somebody else perhaps take on the role of reviewing my patch?

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Fri, 15 Jan 2016 18:32:01 GMT) Full text and rfc822 format available.

Message #76 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org, lekktu <at> gmail.com
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Fri, 15 Jan 2016 20:31:17 +0200
> Date: Fri, 15 Jan 2016 16:18:06 +0000
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, 22025 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > OK, here is the patch.  Do you think I should solicit a review from
> > > somebody else before I commit it to emacs-25?
> 
> > I'd like Juanma to look at it, thanks.
> 
> I asked Juanma back then to review it, but he seems to have disappeared.
> I hope nothing bad has happened to him.
> 
> I do think it would be a good thing for this patch to make it into the
> first pre-test version of Emacs 25.1, to save our pretesters from having
> their .emacs.desktop's becoming incompatible with their main Emacs
> systems.
> 
> Could somebody else perhaps take on the role of reviewing my patch?

If neither Juanma nor anyone else chimes in in a day or two, please
commit this to emacs-25.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Mon, 18 Jan 2016 13:36:02 GMT) Full text and rfc822 format available.

Message #79 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22025 <at> debbugs.gnu.org, lekktu <at> gmail.com
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Mon, 18 Jan 2016 13:37:28 +0000
Hello, Eli.

On Fri, Jan 15, 2016 at 08:31:17PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 15 Jan 2016 16:18:06 +0000
> > Cc: Juanma Barranquero <lekktu <at> gmail.com>, 22025 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

> > > > OK, here is the patch.  Do you think I should solicit a review from
> > > > somebody else before I commit it to emacs-25?

> > > I'd like Juanma to look at it, thanks.

> > I asked Juanma back then to review it, but he seems to have disappeared.
> > I hope nothing bad has happened to him.

> > I do think it would be a good thing for this patch to make it into the
> > first pre-test version of Emacs 25.1, to save our pretesters from having
> > their .emacs.desktop's becoming incompatible with their main Emacs
> > systems.

> > Could somebody else perhaps take on the role of reviewing my patch?

> If neither Juanma nor anyone else chimes in in a day or two, please
> commit this to emacs-25.

Done.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#22025; Package emacs. (Sun, 29 Sep 2019 21:18:01 GMT) Full text and rfc822 format available.

Message #82 received at 22025 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22025 <at> debbugs.gnu.org, lekktu <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#22025: Emacs 25 corrupts Emacs 24 .emacs.desktop.
Date: Sun, 29 Sep 2019 23:17:24 +0200
close 22025 25.1
quit

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Eli.
>
> On Fri, Jan 15, 2016 at 08:31:17PM +0200, Eli Zaretskii wrote:
>> > Date: Fri, 15 Jan 2016 16:18:06 +0000
>> > Cc: Juanma Barranquero <lekktu <at> gmail.com>, 22025 <at> debbugs.gnu.org
>> > From: Alan Mackenzie <acm <at> muc.de>
>
>> > > > OK, here is the patch.  Do you think I should solicit a review from
>> > > > somebody else before I commit it to emacs-25?
>
>> > > I'd like Juanma to look at it, thanks.
>
>> > I asked Juanma back then to review it, but he seems to have disappeared.
>> > I hope nothing bad has happened to him.
>
>> > I do think it would be a good thing for this patch to make it into the
>> > first pre-test version of Emacs 25.1, to save our pretesters from having
>> > their .emacs.desktop's becoming incompatible with their main Emacs
>> > systems.
>
>> > Could somebody else perhaps take on the role of reviewing my patch?
>
>> If neither Juanma nor anyone else chimes in in a day or two, please
>> commit this to emacs-25.
>
> Done.

It seems like the fix for this bug was installed at the time, so I'm
closing this bug report.

commit 20defc5538de705fc6b39d5a754244e6787db162
Author: Alan Mackenzie <acm <at> muc.de>
Date:   Mon Jan 18 13:32:22 2016 +0000

    Desktop: protect users against inadvertant upgrading of desktop file.

Best regards,
Stefan Kangas




bug marked as fixed in version 25.1, send any further explanations to 22025 <at> debbugs.gnu.org and Alan Mackenzie <acm <at> muc.de> Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Sun, 29 Sep 2019 21:18:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 28 Oct 2019 11:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 181 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.