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

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

[Peter Münster]

Hello,

Surprised about functions never executing, that I start with
gnus-demon-add-handler and some idle-time, I've checked the idle time of
emacs this way:

while sleep 1; do emacsclient -e '(current-idle-time)'; done

This test has revealed, that the idle time is reset to 0, whenever I
switch a desktop-page. I use FvwmPager with 3x3 pages. Emacs is on page
2-2 and even when emacs is not affected by the page-change (for example
from 1-1 to 1-2), the idle time is reset.

How could I avoid such reset please?

TIA for any hints.



In GNU Emacs 27.2 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: openSUSE Leap 15.2

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Configured using:
 'configure --disable-build-details --with-pop --without-hesiod
 --with-gameuser=:games --with-kerberos --with-kerberos5
 --with-file-notification=inotify --with-modules --enable-autodepend
 --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
 --datadir=/usr/share --localstatedir=/var --sharedstatedir=/var/lib
 --libexecdir=/usr/lib
 --enable-locallisppath=/usr/share/emacs/27.2/site-lisp:/usr/share/emacs/site-lisp
 --with-x --with-xim --with-sound --with-xpm --with-jpeg --with-tiff
 --with-gif --with-png --with-rsvg --with-dbus --with-xft --without-gpm
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 --x-includes=/usr/include --x-libraries=/usr/lib64 --with-libotf
 --with-m17n-flt --with-cairo --with-xwidgets --build=x86_64-suse-linux
 --with-dumping=pdumper 'CFLAGS=-fmessage-length=0 -grecord-gcc-switches
 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables
 -fasynchronous-unwind-tables -fstack-clash-protection -g -D_GNU_SOURCE
 -DGDK_DISABLE_DEPRECATION_WARNINGS -DGLIB_DISABLE_DEPRECATION_WARNINGS
 -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
 -fno-optimize-sibling-calls -fno-PIE -DSYSTEM_PURESIZE_EXTRA=55000
 -DSITELOAD_PURESIZE_EXTRA=10000 -DPDMP_BASE='\''"emacs-gtk"'\'''
 LDFLAGS=-Wl,-O2'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_CTYPE: en_GB.utf8
  value of $LC_MESSAGES: en_GB.utf8
  value of $LC_NUMERIC: POSIX
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils pp server time-date
subr-x cl-loaddefs cl-lib delsel lpr easy-mmode pcase tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 45431 8593)
 (symbols 48 6077 1)
 (strings 32 16018 2520)
 (string-bytes 1 520413)
 (vectors 16 9497)
 (vector-slots 8 127010 11274)
 (floats 8 21 52)
 (intervals 56 279 0)
 (buffers 1000 14))

-- 
           Peter

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

[Lars Ingebrigtsen]

Peter Münster <pm@a16n.net> writes:

> This test has revealed, that the idle time is reset to 0, whenever I
> switch a desktop-page. I use FvwmPager with 3x3 pages. Emacs is on page
> 2-2 and even when emacs is not affected by the page-change (for example
> from 1-1 to 1-2), the idle time is reset.

I can reproduce this under Gnome with:

(run-at-time 1 1 (lambda ()
		   (insert (format-time-string "%H:%M:%S") " "
                   (format "%s\n" (current-idle-time)))))

and then switching to another virtual desktop.

So I guess there's a notification Emacs receives that resets the idle
time?  Does anybody happen to know what notification this could be?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Peter Münster <pm@a16n.net>
> Date: Wed, 11 Aug 2021 10:42:57 +0200
> 
> Surprised about functions never executing, that I start with
> gnus-demon-add-handler and some idle-time, I've checked the idle time of
> emacs this way:
> 
> while sleep 1; do emacsclient -e '(current-idle-time)'; done
> 
> This test has revealed, that the idle time is reset to 0, whenever I
> switch a desktop-page. I use FvwmPager with 3x3 pages. Emacs is on page
> 2-2 and even when emacs is not affected by the page-change (for example
> from 1-1 to 1-2), the idle time is reset.
> 
> How could I avoid such reset please?

Does Emacs receive some event from the window-system when you switch
the desktop-page?  If it does, that's what explains the reset of the
idle time.

