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

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 16519@debbugs.gnu.org
> Date: Fri, 31 Jan 2014 15:11:20 +0100
> 
> 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.

I didn't really debug that part, so what's below might be my
imagination (though the fact that input-pending-p returns non-nil is
verified).  That said, it doesn't make much difference to Emacs on
Windows whether we are in batch mode or in console (i.e. -nw) mode.
We still read the keyboard using the same Windows APIs (see
w32inevt.c), and so we still see the console events that Windows sends
us.  Those events are strange, and not all of them are documented, but
they do arrive.

More generally, you can never rely on what kind of input events are
sent to Emacs in any mode.  This is inherently system-dependent,
especially with today's systems that have any number of channels to
send events to a program.

> > 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.

If we need this part, we can simply copy the relevant portion of
sit-for into file-notify-tests.el.

> 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.

Maybe we should have ert-sit-for, then, which does everything like
sit-for, except relying on input-pending-p?

> >   #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.

I don't see why we would need a separate queue for special events.
What we need, perhaps, is a way to peek at stdin to see whether
there's some input ready to be gobbled.  Shouldn't select/pselect
already provide that?  IOW, there should be no need to call getchar at
all at this point.

> > 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.

I meant uncommitted changes in file-notify-tests.el.

> > 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.

Thanks.