bug#16519: 24.3.50; gfile notifications not received in batch mode

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

>> `sit-for' calls `read-event', if `input-pending-p' returns nil. So it
>> shall be safe to call.
>
> Obviously, input-pending-p returns non-nil on Windows, so read-event
> is never called.

Out of curiosity: why? We are in batch mode.

> If we want sit-for to call read-event, then let's call read-event
> directly.  Why risk platform-specific behavior in delicate functions
> like input-pending-p? what does it gain us here?  sit-for does nothing
> useful except call read-event.

The reason that I have preferred sit-for over read-event is, that
sit-for puts the events back to unread-command-events. Likely, we don't
need this in the test cases we're speaking about, but the code shall
give also how-to-use examples to people. sit-for seems to be cleaner to
me in this respect.

>> All interactive cases work. In the noninteractive case, it works also
>> for inotify. For w32notify and gfilenotify it doesn't work yet, that's
>> why there is the expected result :fail.
>
> My crystal ball says that you've done all your testing on GNU/Linux
> with a build that has D-Bus support compiled in.  If so, please try
> a --without-dbus build: I'm sure you will see that read-event in batch
> mode doesn't return in such a build even if there is a time-out.

Perfect crystal ball. When I reconfigure Emacs not to use D-Bus, also
the inotify test case fails in batch mode.

> The reason is this part in kbd_buffer_get_event:
>
>   #ifndef HAVE_DBUS  /* We want to read D-Bus events in batch mode.  */
>     if (noninteractive
> 	/* In case we are running as a daemon, only do this before
> 	   detaching from the terminal.  */
> 	|| (IS_DAEMON && daemon_pipe[1] >= 0))
>       {
> 	int c = getchar ();
> 	XSETINT (obj, c);
> 	*kbp = current_kboard;
> 	return obj;
>       }
>   #endif	/* ! HAVE_DBUS  */

I remember. I've added the !HAVE_DBUS prepocessor statetements due to
Bug#11415. It was a similar situation, D-Bus events were not read in
batch mode. So we really need a changed handling of special events in
the main loop, instead of adding more preprocessor lines.

>> So it seems to be a problem read the events inside Emacs. The difference
>> between the two test cases is, that in the autorevert case there are
>> active timers. Maybe those timers trigger the event handling.
>
> That's possible: timers change the control flow in the input
> processing code.  But test02 also has at least one timer: the one
> launched by with-timeout.

This one I will continue to debug, although changes should be applied
only after the release.

> Please try with running emacs.exe, not runemacs.exe, and see if it
> still succeeds.  I run like this (from cmd prompt):
>
>   cd test\automated
>   ..\..\src\emacs -Q -batch -l file-notify-tests.el -f ert
>
> then type "2 RET" when prompted in the minibuffer.  The results are
> one test skipped and one unexpected failure.

I'll continue to check if time allows. I have only limited access to
that Windows XP machine.

> If you still don't see the failure, is it possible that you have some
> local uncommitted changes?

Guaranteed not :-)

I cannot and I do not compile w32 versions of Emacs. The only changes
are in file-notify-tests.el, where I add traces etc pp.

> So, where to go from here?
>
> First, I think the above fragment, which makes D-Bus builds behave in
> batch differently from any other build, is not a good idea.  It is
> probably not a good idea even in D-Bus builds when they run an daemon
> mode.  Does anyone understand why we need to call getchar in batch, on
> any of the supported platforms and configurations?  Or why it is
> needed in daemon mode?

As said above: Bug#11415.

> As for the need to call read-event in file-notify--wait-for-events on
> w32, if no other build needs that, I guess we can condition that call
> on windows-nt.  But given the above discussion, I think we should do
> the opposite: call read-event directly on _all_ platforms.

I will run some tests for that. Then we can switch to use read-event.

I vaguely remember there was also a problem with file notifications of
remote files; I had to call accept-process-output. But maybe it was
superfluous, I will check again.

These tests may take some days (I have some private trouble). But since
we don't want to change Emacs proper but only the test code and the
documentation, it might not be a serious problem.

> Thanks.

Best regards, Michael.