GNU bug report logs - #49997
27.2; idle-time reset when switching desktop-page

Previous Next

Package: emacs;

Reported by: Peter Münster <pm <at> a16n.net>

Date: Wed, 11 Aug 2021 08:44:01 UTC

Severity: normal

Tags: confirmed, moreinfo

Found in version 27.2

Fixed in version 29.1

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


Message #109 received at 49997 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Peter Münster <pm <at> a16n.net>
Cc: 49997 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#49997: 27.2; idle-time reset when switching desktop-page
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




This bug report was last modified 3 years and 225 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.