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

[Eli Zaretskii <eliz@gnu.org>]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Thu, 21 Oct 2021 07:25:44 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, martin rudalics <rudalics@gmx.at>, Alan Third <alan@idiocy.org>, 
> 	Gregory Heytings <gregory@heytings.org>, emacs-devel@gnu.org
> 
> I understand the change better now and why the `#ifdef
> USE_TOOLKIT_SCROLL_BARS` was added around the `flags &
> READABLE_EVENTS_FILTER_EVENTS` check. It was an optimization to avoid
> an additional check because there was a previous check already done
> before entering the loop. So, I don't think that a bug was introduced,
> it just made the code a little more difficult to decipher. I can add
> that check back into my patch in whatever its final form is.

Whatever the original reasons, that patch has proven its utility by
fixing the original problem and not generating new ones in all the
years that passed since then.

> > I think that the input-pending-p problem needs a real fix.
> > These events should be ignored for the sake of input-pending-p
> > even if they are not ignored for some other purposes.
> >
> > Perhaps there should be two different functions for asking
> > whether there is input, one for low-level Emacs purposes
> > and one for high-level purposes.  Can you try fixing it that way?
> 
> So, the original impetus for the filtering code was that
> input-pending-p was reporting t when only a filter change was made.

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.

Which is why I must insist on making the change either limited to
input-pending-p, come what may, or to have a variable that controls
the change if its effect is more general.  If the change proves to not
cause any harm, in some distant future we can consider removing the
condition.

> > 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 think that the variable would just change how
> READABLE_EVENTS_FILTER_EVENTS worked, so I would not add a new flag
> unless you feel that ultimately renaming it would be beneficial.

The change you propose _does_ change how READABLE_EVENTS_FILTER_EVENTS
behaves.  I want that change to be controlled by a Lisp variable.  I'm
not wedded to the specific implementation I suggested.  If you can
think of a different way to reach that goal, it's fine with me; show
me the code.

> > > 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? ;-)
> 
> Hah, to be fair I understand exactly what the flag does :).

Famous last words.

> Please let me know how you would like me to proceed -- I'm happy to
> add the extra variable and vary the behavior based on it for now.

I hope the above answers that question.

Thanks.