From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: checking results of `compile' in batch mode Date: Sun, 13 Oct 2013 15:17:00 -0500 Message-ID: <85hacldiyr.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1381695440 12025 80.91.229.3 (13 Oct 2013 20:17:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Oct 2013 20:17:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 13 22:17:23 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VVS6M-0007P3-To for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2013 22:17:23 +0200 Original-Received: from localhost ([::1]:34461 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVS6M-0003IG-DC for ged-emacs-devel@m.gmane.org; Sun, 13 Oct 2013 16:17:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59263) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVS6D-0003IA-BS for emacs-devel@gnu.org; Sun, 13 Oct 2013 16:17:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVS66-000787-0s for emacs-devel@gnu.org; Sun, 13 Oct 2013 16:17:13 -0400 Original-Received: from cdptpa-outbound-snat.email.rr.com ([107.14.166.226]:10307 helo=cdptpa-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVS65-00077y-Sw for emacs-devel@gnu.org; Sun, 13 Oct 2013 16:17:05 -0400 Original-Received: from [75.87.81.6] ([75.87.81.6:51167] helo=TAKVER) by cdptpa-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id E3/31-15529-EBFFA525; Sun, 13 Oct 2013 20:17:04 +0000 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) X-RR-Connecting-IP: 107.14.168.118:25 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: BaiduSpider X-Received-From: 107.14.166.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:164183 Archived-At: I'm trying to run a test of an Ada mode function that invokes `compilation-start'. The process started runs a cross reference tool; the expected result is a list of locations, recognized by an entry in compilation-error-regexp-alist. The test invokes the top level Ada mode function, sleeps a bit to let the cross reference tool run, then invokes `next-error' to pop to the expected location, and checks the location using `looking-at'. This works fine in interactive mode, but fails in batch mode. I've added a debug dump of the "*compilation*" buffer to the test, and the output of the background process is not appearing in that buffer. Even when I add a verbosity option to the background process command, nothing shows up in the ""*compilation*" buffer after the echo of the command line inserted directly by `compilation-start'. Is there something in the compilation-start mechanism that inhibits background process output in batch mode? I'm looking thru the code in compile.el, but I don't see any mention of this effect. Hmm. I just realized the *compilation* buffer also doesn't have the normal "Compilation finished at ..." message. So maybe the background process is not running, despite the `sleep-for'? The sleep-for does delay the foreground emacs (it takes longer to exit when I increase it), so why would the background process not run? I found a work-around; (fmakeunbound 'start-process). This causes `compilation-start' to call the cross reference tool synchronously; now the tool output appears in the *compilation* buffer (the test still fails, but that's another problem). This also means I can delete the 'sleep-for, and I don't have to guess at how long to wait for the results. So this may be a good thing to keep in the batch mode test. So I can move forward, but I'd like to understand what's going on with the background process in batch mode. -- -- Stephe