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

[Aaron Jensen]

On Thu, Oct 21, 2021 at 1:36 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> (I feel like I'm repeating myself, but so do you.)

I'm sorry about that. Negotiating meaning over email is tough
sometimes and I don't have as much context as I wish I had, hence my
probing. I appreciate your patience with me.

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

Right, READABLE_EVENTS_FILTER_EVENTS does not (and should not)
indicate that it is only used from input-pending-p. The flag is named
after what it does, not its use case. What its meaning is is
ambiguous, so it is up to us to define what it is. We know what it
means in code today. We know it is only used in one place today and
why it is used there. I posit that it could eventually come to mean
"filter all events specified by while-no-input-ignore-events", but
since we want to take a cautious approach, the above suggestion is to,
rather than provide a boolean flag to enable/disable the new meaning
of READABLE_EVENTS_FILTER_EVENTS we would use a new variable that was
better named for its use case. A user who discovered problems would be
able to set the new variable to nil and get the exact behavior that
they get today. Once we feel comfortable that this approach did not
introduce any problems, we could deprecate/remove
while-no-input-ignore-events. If there is no appetite for renaming the
variable at all, I can go with some other temporary variable, perhaps
readable-events-filter-events-includes-while-no-input-ignore-events?

Thanks,

Aaron