[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan Djärv
Subject: bug#14765: 24.3.50; desktop-restore-frames on NS does not work
Date: Tue, 2 Jul 2013 19:34:36 +0200


2 jul 2013 kl. 15:48 skrev Juanma Barranquero <address@hidden>:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]