emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Aaron Jensen
Subject: Re: input-pending-p after make-frame-visible
Date: Wed, 20 Oct 2021 16:00:12 -0400

On Wed, Oct 20, 2021 at 3:03 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Wed, 20 Oct 2021 14:55:05 -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>
> >
> > On Wed, Oct 20, 2021 at 2:24 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > AFAICT kbd_buffer_get_event calls `readable_events (0)' only, which
> > > > will disregard any of the code I changed or added. The
> > > > READABLE_EVENTS_FILTER_EVENTS must be set for it to come into play.
> > > > Only input-pending-p sets that flag AFAICT.
> > >
> > > I don't see how this helps: who will remember that no caller of
> > > readable_events can ever use that flag without invoking this behavior
> > > whose justification we don't understand?
> >
> > Which behavior are you saying the justification is not understood? If
> > it's the behavior I introduced, it should be understood as it is
> > understandable.
>
> We are mis-communicating.  What bothers me is that in some more or
> less distant future someone will find a good reason to call
> readable_events with that flag from some other place, not realizing
> that doing so will get some of the events filtered out under some
> subtle conditions.  Thus, the fact that this flag has currently just
> one user, which just happens to be the function whose behavior you are
> interested to change, doesn't help, because we'd still have a ticking
> maintenance bomb.

Got it, so I guess the question is, what is the expected behavior of
readable_events when READABLE_EVENTS_FILTER_EVENTS is set?

Would adding another flag like
READABLE_EVENTS_FILTER_WHILE_NO_INPUT_IGNORE_EVENTS make it more clear
exactly what it is doing? 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?

It seems unlikely that a person would start using a flag that has a
single use without understanding what that flag does, but I'm somewhat
out of position here and I don't want to create a maintenance burden
for anyone.

Thanks,

Aaron



reply via email to

[Prev in Thread] Current Thread [Next in Thread]