Subject: bug#25265: [PATCH] Rework NS event handling (bug#25265)

From: Alan Third <[email-masked]>
Date: Sun, 1 Jan 2017 15:03:52 +0000

On Sat, Dec 31, 2016 at 04:09:30PM +0000, Alan Third wrote:
> * src/nsterm.m (unwind_apploopnr): Remove.
> (ns_read_socket): Remove references to apploopnr.  Make processing the
> NS event loop conditional on being in the main thread.
> (ns_select): Remove references to apploopnr.  Remove all fd_handler
> related stuff.  Check if there are events waiting on the NS event
> queue rather than running the event loop.  Remove unused variables and
> code.
> (fd_handler): Remove.
> (ns_term_init): Remove creation of fd_handler thread.
> (hold_event, EmacsApp:sendEvent, EmacsView:mouseMoved,
> EmacsView:windowDidExpose): Remove send_appdefined.
> (ns_send_appdefined): Always check the event queue for
> applicationDefined events rather than relying on send_appdefined var.
> * src/nsterm.h: Remove reference to fd_handler method.

OK, I’m running into performance bugs with this almost straight away.

It all looks OK until I start flyspell-mode. Then it appears that
redisplay is only called every two or three keypresses. It looks like
Emacs is still going fine, though, as messages to the modeline appear,
even if the action isn’t immediately displayed in the buffer.

For example, I open up an org file and start flyspell-mode, then I hit
the down arrow which should take me to a heading but the cursor
doesn’t move. Then I hit TAB, and I get a message in the modeline
telling me that the section associated with the heading has been
expanded, but the buffer is still displayed with the cursor on the
previous line and the section not expanded. Finally I hit the down
arrow again and the buffer updates to display the expanded section and
the cursor where I’d expect it.

emacsclient runs with a delay, which I guess corresponds to the
timeout on the NS event queue check.

I’m not at all sure how to fix these problems.

One option I thought about is to wrap the fd’s in ns_select with
NSFileHandle, which should then mean we could look for notifications
on the NS event queue, and emulate select that way. Unfortunately as
far as I can see NSFileHandle only provides an event for ‘data
available for reading’, and it looks like we’d need to be able to spot
write availability too.

(See under Notifications:
https://developer.apple.com/reference/foundation/nsfilehandle)
-- 
Alan Third