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

[Nick Helm]

On Sat, 19 May 2018 at 22:33:29 +1200, Alan Third wrote:

> FWIW, the NSApp loop does keep running, but it’s embedded in ns_select
> and ns_read_socket. We can, in theory, create a new frame directly,
> but it needs to run through Emacs first.
>
> The fundamental issue in the NS port is that we have two bosses: the
> NSApp run loop, and Emacs lisp, and we need to mediate between them.
>
> A standard Cocoa app responds to events from the NSApp loop, and
> that’s pretty much it. As I understand it you can make a complete app
> without very much work this way. The NSApp loop is the boss.
>
> Emacs’ architecture expects everything to go through lisp and it makes
> decisions on what we do with our GUI. Emacs lisp is the boss.
>
> We can’t react directly to NS events like a normal NS app. We get
> input from the NSApp loop and send it to lisp. Lisp might tell us to
> do something any time. We also need to know how Emacs expects to do
> things (the GUI code was originally written for a completely different
> platform after all) and then try and make Cocoa/GNUstep handle it
> correctly.
>
> 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.
>
> 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).
>
> Additionally I think we sometimes have workarounds fixing workarounds
> fixing hacks, all written by different people, and the simplest
> solution is to strip it right back to the basics. I have a feeling the
> menus fall somewhat into this category, and the drag‐n‐drop stuff
> definitely does.

Thanks for the great explanations. I think we should add something like
this to the head of nsterm.m.

I have more questions though (apologies in advance if they're
ill-informed or I've missed something obvious).

With all the to-and-fro of control between the Lisp and NSApp loops, why
don't we see more event collisions (or race conditions or whatever
competing events are called) like we saw recently with the Help menu
bug? Redisplay, for example, must be diabolical.

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. So why does it matter whether that last
frame is on a tty or GUI? 

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?

Thanks again.