bug#53276: The blink-cursor-mode not work after startup on macOS

[Alan Third <alan@idiocy.org>]

On Sat, Jan 15, 2022 at 03:04:35PM +0800, Po Lu wrote:
> Eason Huang <aqua0210@foxmail.com> writes:
> 
> > When Emacs is started at the first time, the blink-cursor-mode does
> > not work, and the focus needs to be switched to another
> > application, and then switching back again, it will work properly.
> 
> blink-cursor-mode will only start the idle timer that actually blinks
> the cursor if at least one frame is focused, but no FOCUS_IN_EVENT is
> sent until windowDidBecomeKey is called a second time, as emacs_event is
> NULL when windowDidBecomeKey is first called.  This is both on GNUstep
> and macOS.  (Perhaps storing the FOCUS_IN_EVENT into the keyboard buffer
> would be an option.)
> 
> Alan, do you have any idea as to why this is?  I'm afraid I don't really
> understand the NS event loop code.

No, I don't know why it's done this way. There are a number of other
bugs that have the same root cause, where emacs_event is null because
the code is being called outside the run loop and therefore the event
never reaches Emacs.

My assumption is that there is a reason why it's done this way, but I
can't work it out.

I had a look at some of the other terms and they *kind of* work in a
similar fashion, in that there's one function that scoops up all the
events and passes them to Emacs (like ns_read_socket does) but they
differ in that the events are queued up by the system before they're
read in. So given that I wonder if the NS port is just copying that
style from other terms, but it doesn't actually work right.

(I sometimes think it would be nice if we had git history for the NS
port from before it was merged in, because a lot of these design
decisions are ancient and it's unclear why they were made.)
-- 
Alan Third