bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Stefan Guath]

VERSION:
GNU Emacs 24.3.91.1 (x86_64-apple-darwin13.2.0, NS apple-appkit-1265.20) of 2014-05-23 on angelofdeaths-MacBook-Air.local

TO REPRODUCE BUG:

In OS X 10.9.3:
1) Create a .emacs file with only one expression:
    (desktop-save-mode)
2) Start emacs in graphical mode (i.e. double-click on Emacs.app icon).
3) Quit emacs, and answer "y" on question "Save desktop? (y or n)". The file .emacs.desktop is now created.
4) Run 'emacs -nw' in terminal.
5) Despite the '-nw' option, Emacs is now opened in graphical mode in a new non-terminal window.

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Juanma Barranquero]

On Wed, Jun 4, 2014 at 8:34 PM, Stefan Guath <stefan@automata.se> wrote:

> TO REPRODUCE BUG:

Likely related to framesets, but just to be sure

> 1) Create a .emacs file with only one expression:
>     (desktop-save-mode)

Add (setq desktop-restore-frames nil) to your .emacs.

    J

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Stefan Guath]

Yes, adding (setq desktop-restore-frames nil) is a work-around for this bug (#17693) and also bug #17692. But the user shouldn't have to use these kind of work-arounds. A single (desktop-save-mode) should be sufficient and just work out of the box.

/Stefan Guath

On 4 jun 2014, at 23:18, Juanma Barranquero <lekktu@gmail.com> wrote:

> On Wed, Jun 4, 2014 at 8:34 PM, Stefan Guath <stefan@automata.se> wrote:
> 
>> TO REPRODUCE BUG:
> 
> Likely related to framesets, but just to be sure
> 
>> 1) Create a .emacs file with only one expression:
>>    (desktop-save-mode)
> 
> Add (setq desktop-restore-frames nil) to your .emacs.
> 
>    J

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Juanma Barranquero]

> Yes, adding (setq desktop-restore-frames nil) is a work-around for this bug (#17693) and also bug #17692. But the user shouldn't have to use these kind of work-arounds.

I wasn't suggesting it as a workaround, only as a way to determine if
it was a frameset-related bug.

    J

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Stefan Guath]

You're of course right. Sorry, didn't mean to sound rude. On the contrary, you're doing an amazing work - many thanks!

On 5 jun 2014, at 09:02, Juanma Barranquero <lekktu@gmail.com> wrote:

>> Yes, adding (setq desktop-restore-frames nil) is a work-around for this bug (#17693) and also bug #17692. But the user shouldn't have to use these kind of work-arounds.
> 
> I wasn't suggesting it as a workaround, only as a way to determine if
> it was a frameset-related bug.
> 
>    J

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Juanma Barranquero]

> Sorry, didn't mean to sound rude.

Don't worry, it's just that I'm a bit busy right now. I have four
frameset-related bugs pending, and hope to have time to tackle them
this weekend.

    J

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Glenn Morris]

I was going to suggest checking the value of initial-window-system
before restoring graphical frames. But it is also nil for emacs --daemon.
Humph. Maybe check (or initial-window-system (daemonp)) ?
Perhaps there should be some option that defaults to that value,
so that people can override it?

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Glenn Morris]

An even more problematic version of this is that now

emacs --daemon

can create a bunch of graphical frames at startup, if you have
desktop-save-mode enabled in .emacs and a saved desktop.

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Glenn Morris]

Version: 24.3.93

I applied a simple workaround. Hopefully good enough for now at least.

--- a/lisp/desktop.el	2014-07-03 23:48:24 +0000
+++ b/lisp/desktop.el	2014-07-16 04:28:42 +0000
@@ -1516,8 +1516,15 @@
         (setq command-line-args (delete key command-line-args))
         (desktop-save-mode 0)))
     (when desktop-save-mode
-      (desktop-read)
-      (setq inhibit-startup-screen t))))
+      ;; People don't expect emacs -nw, or --daemon,
+      ;; to create graphical frames (bug#17693).
+      ;; TODO perhaps there should be a separate value
+      ;; for desktop-restore-frames to control this startup behavior?
+      (let ((desktop-restore-frames (and desktop-restore-frames
+                                         initial-window-system
+                                         (not (daemonp)))))
+        (desktop-read)
+        (setq inhibit-startup-screen t)))))
 

bug#17693: This bug is not resolved.

[Jordon Biondo]

