Subject: bug#49997: 27.2; idle-time reset when switching desktop-page

From: martin rudalics <[email-masked]>
Date: Fri, 20 Aug 2021 10:19:06 +0200

> FWIW, I think this is a slippery slope, let alone
 > backward-incompatible change.  If we want to go anywhere near this
 > method, I'd suggest to create a variable with a list of events ignored
 > for the idleness purposes, which users could customize according to
 > their preferences and usage patterns (and, it turns out, their WM).
 > That would at least let users some kind of fire escape, whereas
 > hard-coding arbitrary events that we happen not to like this week
 > doesn't.

Until 2016 Qselect_window was the only event in this group.  And when
Michael fixed Bug#23207 by adding Qfile_notify you said

    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?

and we finally ended up with

           && (EQ (XCAR (c), Qselect_window)
               || EQ (XCAR (c), Qfocus_out)
#ifdef HAVE_DBUS
	      || EQ (XCAR (c), Qdbus_event)
#endif
#ifdef USE_FILE_NOTIFY
	      || EQ (XCAR (c), Qfile_notify)
#endif
#ifdef THREADS_ENABLED
	      || EQ (XCAR (c), Qthread_event)
#endif
	      || EQ (XCAR (c), Qconfig_changed_event))

 > Btw, idleness is not the only feature related to this gray area:
 > there's also while-no-input, input-pending-p, and throw-on-input, to
 > mention a few.  Should these be in sync?

Here we have

(setq while-no-input-ignore-events
       '(focus-in focus-out help-echo iconify-frame
         make-frame-visible selection-request))

so this set and the above are certainly not "in sync".

But I have no idea how these two sets are supposed to interact and
whether and how they should be presented to users.

martin