[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`. ]
Stefan
- Re: [PATCH] On the nasty "ghost key" problem on NS, (continued)
- Re: [PATCH] On the nasty "ghost key" problem on NS, Kai Ma, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Po Lu, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Kai Ma, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Po Lu, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Kai Ma, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Po Lu, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Kai Ma, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Po Lu, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Stefan Monnier, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS, Po Lu, 2022/11/04
- Re: [PATCH] On the nasty "ghost key" problem on NS,
Stefan Monnier <=
- Re: [PATCH] On the nasty "ghost key" problem on NS, Kai Ma, 2022/11/05
- Re: [PATCH] On the nasty "ghost key" problem on NS, Stefan Monnier, 2022/11/05
- Re: [PATCH] On the nasty "ghost key" problem on NS, Po Lu, 2022/11/05
- Re: [PATCH] On the nasty "ghost key" problem on NS, Kai Ma, 2022/11/10
- Re: [PATCH] On the nasty "ghost key" problem on NS, Po Lu, 2022/11/10
- Re: [PATCH] On the nasty "ghost key" problem on NS, Stefan Monnier, 2022/11/12
- Re: [PATCH] On the nasty "ghost key" problem on NS, Eli Zaretskii, 2022/11/04