GNU bug report logs - #14765
24.3.50; desktop-restore-frames on NS does not work

Previous Next

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

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

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 14:20:57 +0200

Hello.

Saving frames on NS (OSX or GnuStep) does not work.
It only restores one frame, the last one created, no matter how many
frames where saved (I tried, two, three and four).
It works on GNU/Linux though.

   Jan D.


In GNU Emacs 24.3.50.1 (x86_64-apple-darwin12.4.0, NS apple-appkit-1187.39)
of 2013-07-02 on zeplin
Bzr revision: 113257 yamaoka <at> jpl.org-20130702103858-pfajmji6yk77armw
Windowing system distributor `Apple', version 10.3.1187
Configured using:
`configure --prefix=/opt/emacs-cvs --without-x --with-ns'

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: sv_SE.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: ObjC/lah

Minor modes in effect:
  desktop-save-mode: t
  delete-selection-mode: t
  icomplete-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
<down-mouse-1> <mouse-1> <escape> x r e p o r t - e 
<tab> <return>

Recent messages:
Loading icomplete...done
Loading desktop...done
Setting up indent for shell type sh
setting up indent stuff
Indentation variables are now local.
Indentation setup for shell type sh
Wrote /Users/jhd/src/emacs/current/.emacs.desktop.lock
Error restoring frame: "Don't know how to interpret display \"\"zeplin.localdomain\"\"" [2 times]
Desktop: 4 buffers restored.
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/Users/jhd/.emacs.d/elpa/magit-20130525.2329/.dir-locals hides /Users/jhd/Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals

Features:
(shadow sort gnus-util mail-extr emacsbug message cl-macs gv format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils make-mode sh-script smie executable vc-bzr
magit-autoloads package desktop cus-start cus-load msb delsel advice
help-fns icomplete cc-langs cl nadvice cl-loaddefs cl-lib cc-mode
cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs time time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel ns-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process ns multi-tty emacs)

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14765 <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 02 Jul 2013 15:11:34 +0200

> Saving frames on NS (OSX or GnuStep) does not work.
> It only restores one frame, the last one created, no matter how many
> frames where saved (I tried, two, three and four).
> It works on GNU/Linux though.
[...]
> Error restoring frame: "Don't know how to interpret display \"\"zeplin.localdomain\"\"" [2 times]

