--- Begin Message ---
|
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 address@hidden
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)
--- End Message ---
--- Begin Message ---
|
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 <address@hidden>:
> Hello.
>
> 2 jul 2013 kl. 19:38 skrev Juanma Barranquero <address@hidden>:
>
>> On Tue, Jul 2, 2013 at 7:34 PM, Jan Djärv <address@hidden> 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.
>
--- End Message ---