[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: Stefan Monnier
Subject: Re: [PATCH] On the nasty "ghost key" problem on NS
Date: Sat, 05 Nov 2022 10:40:37 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>>     -  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`.  ]


reply via email to

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