To see what can be done, I think we'd need to know whether indeed
Emacs receives an event, and what kind of event is that.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> To see what can be done, I think we'd need to know whether indeed
> Emacs receives an event, and what kind of event is that.

It seems like Emacs is woken up from read_event_from_main_queue...  so
by instrumenting that a bit, and then changing virtual desktops...

Aha!

16:12:06 starting (move-frame (#<frame ba.el - GNU Emacs at elva 0x55dd37bbcea0>))  backtrace-to-string()
  internal-timer-start-idle((move-frame (#<frame GNU Emacs at elva 0x55dd37bbcea0>)))
  read-event(nil nil 0.001)

So we're getting a move-frame event so this is being triggered, I guess?

      if (!end_time)
	timer_stop_idle ();

I guess the question then is...  can we distinguish between real
move-frame events and these virtual desktop things?  I'm guessing not:

    case MOVE_FRAME_EVENT:
      /* Make an event (move-frame (FRAME)).  */
      return list2 (Qmove_frame, list1 (event->frame_or_window));

So the window manager is sending us a MOVE_FRAME_EVENT here.

Then the question becomes: Should one of these events stop Emacs idleness?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Peter Münster <pm@a16n.net>,  49997@debbugs.gnu.org
> Date: Sun, 15 Aug 2021 16:18:30 +0200
> 
> 16:12:06 starting (move-frame (#<frame ba.el - GNU Emacs at elva 0x55dd37bbcea0>))  backtrace-to-string()
>   internal-timer-start-idle((move-frame (#<frame GNU Emacs at elva 0x55dd37bbcea0>)))
>   read-event(nil nil 0.001)
> 
> So we're getting a move-frame event so this is being triggered, I guess?
> 
>       if (!end_time)
> 	timer_stop_idle ();
> 
> I guess the question then is...  can we distinguish between real
> move-frame events and these virtual desktop things?  I'm guessing not:
> 
>     case MOVE_FRAME_EVENT:
>       /* Make an event (move-frame (FRAME)).  */
>       return list2 (Qmove_frame, list1 (event->frame_or_window));
> 
> So the window manager is sending us a MOVE_FRAME_EVENT here.

The code you show is in keyboard.c, where we interpret the events
we've received.  To see whether we can distinguish between these
events and "real" move-frame events, we need to look in xterm.c, where
the events come in from the window-system.  Maybe they are different
in their raw form?

> Then the question becomes: Should one of these events stop Emacs idleness?

If you move the frame, I think the answer is yes.  But if this problem
is really very annoying, and we cannot distinguish between these
pseudo-moves and real moves, we could perhaps have a variable to
control whether this event stops idleness,so people could decide
what's more important for them?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The code you show is in keyboard.c, where we interpret the events
> we've received.  To see whether we can distinguish between these
> events and "real" move-frame events, we need to look in xterm.c, where
> the events come in from the window-system.  Maybe they are different
> in their raw form?

Ah, I see.  Right, this is in handle_one_xevent, where we apparently
synthesise the MOVE_FRAME_EVENT:

	      if (!FRAME_TOOLTIP_P (f)
		  && (old_left != f->left_pos || old_top != f->top_pos))
		{
		  inev.ie.kind = MOVE_FRAME_EVENT;
		  XSETFRAME (inev.ie.frame_or_window, f);
		}
	    }

So it's purely based on whether the window manager told is that the
position changed -- which I guess it sort of does?  When I move to a
different virtual desktop, it shows me all the iconified frames, and
that's probably where this comes from?

This is in:

    case ConfigureNotify:

that case in itself is almost 200 lines long...

I've added Martin to the CCs; perhaps he has some insights here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: pm@a16n.net,  49997@debbugs.gnu.org, Martin Rudalics <rudalics@gmx.at>
> Date: Sun, 15 Aug 2021 16:36:49 +0200
> 
> 	      if (!FRAME_TOOLTIP_P (f)
> 		  && (old_left != f->left_pos || old_top != f->top_pos))
> 		{
> 		  inev.ie.kind = MOVE_FRAME_EVENT;
> 		  XSETFRAME (inev.ie.frame_or_window, f);
> 		}
> 	    }
> 
> So it's purely based on whether the window manager told is that the
> position changed -- which I guess it sort of does?  When I move to a
> different virtual desktop, it shows me all the iconified frames, and
> that's probably where this comes from?

The OP said this happens even when he switches to a page without the
Emacs frame, so I'm not sure how the position could change?  And if
iconified frames are somehow involved, we could perhaps look at
FRAME_ICONIFIED_P and/or the FocusIn/FocuseOut events?

(Full disclosure: I know almost nothing about X events.)

> I've added Martin to the CCs; perhaps he has some insights here.

Good idea.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> The OP said this happens even when he switches to a page without the
> Emacs frame, so I'm not sure how the position could change?  And if
> iconified frames are somehow involved, we could perhaps look at
> FRAME_ICONIFIED_P and/or the FocusIn/FocuseOut events?

I poked around some more, and

	      if (!FRAME_TOOLTIP_P (f)
		  && (old_left != f->left_pos || old_top != f->top_pos))
		{
		  inev.ie.kind = MOVE_FRAME_EVENT;
		  XSETFRAME (inev.ie.frame_or_window, f);
		}

is not involved here, and neither is

    case MOVE_FRAME_EVENT:
      /* Make an event (move-frame (FRAME)).  */
      return list2 (Qmove_frame, list1 (event->frame_or_window));

So we're getting the Qmove_frame from somewhere else?

Perhaps I should fire up gdb to trace this...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

I think I was looking at the wrong thing -- I was looking at the
idle_start stuff, but it's the idle_stop stuff that's important.  (An
idle_start when we're already idle doesn't change anything.)

And the idle_stops that happen when I change back to the virtual desktop
comes from here:

static void
x_focus_changed (int type, int state, struct x_display_info *dpyinfo, struct frame *frame, struct input_event *bufp)
{
  if (type == FocusIn)
    {
      if (dpyinfo->x_focus_event_frame != frame)
        {
          x_new_focus_frame (dpyinfo, frame);
          dpyinfo->x_focus_event_frame = frame;
          bufp->kind = FOCUS_IN_EVENT;
          XSETFRAME (bufp->frame_or_window, frame);
        }

      frame->output_data.x->focus_state |= state;
[...]
  else if (type == FocusOut)
    {
      frame->output_data.x->focus_state &= ~state;

So we lose focus and then get it back, and that makes Emacs unidle.

Which is arguably correct behaviour, but I can see the case for changing
that.  I mean, the user hasn't done anything inside Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: pm@a16n.net,  49997@debbugs.gnu.org,  rudalics@gmx.at
> Date: Sun, 15 Aug 2021 18:17:06 +0200
> 
> static void
> x_focus_changed (int type, int state, struct x_display_info *dpyinfo, struct frame *frame, struct input_event *bufp)
> {
>   if (type == FocusIn)
>     {
>       if (dpyinfo->x_focus_event_frame != frame)
>         {
>           x_new_focus_frame (dpyinfo, frame);
>           dpyinfo->x_focus_event_frame = frame;
>           bufp->kind = FOCUS_IN_EVENT;
>           XSETFRAME (bufp->frame_or_window, frame);
>         }
> 
>       frame->output_data.x->focus_state |= state;
> [...]
>   else if (type == FocusOut)
>     {
>       frame->output_data.x->focus_state &= ~state;
> 
> So we lose focus and then get it back, and that makes Emacs unidle.

If we get focus in/out events when the user changes the page, then
it's the correct behavior.

> Which is arguably correct behaviour, but I can see the case for changing
> that.  I mean, the user hasn't done anything inside Emacs.

The user switched off the Emacs frame, which is something, not
nothing.

Why exactly does the stop of idleness present a problem in this case?
And if it does present a problem, cannot the OP use
after-focus-change-function to restart the idleness?

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

[Eli Zaretskii]

> Date: Sun, 15 Aug 2021 19:46:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 49997@debbugs.gnu.org, pm@a16n.net
> 
> And if it does present a problem, cannot the OP use
> after-focus-change-function to restart the idleness?

Or maybe configure the WM not to send focus-out events for a page
switch?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> And if it does present a problem, cannot the OP use
>> after-focus-change-function to restart the idleness?
>
> Or maybe configure the WM not to send focus-out events for a page
> switch?

Well, it does definitely lose focus when we switch to a different
desktop, so I think the events themselves are correct (more or less).

I guess the concept of "Emacs is idle" isn't well-defined.  I think a
natural interpretation of the it is "I haven't done anything in Emacs".
And giving focus to Emacs isn't "in Emacs", in a way.  So we could bar
FOCUS_IN/FOCUS_OUT from changing idleness in general.

On the other hand, getting/losing focus is a thing that happens to
Emacs, so it's not really "idle".

I dunno.  Perhaps we should just leave it as is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 49997@debbugs.gnu.org,  pm@a16n.net
> Date: Sun, 15 Aug 2021 19:12:55 +0200
> 
> Well, it does definitely lose focus when we switch to a different
> desktop, so I think the events themselves are correct (more or less).

If we get a focus-out event for a frame that was already in
"focus-out" state, we could detect that and do nothing.  This would
correspond to the situation where the user already moved focus from
Emacs (i.e. was working in some other application's window), and
switched to a different page -- in such a situation I could indeed
understand why the user didn't expect the idleness to end.

But if the user had focus in an Emacs frame, and switched pages, then
the focus-out event indeed counts, and the user cannot expect the
idleness to continue.

> I guess the concept of "Emacs is idle" isn't well-defined.  I think a
> natural interpretation of the it is "I haven't done anything in Emacs".

No, it means no input events came in.  Emacs cannot know whether the
user does anything, it can only know what events come its way.

> And giving focus to Emacs isn't "in Emacs", in a way.  So we could bar
> FOCUS_IN/FOCUS_OUT from changing idleness in general.
> 
> On the other hand, getting/losing focus is a thing that happens to
> Emacs, so it's not really "idle".
> 
> I dunno.  Perhaps we should just leave it as is.

Can we please see if this also happens when the frame is already in a
focus-out state?  We could perhaps ignore such events.  Otherwise, I
tend to agree that there's not much we could do here.

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: pm@a16n.net,  49997@debbugs.gnu.org,  rudalics@gmx.at
> Date: Sun, 15 Aug 2021 18:17:06 +0200
> 
> static void
> x_focus_changed (int type, int state, struct x_display_info *dpyinfo, struct frame *frame, struct input_event *bufp)
> {
>   if (type == FocusIn)
>     {
>       if (dpyinfo->x_focus_event_frame != frame)
>         {
>           x_new_focus_frame (dpyinfo, frame);
>           dpyinfo->x_focus_event_frame = frame;
>           bufp->kind = FOCUS_IN_EVENT;
>           XSETFRAME (bufp->frame_or_window, frame);
>         }
> 
>       frame->output_data.x->focus_state |= state;
> [...]
>   else if (type == FocusOut)
>     {
>       frame->output_data.x->focus_state &= ~state;
> 
> So we lose focus and then get it back, and that makes Emacs unidle.

Actually, I think we need the details.  When the user changes the
page, which event do we get? focus-out or focus-in? or both one after
the other?

If we get the focus-out event, what is the frame's focus_state at that
point?

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

[Eli Zaretskii]

> Date: Sun, 15 Aug 2021 19:54:40 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 49997@debbugs.gnu.org, pm@a16n.net
> 
> Actually, I think we need the details.  When the user changes the
> page, which event do we get? focus-out or focus-in? or both one after
> the other?
> 
> If we get the focus-out event, what is the frame's focus_state at that
> point?

And also, which frame is being reported as receiving the event?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, I think we need the details.  When the user changes the
> page, which event do we get? focus-out or focus-in? or both one after
> the other?

Let's see...  when switching to the other desktop, we get a focus out.
When switching back again, we seem to get a focus in, then an out, and
then an in again.

Just opening a frame normally gives me an in, out and in again, so the
extra out/in may be just something the window manager always does.

> If we get the focus-out event, what is the frame's focus_state at that
> point?

Haven't looked yet.

Eli Zaretskii <eliz@gnu.org> writes:

> And also, which frame is being reported as receiving the event?

There's only a single Emacs frame in my tests.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

 >> The code you show is in keyboard.c, where we interpret the events
 >> we've received.  To see whether we can distinguish between these
 >> events and "real" move-frame events, we need to look in xterm.c, where
 >> the events come in from the window-system.  Maybe they are different
 >> in their raw form?
 >
 > Ah, I see.  Right, this is in handle_one_xevent, where we apparently
 > synthesise the MOVE_FRAME_EVENT:
 >
 > 	      if (!FRAME_TOOLTIP_P (f)
 > 		  && (old_left != f->left_pos || old_top != f->top_pos))
 > 		{
 > 		  inev.ie.kind = MOVE_FRAME_EVENT;
 > 		  XSETFRAME (inev.ie.frame_or_window, f);
 > 		}
 > 	    }
 >
 > So it's purely based on whether the window manager told is that the
 > position changed -- which I guess it sort of does?  When I move to a
 > different virtual desktop, it shows me all the iconified frames, and
 > that's probably where this comes from?
 >
 > This is in:
 >
 >      case ConfigureNotify:
 >
 > that case in itself is almost 200 lines long...
 >
 > I've added Martin to the CCs; perhaps he has some insights here.

I can offer the attached trivial patch.  Peter, can you try it?

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: move-frame.diff --]
[-- Type: text/x-patch; name="move-frame.diff", Size: 407 bytes --]

diff --git a/src/keyboard.c b/src/keyboard.c
index 34c64b9186..e643d3267b 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2929,6 +2929,7 @@ read_char (int commandflag, Lisp_Object map,

       if (CONSP (c)
           && (EQ (XCAR (c), Qselect_window)
+	      || EQ (XCAR (c), Qmove_frame)
               || EQ (XCAR (c), Qfocus_out)
 #ifdef HAVE_DBUS
 	      || EQ (XCAR (c), Qdbus_event)

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

On Wed, Aug 18 2021, martin rudalics wrote:

> I can offer the attached trivial patch.  Peter, can you try it?

Thanks. Yes, it works as expected.

Now the question is: is this the right thing to do?

According to Eli
(https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-08/msg01016.html)
it's not so clear.

But on the other side, focus-out events and mouse movements keep the
"idleness" too. So I guess, that frame movements could fall in the same
category...

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[Eli Zaretskii]

> From: Peter Münster <pm@a16n.net>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Eli Zaretskii <eliz@gnu.org>,
>   49997@debbugs.gnu.org
> Date: Wed, 18 Aug 2021 11:16:57 +0200
> 
> > I can offer the attached trivial patch.  Peter, can you try it?
> 
> Thanks. Yes, it works as expected.
> 
> Now the question is: is this the right thing to do?
> 
> According to Eli
> (https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-08/msg01016.html)
> it's not so clear.
> 
> But on the other side, focus-out events and mouse movements keep the
> "idleness" too. So I guess, that frame movements could fall in the same
> category...

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.

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?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> FWIW, I think this is a slippery slope, let alone
> backward-incompatible change.

The slope has already been created, since we already filter out three
events:

       if (CONSP (c)
           && (EQ (XCAR (c), Qselect_window)
+	      || EQ (XCAR (c), Qmove_frame)
               || EQ (XCAR (c), Qfocus_out)
 #ifdef HAVE_DBUS
 	      || EQ (XCAR (c), Qdbus_event)

> 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

I agree totally.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

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

[Eli Zaretskii]

> Cc: larsi@gnus.org, 49997@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 20 Aug 2021 10:19:06 +0200
> 
>  > 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.

If we end up with a list of ignored events, as I think we should, we
should consider making the same list control all of the relevant
features.

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

 > If we end up with a list of ignored events, as I think we should, we
 > should consider making the same list control all of the relevant
 > features.

Not sure whether the attached is what you meant - it's just a first stab
in that direction.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: while-no-input-ignore-events.diff --]
[-- Type: text/x-patch; name="while-no-input-ignore-events.diff", Size: 2907 bytes --]

diff --git a/lisp/subr.el b/lisp/subr.el
index 0a31ef2b29..f100259e9e 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4350,11 +4350,6 @@ with-local-quit
 	   ;; that intends to handle the quit signal next time.
 	   (eval '(ignore nil)))))

-;; Don't throw `throw-on-input' on those events by default.
-(setq while-no-input-ignore-events
-      '(focus-in focus-out help-echo iconify-frame
-        make-frame-visible selection-request))
-
 (defmacro while-no-input (&rest body)
   "Execute BODY only as long as there's no pending input.
 If input arrives, that ends the execution of BODY,
diff --git a/src/keyboard.c b/src/keyboard.c
index 2e4c4e6aab..48b9904d85 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2927,20 +2927,8 @@ 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)
-              || 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))
-          && !end_time)
+      if (CONSP (c) && !NILP (Fmemq (XCAR (c), Vwhile_no_input_ignore_events))
+	  && !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
@@ -11550,6 +11538,27 @@ init_keyboard (void)
   {SYMBOL_INDEX (Qselect_window),       SYMBOL_INDEX (Qswitch_frame)}
 };

+static Lisp_Object
+init_while_no_input_ignore_events (void)
+{
+  Lisp_Object events = listn (9, Qselect_window, Qhelp_echo, Qmove_frame,
+			      Qiconify_frame, Qmake_frame_visible,
+			      Qfocus_in, Qfocus_out, Qconfig_changed_event,
+			      Qselection_request);
+
+#ifdef HAVE_DBUS
+  events = Fcons (Qdbus_event, events);
+#endif
+#ifdef USE_FILE_NOTIFY
+  events = Fcons (Qfile_notify, events);
+#endif
+#ifdef THREADS_ENABLED
+  events = Fcons (Qthread_event, events);
+#endif
+
+  return events;
+}
+
 static void syms_of_keyboard_for_pdumper (void);

 void
@@ -12444,7 +12453,12 @@ syms_of_keyboard (void)

   DEFVAR_LISP ("while-no-input-ignore-events",
                Vwhile_no_input_ignore_events,
-               doc: /* Ignored events from while-no-input.  */);
+               doc: /* Ignored events from while-no-input.
+Events in this list do not count as pending input while running
+`while-no-input' and do not cause any idle timers to get reset when they
+occur.  */);
+
+  Vwhile_no_input_ignore_events = init_while_no_input_ignore_events ();

   pdumper_do_now_and_after_load (syms_of_keyboard_for_pdumper);
 }

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

[Eli Zaretskii]

> Cc: pm@a16n.net, larsi@gnus.org, 49997@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 22 Aug 2021 10:24:15 +0200
> 
>  > If we end up with a list of ignored events, as I think we should, we
>  > should consider making the same list control all of the relevant
>  > features.
> 
> Not sure whether the attached is what you meant - it's just a first stab
> in that direction.

Something like that, yes.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Not sure whether the attached is what you meant - it's just a first stab
>> in that direction.
>
> Something like that, yes.

Looks good to me, too.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Not sure whether the attached is what you meant - it's just a first stab
>>> in that direction.
>>
>> Something like that, yes.
>
> Looks good to me, too.

Martin, I think everybody agreed that your patch looked like basically
the right thing, but as far as I can see, it wasn't applied.  Was there
something more you wanted to check before pushing it, or were you just
waiting until after the emacs-28 branch was cut (so that it can be
pushed to master)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[martin rudalics]

 > Martin, I think everybody agreed that your patch looked like basically
 > the right thing, but as far as I can see, it wasn't applied.  Was there
 > something more you wanted to check before pushing it, or were you just
 > waiting until after the emacs-28 branch was cut (so that it can be
 > pushed to master)?

I wanted to understand it first.  Or maybe I was just waiting for Peter
to say that he uses it for quite a while now without problems and if we
could finally install it ...

martin

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

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> I wanted to understand it first.

:-)

> Or maybe I was just waiting for Peter to say that he uses it for quite
> a while now without problems and if we could finally install it ...

I think it looks safeish enough to push to master, and then we'll see
whether there's any corner cases.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[martin rudalics]

 > I think it looks safeish enough to push to master, and then we'll see
 > whether there's any corner cases.

OK.  Pushed to master now.

martin

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

On Mon, Oct 11 2021, martin rudalics wrote:

> Or maybe I was just waiting for Peter

Sorry. I was waiting for the push to master before using it...

(But I've tested it once, and it worked.)

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[martin rudalics]

close 49997 29.1
quit

 > Sorry. I was waiting for the push to master before using it...
 >
 > (But I've tested it once, and it worked.)

Pushed to master so you can use it now.  Closing this bug.

Good luck, martin

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

On Wed, Aug 11 2021, Peter Münster wrote:

> Emacs is on page 2-2 and even when emacs is not affected by the
> page-change (for example from 1-1 to 1-2), the idle time is reset.

Just to be clear: That means, that Emacs is already out of focus
*before* the page change. And after the page change too.

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[Lars Ingebrigtsen]

Peter Münster <pm@a16n.net> writes:

> On Wed, Aug 11 2021, Peter Münster wrote:
>
>> Emacs is on page 2-2 and even when emacs is not affected by the
>> page-change (for example from 1-1 to 1-2), the idle time is reset.
>
> Just to be clear: That means, that Emacs is already out of focus
> *before* the page change. And after the page change too.

Oh, then we're not seeing the exact same behaviour -- when I switch
virtual desktops in Gnome (where Emacs isn't on any of them), then idle
time isn't reset.

But I guess it's window manager dependent.

Do you get focus-in events when you do the changing between pages in the
way you describe?  Try putting something on focus-in-hook -- that should
be run when Emacs gets a focus-in event.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Sun, Aug 15 2021, Lars Ingebrigtsen wrote:

> Do you get focus-in events when you do the changing between pages in the
> way you describe?

No. Neither focus-in nor focus-out events...

Now I've checked the events with "xev -id 0x140013e":

ConfigureNotify event, serial 18, synthetic YES, window 0x140013e,
    event 0x140013e, window 0x140013e, (3843,2334), width 3389, height 1963,
    border_width 0, above 0xa0016e, override NO

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[Lars Ingebrigtsen]

Peter Münster <pm@a16n.net> writes:

>> Do you get focus-in events when you do the changing between pages in the
>> way you describe?
>
> No. Neither focus-in nor focus-out events...

So I guess our window managers are sending us different events in this
case...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Peter Münster <pm@a16n.net>
> Date: Mon, 16 Aug 2021 09:22:01 +0200
> Cc: 49997@debbugs.gnu.org
> 
> > Do you get focus-in events when you do the changing between pages in the
> > way you describe?
> 
> No. Neither focus-in nor focus-out events...
> 
> Now I've checked the events with "xev -id 0x140013e":
> 
> ConfigureNotify event, serial 18, synthetic YES, window 0x140013e,
>     event 0x140013e, window 0x140013e, (3843,2334), width 3389, height 1963,
>     border_width 0, above 0xa0016e, override NO

Can you tell what is "serial 18" in our xterm.c nomenclature?  IOW,
what does this ConfigureNotify report to us?

Thanks.

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

On Mon, Aug 16 2021, Eli Zaretskii wrote:

>> ConfigureNotify event, serial 18, synthetic YES, window 0x140013e,
>> event 0x140013e, window 0x140013e, (3843,2334), width 3389, height 1963,

> Can you tell what is "serial 18" in our xterm.c nomenclature?

I don't know. But according to XEvent(3) it's the "number of last
request processed by server".


> IOW, what does this ConfigureNotify report to us?

It seems to me, that it reports a new position: (3843,2334)
The position changes, because the viewport changes, and so the origin
(point 0,0) too.

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[Eli Zaretskii]

> From: Peter Münster <pm@a16n.net>
> Cc: larsi@gnus.org,  49997@debbugs.gnu.org
> Date: Mon, 16 Aug 2021 17:51:43 +0200
> 
> > Can you tell what is "serial 18" in our xterm.c nomenclature?
> 
> I don't know. But according to XEvent(3) it's the "number of last
> request processed by server".

Thanks.  So that won't help.

> > IOW, what does this ConfigureNotify report to us?
> 
> It seems to me, that it reports a new position: (3843,2334)
> The position changes, because the viewport changes, and so the origin
> (point 0,0) too.

Is there a way to detect that the origin changed?  If so, we could
perhaps teach Emacs that when the coordinates change due to the change
in origin, it isn't a move at all.

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 213 bytes --]

On Mon, Aug 16 2021, Eli Zaretskii wrote:

> Is there a way to detect that the origin changed?

I guess no.

But IMHO the idle time should not be reset to 0, when the window moves.

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[Eli Zaretskii]

> From: Peter Münster <pm@a16n.net>
> Cc: larsi@gnus.org,  49997@debbugs.gnu.org
> Date: Mon, 16 Aug 2021 18:42:14 +0200
> 
> > Is there a way to detect that the origin changed?
> 
> I guess no.

Too bad.

> But IMHO the idle time should not be reset to 0, when the window moves.

Not even when the user moves the window? why not?

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Mon, Aug 16 2021, Eli Zaretskii wrote:

>> But IMHO the idle time should not be reset to 0, when the window moves.
>
> Not even when the user moves the window? why not?

Because that's my understanding of idleness: when nothing is done inside
of Emacs, the idle timer should keep running. When the window is just
moved to another place, there is no real input.
Same with my kid: when he sleeps, he keeps sleeping even when I carry him
to another bedroom... ;)

Anyway: when the user moves the window, there will be certainly also an
focus-in event, that can trigger the reset of the idle timer.

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[Eli Zaretskii]

> From: Peter Münster <pm@a16n.net>
> Cc: larsi@gnus.org,  49997@debbugs.gnu.org
> Date: Mon, 16 Aug 2021 19:10:37 +0200
> 
> >> But IMHO the idle time should not be reset to 0, when the window moves.
> >
> > Not even when the user moves the window? why not?
> 
> Because that's my understanding of idleness: when nothing is done inside
> of Emacs, the idle timer should keep running. When the window is just
> moved to another place, there is no real input.
> Same with my kid: when he sleeps, he keeps sleeping even when I carry him
> to another bedroom... ;)

The only definition of "idleness" we can use in Emacs is that Emacs is
not processing any input events.  This is fundamental.  I don't know
how to define "nothing is done inside Emacs" otherwise.  If taken
literally, this is something that never happens, because the main loop
in Emacs always runs, and always "does things".

> Anyway: when the user moves the window, there will be certainly also an
> focus-in event, that can trigger the reset of the idle timer.

So focus-in events are different for some reason?  I guess we will
have to agree to disagree.

That said, we could perhaps provide user control on what constitutes
an event that can stop the idleness.  Some sort of list of events that
are disregarded for this purpose, maybe.  Patches welcome.

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

On Mon, Aug 16 2021, Eli Zaretskii wrote:

> The only definition of "idleness" we can use in Emacs is that Emacs is
> not processing any input events.

I agree. So the question is: Does Emacs process a window movement, when
it's not visible? If yes, what does it do? If not, then you seem to
agree to not resetting the idle timer.

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[Eli Zaretskii]

> From: Peter Münster <pm@a16n.net>
> Cc: larsi@gnus.org,  49997@debbugs.gnu.org
> Date: Mon, 16 Aug 2021 19:47:36 +0200
> 
> > The only definition of "idleness" we can use in Emacs is that Emacs is
> > not processing any input events.
> 
> I agree. So the question is: Does Emacs process a window movement, when
> it's not visible? If yes, what does it do? If not, then you seem to
> agree to not resetting the idle timer.

When Emacs receives this event, it does process it: it generates the
move-frame pseudo-function key, which is bound to the command
handle-move-frame.

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

[Peter Münster]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

On Mon, Aug 16 2021, Eli Zaretskii wrote:

> When Emacs receives this event, it does process it: it generates the
> move-frame pseudo-function key, which is bound to the command
> handle-move-frame.

Ok, then I think nothing should be done in Emacs, and I should look for
other solutions for my quite particular problem.

-- 
           Peter

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 211 bytes --]