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

[Eli Zaretskii <eliz@gnu.org>]

> From: Nick Helm <nick@tenpoint.co.nz>
> Date: Wed, 23 May 2018 17:11:35 +1200
> 
> > In an ideal world (and I believe the Mac port has gone this way) we
> > would put the NSApp run loop in one thread, and Emacs lisp in another
> > and let them communicate with each other asynchronously. This wouldn’t
> > solve everything, but it would make some of our problems easier.

FWIW, that's what the w32 port does.

> > We can’t easily do that, though, as the inter‐thread communication
> > systems provided in Objective‐C are either a pain to implement with
> > complex types like Lisp_Object, or aren’t compatible with GCC and/or
> > GNUstep (Grand Central Dispatch).

Why do you need to have the communications between the threads be in
terms of Lisp objects?  In the w32 port, they communicate in C
objects, and the communications pipe is the read_socket_hook.  So in a
nutshell, the GUI event thread sends input to the Lisp interpreter as
if it was the other end of a socket through which window-system
events, including keyboard, mouse, and everything else, are coming.

> Putting emacsclient aside again, Emacs as a process (the Lisp loop) is
> intrinsically linked to the concept of a Lisp frame, right? In other
> words, no Lisp frame, no Emacs.

No, that's not true.  Why did you think that?

> And, I guess, how does emacsclient beat this one-frame-must-exist
> limitation – does it maintain some kind of fake frame that it hides from
> the windowing system?

That's exactly why your notion of frame-centric Emacs is inaccurate.