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

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

Eli Zaretskii <eliz@gnu.org> writes:

> This breaks the file-notify-test02-events test on w32.  It looks like
> read-event never returns there.

Strange. There is the call (read-event nil nil 0.1) - shouldn't it
return under any circumstances?

> If I replace that with sit-for, it does return, but the test still
> fails because file-notify--test-results remains nil, something that
> wasn't being tested when I last ran the test (in early December).

sit-for seems to work for inotify based file notifications only. If
there is gio in place, one needs to perform accept-process-output. This
is unfortune, because the user cannot know in advance how to check for
events. Fortnately, both read-event and accept-process-output are called
for other reasons in interactive mode, letting the events arrive. Not
the best situation, but I don't know (yet) how to harmonize.

I don't know what it needs on w32 to get the file notification
events. Is it sit-for?

> Frankly, given the inordinate amount of work it took to try to get
> file notifications work in batch mode, I'd rather we declared they are
> not expected to work in batch, and moved on.  If you, for some reason,
> still want to stick with that test, please mark
> file-notify-test02-events to be skipped for w32, as I'm tired of
> fixing the breakage there time and again.

Well, maybe there is no use case which requires file notification events
in batch mode. BUT I like to be informed by hydra, that a whatever
change has broken Emacs. Often, this are collateral damages by unrelated
changes.

Given, that I have no possibility to develop on w32, I'll go as proposed
by you and mark file-notify-test02-events (and maybe also
file-notify-test03-autorevert) as expected to fail on w32 in batch
mode. The same is currently true for gio based file notifications, but
here I'm eager to find a solution, which works on hydra.

> Thanks.

Best regards, Michael.