* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
@ 2013-07-02 12:20 Jan Djärv
2013-07-02 13:11 ` martin rudalics
2013-07-02 13:48 ` Juanma Barranquero
0 siblings, 2 replies; 10+ messages in thread
From: Jan Djärv @ 2013-07-02 12:20 UTC (permalink / raw
To: 14765
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@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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 12:20 bug#14765: 24.3.50; desktop-restore-frames on NS does not work Jan Djärv
@ 2013-07-02 13:11 ` martin rudalics
2013-07-02 13:48 ` Juanma Barranquero
1 sibling, 0 replies; 10+ messages in thread
From: martin rudalics @ 2013-07-02 13:11 UTC (permalink / raw
To: Jan Djärv; +Cc: 14765
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 12:20 bug#14765: 24.3.50; desktop-restore-frames on NS does not work Jan Djärv
2013-07-02 13:11 ` martin rudalics
@ 2013-07-02 13:48 ` Juanma Barranquero
2013-07-02 17:34 ` Jan Djärv
1 sibling, 1 reply; 10+ messages in thread
From: Juanma Barranquero @ 2013-07-02 13:48 UTC (permalink / raw
To: Jan Djärv; +Cc: 14765
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>?
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 13:48 ` Juanma Barranquero
@ 2013-07-02 17:34 ` Jan Djärv
2013-07-02 17:38 ` Juanma Barranquero
0 siblings, 1 reply; 10+ messages in thread
From: Jan Djärv @ 2013-07-02 17:34 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 14765
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 17:34 ` Jan Djärv
@ 2013-07-02 17:38 ` Juanma Barranquero
2013-07-02 18:09 ` Jan Djärv
0 siblings, 1 reply; 10+ messages in thread
From: Juanma Barranquero @ 2013-07-02 17:38 UTC (permalink / raw
To: Jan Djärv; +Cc: 14765
On Tue, Jul 2, 2013 at 7:34 PM, Jan Djärv <jan.h.d@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
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 17:38 ` Juanma Barranquero
@ 2013-07-02 18:09 ` Jan Djärv
2013-07-02 18:16 ` Jan Djärv
2013-07-02 18:53 ` Juanma Barranquero
0 siblings, 2 replies; 10+ messages in thread
From: Jan Djärv @ 2013-07-02 18:09 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 14765
Hello.
2 jul 2013 kl. 19:38 skrev Juanma Barranquero <lekktu@gmail.com>:
> On Tue, Jul 2, 2013 at 7:34 PM, Jan Djärv <jan.h.d@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 18:09 ` Jan Djärv
@ 2013-07-02 18:16 ` Jan Djärv
2013-07-02 18:53 ` Juanma Barranquero
1 sibling, 0 replies; 10+ messages in thread
From: Jan Djärv @ 2013-07-02 18:16 UTC (permalink / raw
To: 14765-done
Fixed in trunk.
Jan D.
2 jul 2013 kl. 20:09 skrev Jan Djärv <jan.h.d@swipnet.se>:
> Hello.
>
> 2 jul 2013 kl. 19:38 skrev Juanma Barranquero <lekktu@gmail.com>:
>
>> On Tue, Jul 2, 2013 at 7:34 PM, Jan Djärv <jan.h.d@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.
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 18:09 ` Jan Djärv
2013-07-02 18:16 ` Jan Djärv
@ 2013-07-02 18:53 ` Juanma Barranquero
2013-07-02 18:59 ` Jan Djärv
1 sibling, 1 reply; 10+ messages in thread
From: Juanma Barranquero @ 2013-07-02 18:53 UTC (permalink / raw
To: Jan Djärv; +Cc: 14765
On Tue, Jul 2, 2013 at 8:09 PM, Jan Djärv <jan.h.d@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
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 18:53 ` Juanma Barranquero
@ 2013-07-02 18:59 ` Jan Djärv
2013-07-02 19:00 ` Juanma Barranquero
0 siblings, 1 reply; 10+ messages in thread
From: Jan Djärv @ 2013-07-02 18:59 UTC (permalink / raw
To: Juanma Barranquero; +Cc: 14765
Hello.
2 jul 2013 kl. 20:53 skrev Juanma Barranquero <lekktu@gmail.com>:
> On Tue, Jul 2, 2013 at 8:09 PM, Jan Djärv <jan.h.d@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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#14765: 24.3.50; desktop-restore-frames on NS does not work
2013-07-02 18:59 ` Jan Djärv
@ 2013-07-02 19:00 ` Juanma Barranquero
0 siblings, 0 replies; 10+ messages in thread
From: Juanma Barranquero @ 2013-07-02 19:00 UTC (permalink / raw
To: Jan Djärv; +Cc: 14765
On Tue, Jul 2, 2013 at 8:59 PM, Jan Djärv <jan.h.d@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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-07-02 19:00 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-02 12:20 bug#14765: 24.3.50; desktop-restore-frames on NS does not work Jan Djärv
2013-07-02 13:11 ` martin rudalics
2013-07-02 13:48 ` Juanma Barranquero
2013-07-02 17:34 ` Jan Djärv
2013-07-02 17:38 ` Juanma Barranquero
2013-07-02 18:09 ` Jan Djärv
2013-07-02 18:16 ` Jan Djärv
2013-07-02 18:53 ` Juanma Barranquero
2013-07-02 18:59 ` Jan Djärv
2013-07-02 19:00 ` Juanma Barranquero
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.