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

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Wed, 20 Oct 2021 16:00:12 -0400
> Cc: martin rudalics <rudalics@gmx.at>, Alan Third <alan@idiocy.org>, 
>       Gregory Heytings <gregory@heytings.org>, emacs-devel@gnu.org, 
>       YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> Got it, so I guess the question is, what is the expected behavior of
> readable_events when READABLE_EVENTS_FILTER_EVENTS is set?

Yes, and the problem is, we don't really know the answer.  Someone at
some point made it ignore some events, and also made it conditional on
whether toolkit scrollbars are or aren't using.  We don't understand
why, and we now want to add more ignored events to the list, which
will change the (partially unknown) behavior even more.

> Would adding another flag like
> READABLE_EVENTS_FILTER_WHILE_NO_INPUT_IGNORE_EVENTS make it more clear
> exactly what it is doing?

A new flag might be a good idea, indeed, but (a) I'd need to see a
patch to have a clear idea what you mean, and (b) the application of
that flag should be dependent on that variable exposed to Lisp, so
that if problems happen, we can ask users to flip the variable and see
if the problems go away.

> I could add that w/o changing the behavior
> of READABLE_EVENTS_FILTER_EVENTS at all, and remove its only usage
> (which should beg the question "Should we keep that flag?"). So, maybe
> I could just rename the flag?

No, it must be a separately controlled behavior, see above.

> It seems unlikely that a person would start using a flag that has a
> single use without understanding what that flag does

In general, yes.  But isn't that precisely what you suggest we do
here? ;-)