Re: Should this package be included into the NS port?

[Alan Third]

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