On Nov 5, 2022, at 22:40, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
- if (WINDOWP (echo_area_window) && ! NILP (call0 (intern ("ns-in-echo-area"))))
+ was_waiting_for_input = waiting_for_input;
+ waiting_for_input = false;
+ specbind (Qinhibit_quit, Qt);
+ if (WINDOWP (echo_area_window) && ! NILP (safe_call (true, 0, Qns_in_echo_area)))
I'm glad we found a way to make the code work, apparently, but
Here we need a comment explaining why we do this gymnastic of
`safe_call` + `inhibit_quit` + `waiting_for_input`.
That is done all over the place in the NS code.
Then why does it need to be hand-coded here? If it's done all over the place, it should have its own `super_extra_safe_call` function or something, no? I don't really know why, you will have to ask its original authors for
that, but suffice it to say calling Lisp from
firstRectForCharacterRange (and also the menu bar update callbacks)
will otherwise crash upon Fsignal being called.
Yet I don't see anything in `ns-in-echo-area` which would call `signal`. I don't mean to say that we should not protect ourselves from the case where `ns-in-echo-area` calls `signal`, but that the above explanation doesn't seem to explain the problem we're currently facing. [ And `safe_call` should be sufficient to protect ourselves from `signal`. ]
I’m not super familiar with the signal mechanism, but here are some findings. (Assume that `waiting_for_input` is correctly maintained.) On certain occasions (which still remain unclear to me), the `Vthrow_on_input` path in `process_quit_flag` is taken. The curious thing is that `safe_call` does not seem to catch that, and thus the control flow directly moves to somewhere above the Lisp call in `firstRectForCharacterRange`. Is it intentional that `safe_call` does not catch throw_on_input?
(Also a correction: I guessed it could be related to threading at first. No, it’s not. It’s always the main thread.) |