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: Fri, 4 Nov 2022 19:04:48 +0800 Message-ID: References: <87leord0ei.fsf@yahoo.com> <87h6zfchpu.fsf@yahoo.com> <394D8618-AF36-44C4-BA64-7AFDFBBDC429@gmail.com> <878rkrcbkx.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=_F2FE0842-C844-4DA8-BCCC-023D3698953F" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30675"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 04 12:06:14 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 1oquWc-0007q6-5P for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Nov 2022 12:06:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oquVs-00051F-7u; Fri, 04 Nov 2022 07:05:28 -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 1oquVe-00050z-59 for emacs-devel@gnu.org; Fri, 04 Nov 2022 07:05:16 -0400 Original-Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oquVX-0002xY-5A for emacs-devel@gnu.org; Fri, 04 Nov 2022 07:05:09 -0400 Original-Received: by mail-pl1-x644.google.com with SMTP id p21so4548222plr.7 for ; Fri, 04 Nov 2022 04:05:06 -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=Cf7qAhibhejOBt0exwkwMqxvlSQdfZL6U0v5ewnn4cc=; b=j3MyCDaed9Zv3tyVG4y7czrH4DVuEO39npYe547uJuecBoRKI0x0ONTAHkysfMDs26 OjV6sL75biCtiKGuoC4mJu0b7PaWNmDM+JGVScJtbhudHBRfszHq5RO/bBwqN3keZ11M P90lEW/uNAzwyQEb6D8jPTxzTTxGOz/th3Sc+6sEixWoshJvIDAM0cswAVjAvOjQl+wN DTIFGEoDiTIULC/HdHbBX+UEcd0fS/N9vwoeHfDuesm6d6wVl5KdGeOGInpoBTL7g/sO H9s9IGlJZUvnXElbh+3TgCJRthj/nowjtZood1T446hVZoILeyUdHXuMTQ0VwN7fp6gz mkOg== 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=Cf7qAhibhejOBt0exwkwMqxvlSQdfZL6U0v5ewnn4cc=; b=GfWQCXN4aqQnWtT8NzLVha06NXyYtzPjinE4avbh6pdnS9cimXHjZRpIJ3E9IlB6wC OjRkCyb0xwylossZyLy+01v0ngB/XmSzpTpZ1jjtD6yJilkeKx3ExUG0UyG21zYNxwz/ 0OZ7wrStfnIZB6GcFzVxz68pgAk91lyXOMTBbpCtBllBmywFmAXEquaLcJqADHBoXmaO 9krQr/xuxELu1C8NtPZ5QBGvMIB0k6rpFkPEMzhSneirOml4LXRRjUXnutxxirEzWQme 6Y9Q8IP1DiTDYZd4ClbS/4opNJ/KewKGOBCeBY+zaKSW/cJ5LPgJRlPxOjHwBTz9pAv6 CMaA== X-Gm-Message-State: ACrzQf2YEy/JgNsGkuCler2P9btp7rS6lyJVmKfyAJC1HQSnaT1mK3Gm dOpnA+5rQRgI3+VD5kJZy7g= X-Google-Smtp-Source: AMsMyM67/aApVMYa50AsOkD/iO/TZ+Hu4MccY5p9Y+V8iQtuBXW0FTxzpm5Wo6M6JhdsByT9sASYrw== X-Received: by 2002:a17:90b:1c11:b0:213:2253:fa7a with SMTP id oc17-20020a17090b1c1100b002132253fa7amr37195329pjb.111.1667559905525; Fri, 04 Nov 2022 04:05:05 -0700 (PDT) Original-Received: from smtpclient.apple (n058153105218.netvigator.com. [58.153.105.218]) by smtp.gmail.com with ESMTPSA id a10-20020a170902b58a00b001886863c6absm783398pls.97.2022.11.04.04.05.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2022 04:05:05 -0700 (PDT) In-Reply-To: <878rkrcbkx.fsf@yahoo.com> X-Mailer: Apple Mail (2.3731.200.110.1.12) Received-SPF: pass client-ip=2607:f8b0:4864:20::644; envelope-from=justksqsf@gmail.com; helo=mail-pl1-x644.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:299120 Archived-At: --Apple-Mail=_F2FE0842-C844-4DA8-BCCC-023D3698953F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 4, 2022, at 17:29, Po Lu wrote: >=20 > Kai Ma > writes: >=20 >> Yes and no. Emacs still responds to new key events, but a previous >> call is stuck and does not return. Presumably in another thread. To = be >> more clear: changing that code to be >>=20 >> static int enter_cnt, leave_cnt; >> enter_cnt++; >> [referenced piece of code] >> leave_cnt++; >> /* (Or just count the return/leave counts of (ns-in-echo-area).) */ >>=20 >> leave_cnt can be less than enter_cnt. I=E2=80=99ve confirmed = re-entrance to >> [firstRectForCharacterRange] leads to the problem. >=20 > I'm going to guess what actually happened is that ns-in-echo-area > signalled. >=20 > What happens if you replace ns-in-echo-area with: >=20 > safe_call (0, Qns_in_echo_area) >=20 > ? Yes, this indeed is related to signals, but it=E2=80=99s not = (ns-in-echo-area) that signals. It seems that there are problems in = nsterm.m regarding waiting_for_input, which caused aborts for me = ([eval.c:signal_or_quit] asserts !waiting_for_input). It=E2=80=99s also = observed that inhibit-quit must be set, or the bug persists. I believe the attached patch fixes this bug, but I don=E2=80=99t know = why Vthrow_on_input is not correctly handled by safe_call.=20 =EF=BF=BC= --Apple-Mail=_F2FE0842-C844-4DA8-BCCC-023D3698953F Content-Type: multipart/mixed; boundary="Apple-Mail=_2D24374F-3377-47AE-B923-332E2788C674" --Apple-Mail=_2D24374F-3377-47AE-B923-332E2788C674 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov = 4, 2022, at 17:29, Po Lu <luangruo@yahoo.com> wrote:

