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

[Alan Third]

On Sat, Dec 31, 2016 at 06:25:58PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 31 Dec 2016 16:09:30 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: charles@aurox.ch, 25265@debbugs.gnu.org
> > 
> > Here we go. This seems to work. It turns out there are trade‐offs
> > between the GUI and network performance. If I remove
> > NSApp:nextEventMatchingMask from ns_select, eww loads web pages
> > *significantly* faster, but the scrollbars become effectively
> > unusable.
> 
> Wow, thanks a lot!
> 
> I cannot review the patch, as I don't really understand the details.
> So I suggest to push this and see if users report bugs.

I forgot to say before, I think there may be slightly more lag then
before when using the scroll bars. I don’t really use them so I don’t
know if people will be bothered by it. With NSTrace turned on I can
actually crash Emacs by waving the scroll bars about, but I can’t with
NSTrace off. Everything else seems fast enough. If I push it I suppose
we’ll find out soon enough if it’s acceptable.

> (I presume you have run all the tests, including those in
> test/src/thread-tests.el and those posted in the few recent
> discussions related to thread-related problems.  If not, I very much
> recommend that you do that, to see if the new code passes these
> "entry-level" tests.)

I hadn’t, but I have now. Make check reports 3 unexpected results as
usual, and the log for thread-tests.el shows 27/27 passed.

I tried this from one of the other threads (I’ve not looked through
them completely yet):

(dotimes (x 10) (make-thread (lambda ()
                               (let ((n (random 10)))
                                 (with-current-buffer "z"
                                   (sleep-for n)
                                   (insert (format "Foo:%d\n" n)))))))

and it seems to do what it’s supposed to do.
-- 
Alan Third