> On Nov 4, 2022, at 17:29, Po Lu wrote: > > Kai Ma > writes: > >> Yes and no. Emacs still responds to new key events, but a previous >> call is stuck and does not return. Presumably in another thread. To be >> more clear: changing that code to be >> >> static int enter_cnt, leave_cnt; >> enter_cnt++; >> [referenced piece of code] >> leave_cnt++; >> /* (Or just count the return/leave counts of (ns-in-echo-area).) */ >> >> leave_cnt can be less than enter_cnt. I’ve confirmed re-entrance to >> [firstRectForCharacterRange] leads to the problem. > > I'm going to guess what actually happened is that ns-in-echo-area > signalled. > > What happens if you replace ns-in-echo-area with: > > safe_call (0, Qns_in_echo_area) > > ? Yes, this indeed is related to signals, but it’s not (ns-in-echo-area) that signals. It seems that there are problems in nsterm.m regarding waiting_for_input, which caused aborts for me ([eval.c:signal_or_quit] asserts !waiting_for_input). It’s also observed that inhibit-quit must be set, or the bug persists. I believe the attached patch fixes this bug, but I don’t know why Vthrow_on_input is not correctly handled by safe_call.