Kai Ma <justksqsf@gmail.com> writes:

Yes and no. = Emacs still responds to new key events, but a previous
call is stuck = and does not return. Presumably in another thread. To be
more clear: = changing that code to be

 static int enter_cnt, = leave_cnt;
 enter_cnt++;
 [referenced piece of = code]
 leave_cnt++;
 /* (Or just count the return/leave = counts of (ns-in-echo-area).) */

leave_cnt can be less than = enter_cnt. I=E2=80=99ve confirmed re-entrance = to
[firstRectForCharacterRange] leads to the = problem.

I'm = going to guess what actually happened is that ns-in-echo-area
signalled.

What = happens if you replace ns-in-echo-area with:

 safe_call (0, = Qns_in_echo_area)

?

Yes, this = indeed is related to signals, but it=E2=80=99s not (ns-in-echo-area) = that signals. It seems that there are problems in nsterm.m regarding = waiting_for_input, which caused aborts for me ([eval.c:signal_or_quit] = asserts !waiting_for_input). It=E2=80=99s also observed that = inhibit-quit must be set, or the bug = persists.

I believe the attached patch fixes = this bug, but I don=E2=80=99t know why Vthrow_on_input is not correctly = handled by = safe_call. 

= --Apple-Mail=_2D24374F-3377-47AE-B923-332E2788C674 Content-Disposition: attachment; filename=fix-ghost-key-v2.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="fix-ghost-key-v2.patch" Content-Transfer-Encoding: 7bit diff --git a/src/lisp.h b/src/lisp.h index eafa241adf..2ba18ec684 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -4603,6 +4603,7 @@ xsignal (Lisp_Object error_symbol, Lisp_Object data) extern Lisp_Object call_debugger (Lisp_Object arg); extern void init_eval_once (void); extern Lisp_Object safe_call (ptrdiff_t, Lisp_Object, ...); +extern Lisp_Object safe_call_inhibit_quit (ptrdiff_t, Lisp_Object, ...); extern Lisp_Object safe_call1 (Lisp_Object, Lisp_Object); extern Lisp_Object safe_call2 (Lisp_Object, Lisp_Object, Lisp_Object); extern void init_eval (void); diff --git a/src/nsterm.m b/src/nsterm.m index 17f40dc7e3..e4b998410d 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -7063,16 +7063,20 @@ - (NSRect)firstRectForCharacterRange: (NSRange)theRange NSRect rect; NSPoint pt; struct window *win; + bool owfi; NSTRACE ("[EmacsView firstRectForCharacterRange:]"); if (NS_KEYLOG) NSLog (@"firstRectForCharRange request"); - if (WINDOWP (echo_area_window) && ! NILP (call0 (intern ("ns-in-echo-area")))) + owfi = waiting_for_input; + waiting_for_input = false; + if (WINDOWP (echo_area_window) && ! NILP (safe_call_inhibit_quit (0, Qns_in_echo_area))) win = XWINDOW (echo_area_window); else win = XWINDOW (FRAME_SELECTED_WINDOW (emacsframe)); + waiting_for_input = owfi; rect.size.width = theRange.length * FRAME_COLUMN_WIDTH (emacsframe); rect.size.height = FRAME_LINE_HEIGHT (emacsframe); @@ -11012,6 +11016,7 @@ Nil means use fullscreen the old (< 10.7) way. The old way works better with DEFSYM (Qcondensed, "condensed"); DEFSYM (Qreverse_italic, "reverse-italic"); DEFSYM (Qexpanded, "expanded"); + DEFSYM (Qns_in_echo_area, "ns-in-echo-area") #ifdef NS_IMPL_COCOA Fprovide (Qcocoa, Qnil); diff --git a/src/xdisp.c b/src/xdisp.c index dd243eca98..af697d0050 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -3041,6 +3041,18 @@ safe_call (ptrdiff_t nargs, Lisp_Object func, ...) return retval; } +Lisp_Object +safe_call_inhibit_quit (ptrdiff_t nargs, Lisp_Object func, ...) +{ + Lisp_Object retval; + va_list ap; + + va_start (ap, func); + retval = safe__call (true, nargs, func, ap); + va_end (ap); + return retval; +} + /* Call function FN with one argument ARG. Return the result, or nil if something went wrong. */ --Apple-Mail=_2D24374F-3377-47AE-B923-332E2788C674 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_2D24374F-3377-47AE-B923-332E2788C674-- --Apple-Mail=_F2FE0842-C844-4DA8-BCCC-023D3698953F--