Re: input-pending-p after make-frame-visible

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 21 Oct 2021 10:07:28 -0400
> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, martin rudalics 
> <rudalics@gmx.at>, 
>       Alan Third <alan@idiocy.org>, Gregory Heytings <gregory@heytings.org>, 
> emacs-devel@gnu.org
> 
> On Thu, Oct 21, 2021 at 9:44 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > On Thu, Oct 21, 2021 at 7:25 AM Aaron Jensen <aaronjensen@gmail.com> 
> > > 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.