[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should this package be included into the NS port?
From: |
Alan Third |
Subject: |
Re: Should this package be included into the NS port? |
Date: |
Tue, 29 May 2018 22:42:23 +0100 |
User-agent: |
Mutt/1.9.3 (2018-01-21) |
On Tue, May 29, 2018 at 05:29:09PM -0400, George Plymale II wrote:
> Hi again folks,
>
> The discourse so far regarding this issue has been very interesting. It
> seems there's been a lot of back-and-forth about how to solve this issue
> in the core. I won't reiterate or re-hash all of it here, but suffice it
> to say that it seems this brings some significant difficulties due to
> the way Emacs and the NS machinery cooperate. I'm still wondering if
> perhaps we shouldn't just put the band-aid of osx-pseudo-daemon on the
> problem for now.
>
> I don't want anyone to feel over-burdened with the task of taking on
> this issue or to feel out of their depth, so I'm just putting this on
> the table once more. I talked to Ryan C. Thompson on Github the other
> day; he said he's already signed the FSF paperwork so his package should
> be acceptable into the core with little to no issues on that front.
>
> I think this package will be a significantly easier solution for the
> time being (if incomplete), and it will give us a little more time to
> mull over how to solve the real problem for good.
FWIW I think we can solve this by defining:
(defun ns-make-frame ()
(interactive)
(make-frame-on-display (car (x-display-list))))
in ns-win.el, binding it to ns-new-frame, and then making that event
available everywhere. I’m not sure how to do the last bit. At the
moment it’s defined in nsterm.h; presumably it needs to be defined
somewhere else.
As described elsewhere the menus will be pretty much useless, but the
dock icon menu should be able to create a new frame.
It might be better to use the package until we can sort out the menu
issue. Thoughts?
--
Alan Third
- Re: Should this package be included into the NS port?, (continued)