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

[martin rudalics]

> 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