From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] On the nasty "ghost key" problem on NS Date: Fri, 04 Nov 2022 11:09:53 -0400 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7385"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Kai Ma , 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 16:10:57 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 1oqyLQ-0001fx-Nn for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Nov 2022 16:10:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqyKb-0001jh-92; Fri, 04 Nov 2022 11:10:05 -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 1oqyKY-0001jX-J9 for emacs-devel@gnu.org; Fri, 04 Nov 2022 11:10:02 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqyKW-00084F-A3 for emacs-devel@gnu.org; Fri, 04 Nov 2022 11:10:02 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D7DF3100197; Fri, 4 Nov 2022 11:09:56 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2E82C1000FB; Fri, 4 Nov 2022 11:09:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1667574595; bh=nEX9Bygsg15xEjmW2aN9J35oWoBFC3tmgc46uA9Om6c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oJxDx751JJWN7JKPnh590hRHWgTcrkPo9o8SJmqIFAh4oZOHbWOb2+PD6x/JmzhdX DBfLk7DU+falHbRh2T+o70cdaB7bReHlmmLS9pjVECkioA6vbLS6GofJ5nHMH7e76c 2owP4dLURTKJVed/AL8Ndro0NsFNbaLa1WdpWEeHP9yi04gWfGCiUe63pbmVKJUUUr vSEEKP+EGZQVgbxaTtLbqmworqxd1RU7t9iZctZQlPXHgnS/Kf9An7pkNOy0r4J8XV 6WL9SFhWyZi/kobEwGf1WF94rVYA9aI5B4z1ym8EujsIG6Rh8dzOCv8fTsSvrt96gR BoSanHPjc6Cig== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0B3121204F1; Fri, 4 Nov 2022 11:09:55 -0400 (EDT) In-Reply-To: <87k04ac3s6.fsf@yahoo.com> (Po Lu's message of "Fri, 04 Nov 2022 20:17:29 +0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:299136 Archived-At: Po Lu [2022-11-04 20:17:29] wrote: > Kai Ma writes: >> Either safe_call alone or safe_call+block_input does not fix the bug. > Okay, I see. > Would people on NS run this patch for a while and ack? I don't see any > adverse affects on GNUstep. Just a comment from someone who's rather unfamiliar with the way input methods work in Emacs (well, I use `TeX`, but that's about it), and even more so for the NS code in general: diff --git a/src/nsterm.m b/src/nsterm.m index 17f40dc7e3..0788442b98 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -7063,16 +7063,23 @@ - (NSRect)firstRectForCharacterRange: (NSRange)theRange NSRect rect; NSPoint pt; struct window *win; + bool was_waiting_for_input; + specpdl_ref count = SPECPDL_INDEX (); NSTRACE ("[EmacsView firstRectForCharacterRange:]"); if (NS_KEYLOG) NSLog (@"firstRectForCharRange request"); - 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`. It's very unusual to have to do that. win = XWINDOW (echo_area_window); else win = XWINDOW (FRAME_SELECTED_WINDOW (emacsframe)); + unbind_to (count, Qnil); + waiting_for_input = was_waiting_for_input; The `unbind_to` suggests that non-local exits are still possible, but if so, we will sometimes not restore `waiting_for_input`. So a comment here would be welcome explaining either that non-local exits aren't possible, or why it's OK not to restore `waiting_for_input`. Or maybe change the code to use an unwind_protect to reliably restore `waiting_for_input` so we don't have to worry about it? + DEFSYM (Qns_in_echo_area, "ns-in-echo-area"); Thanks :-) Now for the other part of my comment: (defun ns-in-echo-area () "Whether, for purposes of inserting working composition text, the minibuffer is currently being used." (or isearch-mode (and cursor-in-echo-area (current-message)) ;; Overlay strings are not shown in some cases. (get-char-property (point) 'invisible) (and (not (bobp)) (or (and (get-char-property (point) 'display) (eq (get-char-property (1- (point)) 'display) (get-char-property (point) 'display))) (and (get-char-property (point) 'composition) (eq (get-char-property (1- (point)) 'composition) (get-char-property (point) 'composition))))))) In which sense does (get-char-property (point) 'invisible), or the big (and ...) below, indicate that "the minibuffer is currently being used"? Could someone clarify this code? Maybe all it takes is to change the docstring, I don't know, but as it stands it looks quite odd. Stefan