From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#16519: 24.3.50; gfile notifications not received in batch mode Date: Fri, 31 Jan 2014 15:11:20 +0100 Message-ID: <87ppn8gs1j.fsf@gmx.de> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391177533 12091 80.91.229.3 (31 Jan 2014 14:12:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jan 2014 14:12:13 +0000 (UTC) Cc: 16519@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 31 15:12:20 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 1W9EpP-0006DI-0Y for geb-bug-gnu-emacs@m.gmane.org; Fri, 31 Jan 2014 15:12:19 +0100 Original-Received: from localhost ([::1]:55813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9EpO-0006Qr-JJ for geb-bug-gnu-emacs@m.gmane.org; Fri, 31 Jan 2014 09:12:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9EpE-0006Ql-Uc for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 09:12:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9Ep9-0004aZ-2H for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 09:12:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56667) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Ep8-0004Zr-UU for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 09:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W9Ep8-0006ae-GW for bug-gnu-emacs@gnu.org; Fri, 31 Jan 2014 09:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 31 Jan 2014 14:12: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.139117749025286 (code B ref 16519); Fri, 31 Jan 2014 14:12:02 +0000 Original-Received: (at 16519) by debbugs.gnu.org; 31 Jan 2014 14:11:30 +0000 Original-Received: from localhost ([127.0.0.1]:42453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W9Eob-0006Zl-I0 for submit@debbugs.gnu.org; Fri, 31 Jan 2014 09:11:30 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:57117) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W9EoY-0006Za-Bn for 16519@debbugs.gnu.org; Fri, 31 Jan 2014 09:11:27 -0500 Original-Received: from detlef.gmx.de ([93.209.86.42]) by mail.gmx.com (mrgmx001) with ESMTPS (Nemesis) id 0Mh9yT-1VvqhR2feD-00MLZ6 for <16519@debbugs.gnu.org>; Fri, 31 Jan 2014 15:11:25 +0100 In-Reply-To: <83ha8l766e.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Jan 2014 19:03:53 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V03:K0:cqCU9hGAsCU8hPuzhzw/lWcwLITYSMnYDGJTR160sWqNgTjZUxb KxQf5fKHuAKOit5D2g4btmvp6QVirNzdQFSiyB3TtrTwmsrBu7U7/ApDLoSY4iVlRdZCeJP q0+bR+6HrACxe0/F+iVnZEEm/+WMt+4Cxg35MVDW57/F1urNeJoQ7YY261VzsJ801dxj9vF zzHgQgtd+UhomSsIdp1RA== 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:84350 Archived-At: 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. > 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.