What happens when you set `desktop-restore-in-current-display' to t?

martin

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14765 <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 15:48:12 +0200

On Tue, Jul 2, 2013 at 2:20 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> Saving frames on NS (OSX or GnuStep) does not work.
> It only restores one frame, the last one created, no matter how many
> frames where saved (I tried, two, three and four).

> Error restoring frame: "Don't know how to interpret display \"\"zeplin.localdomain\"\"" [2 times]

With the current code, the first frame is not created, just reused.
For the others, desktop--restore-frames is calling
make-frame-on-display and passing it the expected display and the
saved frame info.

The expected display, assuming that you didn't set
`destop-restore-in-current-display', is the value of the saved frame's
display property (i.e., the result of (cdr (assq 'display config)). In
this case, "zeplin.localdomain".

So the question is, what happens if you do M-: (make-frame-on-display
"zeplin.localdomain") <RET>?

If that works, then it is possible that the make-frame-on-display is
failing because of other frame parameters; please try with just two
frames and show the contents of desktop--saved-states.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14765 <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 19:34:36 +0200

Hello.

2 jul 2013 kl. 15:48 skrev Juanma Barranquero <lekktu <at> gmail.com>:

> On Tue, Jul 2, 2013 at 2:20 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> 
>> Saving frames on NS (OSX or GnuStep) does not work.
>> It only restores one frame, the last one created, no matter how many
>> frames where saved (I tried, two, three and four).
> 
>> Error restoring frame: "Don't know how to interpret display \"\"zeplin.localdomain\"\"" [2 times]
> 
> With the current code, the first frame is not created, just reused.
> For the others, desktop--restore-frames is calling
> make-frame-on-display and passing it the expected display and the
> saved frame info.
> 
> The expected display, assuming that you didn't set
> `destop-restore-in-current-display', is the value of the saved frame's
> display property (i.e., the result of (cdr (assq 'display config)). In
> this case, "zeplin.localdomain".
> 
> So the question is, what happens if you do M-: (make-frame-on-display
> "zeplin.localdomain") <RET>?

I get an error message:

make-frame: Don't know how to interpret display ""zeplin.localhost""

In frame.el there is a check that the display matches entries in display-format-alist.  On NS that only contains "ns".  So there is a mismatch between what NS use for display name and what display-format-alist contains.  I will fix this in one way or another.  NS does not have display names, or multiple displays so any display name should be OK.

The display-format-alist makes no sense.  It is not like we can start a W32 or NS frame on an X-verson of Emacs or have any combination except X on X, W32 on W32 and NS on NS.  It seems like a meaningless check, that just exists to create bugs like this.

	Jan D.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14765 <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 19:38:59 +0200

On Tue, Jul 2, 2013 at 7:34 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> I get an error message:
>
> make-frame: Don't know how to interpret display ""zeplin.localhost""

Aha.

> In frame.el there is a check that the display matches entries in
> display-format-alist.  On NS that only contains "ns".  So there is
> a mismatch between what NS use for display name and what
> display-format-alist contains.  I will fix this in one way or another.
> NS does not have display names, or multiple displays so any
> display name should be OK.

Windows does not have display names either, so w32 functions that must
use or return a display name use "w32". I suggest you do the same and
use "ns" everywhere.

> The display-format-alist makes no sense.  It is not like we can
> start a W32 or NS frame on an X-verson of Emacs or have any
> combination except X on X, W32 on W32 and NS on NS.

There are X Server implementations for Windows. It could be
conceivable to have a Windows Emacs that could open "normal" (w32)
frames and X ones. It's just that nobody has implemented it.

Can we close this bug, then, or there's something more to do?

    J

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14765 <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 20:09:47 +0200

Hello.

2 jul 2013 kl. 19:38 skrev Juanma Barranquero <lekktu <at> gmail.com>:

> On Tue, Jul 2, 2013 at 7:34 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> 
> Windows does not have display names either, so w32 functions that must
> use or return a display name use "w32". I suggest you do the same and
> use "ns" everywhere.

But then a NS user must know that make-frame-on-display must have "ns" as argument.
This is not documented anywhere (nor is the "w32" thing).
I'd rather just accept anything.

> 
>> The display-format-alist makes no sense.  It is not like we can
>> start a W32 or NS frame on an X-verson of Emacs or have any
>> combination except X on X, W32 on W32 and NS on NS.
> 
> There are X Server implementations for Windows. It could be
> conceivable to have a Windows Emacs that could open "normal" (w32)
> frames and X ones. It's just that nobody has implemented it.

There are X server implementations for OSX also, but mixing X and NS (or X and W32) in the same binary is not easy, and AFAIK, nobody has done it for any application.  Not to mention that Emacs itself is very hard to convert to a "multi-GUI" application.  Having a display check for some theoretical future implementation which nobody has asked for and nobody is even considering, is just silly IMHO.

> 
> Can we close this bug, then, or there's something more to do?

I'll close it when I check in a fix.

	Jan D.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: 14765-done <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 20:16:48 +0200

Fixed in trunk.

	Jan D.

2 jul 2013 kl. 20:09 skrev Jan Djärv <jan.h.d <at> swipnet.se>:

> Hello.
> 
> 2 jul 2013 kl. 19:38 skrev Juanma Barranquero <lekktu <at> gmail.com>:
> 
>> On Tue, Jul 2, 2013 at 7:34 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>> 
>> Windows does not have display names either, so w32 functions that must
>> use or return a display name use "w32". I suggest you do the same and
>> use "ns" everywhere.
> 
> But then a NS user must know that make-frame-on-display must have "ns" as argument.
> This is not documented anywhere (nor is the "w32" thing).
> I'd rather just accept anything.
> 
>> 
>>> The display-format-alist makes no sense.  It is not like we can
>>> start a W32 or NS frame on an X-verson of Emacs or have any
>>> combination except X on X, W32 on W32 and NS on NS.
>> 
>> There are X Server implementations for Windows. It could be
>> conceivable to have a Windows Emacs that could open "normal" (w32)
>> frames and X ones. It's just that nobody has implemented it.
> 
> There are X server implementations for OSX also, but mixing X and NS (or X and W32) in the same binary is not easy, and AFAIK, nobody has done it for any application.  Not to mention that Emacs itself is very hard to convert to a "multi-GUI" application.  Having a display check for some theoretical future implementation which nobody has asked for and nobody is even considering, is just silly IMHO.
> 
>> 
>> Can we close this bug, then, or there's something more to do?
> 
> I'll close it when I check in a fix.
> 
> 	Jan D.
> 

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14765 <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 20:53:16 +0200

On Tue, Jul 2, 2013 at 8:09 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> But then a NS user must know that make-frame-on-display must have "ns" as argument.
> This is not documented anywhere (nor is the "w32" thing).

I'd say that's a documentation bug. Certainly is weird to allow
Windows or Mac users to type M-x make-frame-on-display with no clue
whatsoever of what is allowed (or expected) as display name, or what
the consequences are of chosing one name over another.

> I'd rather just accept anything.

Fair enough.

> There are X server implementations for OSX also, but mixing X and NS
> (or X and W32) in the same binary is not easy, and AFAIK, nobody has
> done it for any application.

IIRC, at some not-so-distant point in the past, Emacs didn't accept
tty and GUI frames on the same running instance.

    Juanma

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14765 <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 20:59:11 +0200

Hello.

2 jul 2013 kl. 20:53 skrev Juanma Barranquero <lekktu <at> gmail.com>:

> On Tue, Jul 2, 2013 at 8:09 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:
> 
>> There are X server implementations for OSX also, but mixing X and NS
>> (or X and W32) in the same binary is not easy, and AFAIK, nobody has
>> done it for any application.
> 
> IIRC, at some not-so-distant point in the past, Emacs didn't accept
> tty and GUI frames on the same running instance.

I'm aware of that.  However, I would estimate a "multi-GUI" implementation to be at least an order of magnitude more difficult.  And that is not even before touching any Emacs code, just to get the toolkits to play nice is a huge undertaking.

	Jan D.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14765 <at> debbugs.gnu.org
Subject: Re: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 21:00:49 +0200

On Tue, Jul 2, 2013 at 8:59 PM, Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> I'm aware of that.  However, I would estimate a "multi-GUI" implementation
> to be at least an order of magnitude more difficult.

Agreed.

> just to get the toolkits to play nice is a huge undertaking.

Yes, thinking about the event loop(s) makes my head hurt.

   J

Previous Next

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