emacs-devel
[Top][All Lists]
Advanced

[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, 12 Nov 2022 12:49:05 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Po Lu [2022-11-10 20:25:03] wrote:

> Kai Ma <justksqsf@gmail.com> writes:
>
>>  On Nov 4, 2022, at 23:09, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>
>>  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`.
>>
>>  It's very unusual to have to do that.
>>
>> Thanks for the pointer, this indeed turned out unnecessary (and dangerous).
>>
>> A tester informed me of a problem in the v3 patch:
>>
>>   safe_call (0, Qns_in_echo_area)
>>
>> is incorrect. The 0 should be 1, or nargs will be -1 for funcall_general.  
>> This will cause an error to be signaled, which explains why 
>> `waiting_for_input` has to be masked.
>>
>> [ I guess we could add an assertion that numargs >= 0 in funcall_general or
>>   somewhere else? ]
>>
>> This patch should be correct even without the ugly `waiting_for_input` hack.
>> I’ve been running patched Emacs for some time without issues.
>>
>> With the current understanding of the bug, I guess the comment line could be
>>   /* Protect against throw-on-input. */
>
> I will install a change using internal_catch_all instead, if Stefan is
> fine with that.

I don't have any objection to any of the patches that were proposed.
My only point was that it looked like we were getting to the point where
we "add hacks upon hacks for lack of understanding".
Once we start doing that it's very important to add as much context in
the form of comments in order to help the poor sod who needs to deal
with the next problem (in the hope that they will get a chance to
actually understand at some point what is the true underlying problem).


        Stefan




reply via email to

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