[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] On the nasty "ghost key" problem on NS

From: Kai Ma
Subject: Re: [PATCH] On the nasty "ghost key" problem on NS
Date: Sat, 5 Nov 2022 23:26:35 +0800

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.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]