Subject: Re: bug#23207: 25.1.50; file-notify event restarts the idle timer

From: Eli Zaretskii <[email-masked]>
Date: Sun, 03 Apr 2016 20:16:59 +0300

> From: Michael Albinus <[email-masked]>
> Date: Sun, 03 Apr 2016 18:05:17 +0200
> Cc: [email-masked]
> 
> > diff --git a/src/keyboard.c b/src/keyboard.c
> > index 1a5dbd0..b71c656 100644
> > --- a/src/keyboard.c
> > +++ b/src/keyboard.c
> > @@ -2834,7 +2834,9 @@ read_char (int commandflag, Lisp_Object map,
> >        last_input_event = c;
> >        call4 (Qcommand_execute, tem, Qnil, Fvector (1, &last_input_event), Qt);
> >  
> > -      if (CONSP (c) && EQ (XCAR (c), Qselect_window) && !end_time)
> > +      if (CONSP (c)
> > +          && (EQ (XCAR (c), Qselect_window) || EQ (XCAR (c), Qfile_notify))
> > +          && !end_time)
> >         /* We stopped being idle for this event; undo that.  This
> >            prevents automatic window selection (under
> >            mouse_autoselect_window from acting as a real input event, for
> 
> Looks good to me. Of course, we must wrap EQ (XCAR (c), Qfile_notify) by
> #ifdef USE_FILE_NOTIFY; not all Emacs instances are configured to use
> file notifications.

Right.

> > This is in the handing of special-event-map which includes
> > file-notify.  special-event-map includes some events that should
> > restart the idle timer because they are user input (like drag-n-drop).
> > But file-notify is not user input so i think it should not restart the
> > idle timer.
> >
> > The same probably goes for dbus-event and config-changed-event that
> > also are in the special-event-map.  Maybe they also should be exempted
> > in the same way.
> 
> I agree for dbus-event. Don't know whether we need it also for
> config-changed-event, my naïve gut feeling tells me that this doesn't
> happen very often. Maybe somebody else knows better.

Why does frequency matter here?

> > Also i don't understand why this code checks for Qselect_window.
> > select-window is not included in special-event-map so that should
> > never turn up there.
> 
> Same here.

Couldn't someone bind select-window in special-event-map?

Anyway, I think we should simply check all the special events that are
not user events here.  If they don't have a binding in
special-event-map, then the test will always fail.

What about focus-in/out events?  Or xwidget-event?