From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Kai Ma Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] On the nasty "ghost key" problem on NS Date: Sat, 5 Nov 2022 23:26:35 +0800 Message-ID: <73CA0A70-2D98-4BC9-B474-2D69373A245A@gmail.com> References: <87leord0ei.fsf@yahoo.com> <87h6zfchpu.fsf@yahoo.com> <394D8618-AF36-44C4-BA64-7AFDFBBDC429@gmail.com> <878rkrcbkx.fsf@yahoo.com> <87sfizaria.fsf@yahoo.com> <87k04ac3s6.fsf@yahoo.com> <87cza2b59l.fsf@yahoo.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_5434113C-FF9C-4C54-A909-9A15FDBAEAFD" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22994"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 05 16:27:43 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1orL5D-0005mq-OR for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Nov 2022 16:27:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orL4S-0005R3-0F; Sat, 05 Nov 2022 11:26:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orL4Q-0005Qf-DU for emacs-devel@gnu.org; Sat, 05 Nov 2022 11:26:54 -0400 Original-Received: from mail-pf1-x442.google.com ([2607:f8b0:4864:20::442]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1orL4O-0000pB-I3 for emacs-devel@gnu.org; Sat, 05 Nov 2022 11:26:54 -0400 Original-Received: by mail-pf1-x442.google.com with SMTP id m6so6997565pfb.0 for ; Sat, 05 Nov 2022 08:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=efNi2qoaPs2BJMIo7y9hfLb47CsrVWixZdDFR2xrRqE=; b=iwOD5TIJvb+YODjX8HIkUrZYvA0ZqoeOlKJ52AIWNMcIFokC0N5M1IL2F47BV8mdfW xYBKDFcFQiOHGK3OMHtZTrKGX0GYoS/nELjEqdkQpiJqCjkyKkvrY2Zd3U6mRzfg4UBk l6lnBwXH9vgrjwK0yRoh2JSneIVYlARUJlXQnfX9unhf6maNzcb2Es+gqNNyOboqHPRv BroprM7fDfnoAa8qYXuqHo9A2NQdec5SePqViwvwNnaaUGTCKJYDWcYBwleVi2FYDu3b 2fcR9snHCfuoV15+2feadFt/+FK803hO9ZmqkSNBNc5U3TY8HmdTr5cMZZGC4HKS8x2N PTJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=efNi2qoaPs2BJMIo7y9hfLb47CsrVWixZdDFR2xrRqE=; b=5hylhUWiWAsvOcX5hwvUU/pi0q2BMgfn0SXs+FfLYpaWM8si3BwNKWfFefm7wLLPrj GODD8ikUj+wUETCEg3iWMNeEUudnwYELnM8EYvubqa/aRKzEHF3E3NkqHdtu/BG+1CnU SPT+9AOEO5NX7bZ+vZ12bhSEGw9OVRRYZLNlbmsDkO88/YmIw2kQhR8G0qoKnsVKtPgG mMaLh/70gW5vARM3tcIbvjwUHkpwo4/etMzXgo42ynCUtIyIQIodtB38zCx65REs1PFO lP6c4fRYGAsjNdzVelzKp6JuRMkd5elR25gq9RUyiDGlHbPAYMTOj1kVAUv302nYwfR0 CLsg== X-Gm-Message-State: ACrzQf2+kCQGFdwjApGrczvJF30gAiBKRemNEJsZ95ld8q7TQ1TlIgUE ooojJgkXsgWrGquBFjkd+KI= X-Google-Smtp-Source: AMsMyM6j5Ep1wp42mHuDycr5eGJPSezWe6L2/Zwegk4980NoLIDWEE7tMHIGe1bl+y+xca5G/gNWsw== X-Received: by 2002:a63:1316:0:b0:46f:7e1c:2bb7 with SMTP id i22-20020a631316000000b0046f7e1c2bb7mr505571pgl.368.1667662010317; Sat, 05 Nov 2022 08:26:50 -0700 (PDT) Original-Received: from smtpclient.apple ([2404:c800:922f:9b7:9c9d:d6ff:fe8d:79d0]) by smtp.gmail.com with ESMTPSA id e15-20020a170902784f00b00178acc7ef16sm1789790pln.253.2022.11.05.08.26.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Nov 2022 08:26:49 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3731.200.110.1.12) Received-SPF: pass client-ip=2607:f8b0:4864:20::442; envelope-from=justksqsf@gmail.com; helo=mail-pf1-x442.google.com X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299212 Archived-At: --Apple-Mail=_5434113C-FF9C-4C54-A909-9A15FDBAEAFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 5, 2022, at 22:40, Stefan Monnier = wrote: >=20 >>> - if (WINDOWP (echo_area_window) && ! NILP (call0 (intern = ("ns-in-echo-area")))) >>> + was_waiting_for_input =3D waiting_for_input; >>> + waiting_for_input =3D false; >>> + specbind (Qinhibit_quit, Qt); >>> + if (WINDOWP (echo_area_window) && ! NILP (safe_call (true, 0, = Qns_in_echo_area))) >>>=20 >>> 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`. >>=20 >> That is done all over the place in the NS code. >=20 > 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? >=20 >> 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. >=20 > 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=E2=80=99m 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=E2=80=99s not. It=E2=80=99s always the main thread.)= --Apple-Mail=_5434113C-FF9C-4C54-A909-9A15FDBAEAFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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 =3D waiting_for_input;
=    +  waiting_for_input =3D 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=E2=80=99m 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=E2=80=99s not. It=E2=80=99s always the main = thread.)
= --Apple-Mail=_5434113C-FF9C-4C54-A909-9A15FDBAEAFD--