From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: input-pending-p after make-frame-visible Date: Thu, 21 Oct 2021 20:36:30 +0300 Message-ID: <83lf2m8eld.fsf@gnu.org> References: <6c69780538e1957d1002@heytings.org> <322f50be-0de1-c818-819d-6ecb400de928@gmx.at> <03ab7a19-6616-445c-cdcf-588fb30a514a@gmx.at> <3205a073-a6ca-b9a5-3834-929025b70b7b@gmx.at> <83wnm7absp.fsf@gnu.org> <83wnm68pc5.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25293"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, alan@idiocy.org, gregory@heytings.org, mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org To: Aaron Jensen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 21 19:37:45 2021 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 1mdc0f-0006O4-Qy for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Oct 2021 19:37:45 +0200 Original-Received: from localhost ([::1]:60090 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mdc0e-0001uV-Ao for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Oct 2021 13:37:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35458) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mdbzd-0001Ad-W4 for emacs-devel@gnu.org; Thu, 21 Oct 2021 13:36:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58024) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mdbzZ-0007MB-Al; Thu, 21 Oct 2021 13:36:37 -0400 Original-Received: from [87.69.77.57] (port=3632 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mdbzX-0007Iv-2G; Thu, 21 Oct 2021 13:36:37 -0400 In-Reply-To: (message from Aaron Jensen on Thu, 21 Oct 2021 10:07:28 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:277524 Archived-At: > From: Aaron Jensen > Date: Thu, 21 Oct 2021 10:07:28 -0400 > Cc: YAMAMOTO Mitsuharu , martin rudalics , > Alan Third , Gregory Heytings , emacs-devel@gnu.org > > On Thu, Oct 21, 2021 at 9:44 AM Eli Zaretskii wrote: > > > > > On Thu, Oct 21, 2021 at 7:25 AM Aaron Jensen wrote: > > > > > > > It does make me wonder if we should rename > > > while-no-input-ignore-events to something like input-ignore-events or > > > non-input-events. Thoughts? > > > > I don't see why: the list is still used the same as before. Renaming > > a variable is a PITA, so it should be reserved to when we have very > > good reasons, or shortly after the variable was introduced, which > > isn't the case here. > > The variable name is while-no-input-ignore-events, which implies that > it is related to while-no-input alone. In any version of the change I > am proposing, that list would also be used to ignore events within > input-pending-p, which is not while-no-input. One may find it > surprising that while-no-input-ignore-events is respected by > input-pending-p, so it seemed worth considering a name change. I'd > rather not undertake a PITA, but at the same time I find it helpful > when the names of variables are not misleading. I still don't think this justifies renaming. Yes, it would have been better if we used a different name, but that ship has sailed, and the new uses aren't far enough from the old ones to justify the pain of renaming. (I feel like I'm repeating myself, but so do you.) > > I have no problem with fixing stuff inside input-pending-p. My > > problem is that your fix is not in input-pending-p, it is in a general > > function called from many places. So its effects are much more > > general than on input-pending-p alone. And my concern is that the > > change which you want to make will some day affect code unrelated to > > input-pending-p, with no one the wiser. > > I'm not trying to be difficult, but I just want to make sure that I am > not missing something. It seems to me that the *only* way that my > change would adversely affect anything other than input-pending-p is > if someone used the READABLE_EVENTS_FILTER_EVENTS flag in the future > without knowing what it does (and/or assuming that it does what it > used to do, which is filter only focus in and focus out). Is that what > you see as well? Yes. > Also, there have already been several changes to readable_events that > were intended to only affect input-pending-p because they were guarded > by READABLE_EVENTS_FILTER_EVENTS (or its predecessor, the > filter_events) flag, so we are choosing now to be more cautious than > we were, which is fine, again, just want to make sure I'm > understanding the reasoning. Yes. > Here's another proposal (not code yet, hopefully the explanation is enough): > > Introduce a new variable, non-input-events that is initialized to the > same list that while-no-input-ignore-events is > In readable_events: Use non-input-events if it is non-nil rather than > focus in/out when READABLE_EVENTS_FILTER_EVENTS is set. Revert to the > old behavior if it is nil. > In while-no-input: Use non-input-events if it is non-nil and > while-no-input-ignore-events if it is not (alternatively, respect both > lists) > Deprecate while-no-input-ignore-events encouraging use of > non-input-events instead > Update documentation in both input-pending-p and while-no-input to > reference non-input-events > > How does that seem? How is this different from your original proposal, and how does this address my concerns, which you described above and I just confirmed? My concern is precisely that using READABLE_EVENTS_FILTER_EVENTS does NOT tell that this flag is supposed to be used only from input-pending-p, it just tells that the events are somehow filtered. But I'm again repeating myself.