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

[Aaron Jensen]

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 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?

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.

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?

Thanks,

Aaron