This problem is not resolved.

The implemented solution only solves the issue on startup, if after start up, you use `desktop-change-dir` to change to a non ‘-nw’ desktop file from a ‘-nw’ instance of emacs, a graphical frame will be opened. Not only that, but the frame cannot be interacted with, it does not receive any key inputs, and thus requires me to kill the emacs process.

Reproduce with:

1. Start a graphical emacs session with -q
2. Open a single file
3. Use desktop-save to save to a directory of your choice.
4. Close emacs
5. start a -nw emacs session with -q
6. run `desktop-change-dir` to load your saved desktop file
7. A graphical frame will be opened that you cannot interact with.

Note: I am on OS X with the latest dev branch.

bug#17693: This bug is not resolved.

[Jordon Biondo]

This can be resolved by setting `desktop-restore-in-current-display` to `t` prior to loading the desktop, but I don’t believe this should be required. Is there ever a reason someone would want a graphical frame to open from a instance of emacs started with -nw? I would imagine not.

bug#17693: This bug is not resolved.

[Eli Zaretskii]

> From: Jordon Biondo <jordonbiondo@gmail.com>
> Date: Wed, 8 Apr 2015 11:10:51 -0400
> 
> This can be resolved by setting `desktop-restore-in-current-display` to `t` prior to loading the desktop, but I don’t believe this should be required. Is there ever a reason someone would want a graphical frame to open from a instance of emacs started with -nw? I would imagine not.

As of today's emacs-25 branch, I cannot reproduce this bug: when I
start "emacs -nw" from a directory with a .emacs.desktop file that was
recorded by a GUI session, I get a single frame with all the buffers
saved in the desktop file.

Can anyone still reproduce the problem?  If so, please provide the
details, including the build and the OS where you see that.  Also,
please try forcing desktop-restore-frames to nil, and tell if doing
so eliminates the problem.

Thanks.

bug#17693: PATCH

[Jun Hao]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

Hi,

Please see the simple patch in the attachment. I can still repro this
issue with latest dev branch. I think the original workaround is not
working since the repro step is using -q which doesn't set
after-init-hook. Let me know if this fix the issue

-- 
Thanks - Jun

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-desktop.el-Disable-restore-frameset-if-in-non-g.patch --]
[-- Type: text/x-patch, Size: 1778 bytes --]

From 4fce83e29ef772b61be276cdaf3e7b12088b417c Mon Sep 17 00:00:00 2001
From: Jun Hao <jun_hao@aol.com>
Date: Fri, 20 May 2016 00:05:25 +0800
Subject: [PATCH] * lisp/desktop.el: Disable restore frameset if in non-graphic
 display.

Fixes: debbugs:17693
---
 lisp/desktop.el | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/lisp/desktop.el b/lisp/desktop.el
index 822db05..dba3277 100644
--- a/lisp/desktop.el
+++ b/lisp/desktop.el
@@ -1163,7 +1163,7 @@ This function also sets `desktop-dirname' to nil."
   "Restore the state of a set of frames.
 This function depends on the value of `desktop-saved-frameset'
 being set (usually, by reading it from the desktop)."
-  (when (desktop-restoring-frameset-p)
+  (when (and (display-graphic-p) (desktop-restoring-frameset-p))
     (frameset-restore desktop-saved-frameset
 		      :reuse-frames (eq desktop-restore-reuses-frames t)
 		      :cleanup-frames (not (eq desktop-restore-reuses-frames 'keep))
@@ -1634,15 +1634,8 @@ If there are no buffers left to create, kill the timer."
         (setq command-line-args (delete key command-line-args))
         (desktop-save-mode 0)))
     (when desktop-save-mode
-      ;; People don't expect emacs -nw, or --daemon,
-      ;; to create graphical frames (bug#17693).
-      ;; TODO perhaps there should be a separate value
-      ;; for desktop-restore-frames to control this startup behavior?
-      (let ((desktop-restore-frames (and desktop-restore-frames
-                                         initial-window-system
-                                         (not (daemonp)))))
-        (desktop-read)
-        (setq inhibit-startup-screen t)))))
+      (desktop-read)
+      (setq inhibit-startup-screen t))))
 
 (provide 'desktop)
 
-- 
2.8.2

bug#17693: 24.3.91.1; desktop-save-mode disables option -nw

[Paul Eggert]

I installed Jun Hao's patch into emacs-25 and am marking Bug#17693 as done. Thanks!