bug#14765: 24.3.50; desktop-restore-frames on NS does not work

[Jan Djärv]

Hello.

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

> On Tue, Jul 2, 2013 at 2:20 PM, Jan Djärv <jan.h.d@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.