From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#16519: 24.3.50; gfile notifications not received in batch mode Date: Fri, 31 Jan 2014 17:17:12 +0200 Message-ID: <83r47o5gg7.fsf@gnu.org> References: <87obft367u.fsf@gnu.org> <87fvomstx8.fsf@gmx.de> <83zjmkb0yu.fsf@gnu.org> <87zjmi67yl.fsf_-_@gmx.de> <87y521if0c.fsf@gmx.de> <83vbx27j0k.fsf@gnu.org> <87iot16b2i.fsf@gmx.de> <83ha8l766e.fsf@gnu.org> <87ppn8gs1j.fsf@gmx.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1391181493 32121 80.91.229.3 (31 Jan 2014 15:18:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jan 2014 15:18:13 +0000 (UTC) Cc: 16519@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 31 16:18:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W9FrE-0005jJ-1w for geb-bug-gnu-emacs@m.gmane.org; Fri, 31 Jan 2014 16:18:16 +0100 Original-Received: from localhost ([::1]:56316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9FrD-0004NP-IA for geb-bug-gnu-emacs@m.gmane.org; Fri, 31 Jan 2014 10:18:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Fr5-0004Gl-U5 for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 10:18:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9Fr0-0000ck-OW for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 10:18:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Fr0-0000ca-KL for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 10:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W9Fr0-0008UU-3C for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 10:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 31 Jan 2014 15:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16519-submit@debbugs.gnu.org id=B16519.139118143932579 (code B ref 16519); Fri, 31 Jan 2014 15:18:02 +0000 Original-Received: (at 16519) by debbugs.gnu.org; 31 Jan 2014 15:17:19 +0000 Original-Received: from localhost ([127.0.0.1]:43382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W9FqI-0008TN-J5 for submit@debbugs.gnu.org; Fri, 31 Jan 2014 10:17:19 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:57731) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W9FqF-0008T9-FS for 16519@debbugs.gnu.org; Fri, 31 Jan 2014 10:17:17 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0N0900200UETON00@mtaout26.012.net.il> for 16519@debbugs.gnu.org; Fri, 31 Jan 2014 17:16:16 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0900N1RUF4OQ40@mtaout26.012.net.il>; Fri, 31 Jan 2014 17:16:16 +0200 (IST) In-reply-to: <87ppn8gs1j.fsf@gmx.de> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:84360 Archived-At: > From: Michael Albinus > Cc: 16519@debbugs.gnu.org > Date: Fri, 31 Jan 2014 15:11:20 +0100 > > Eli Zaretskii 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.