From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#17390: 24.4.50; Doc bug: Batch Mode Date: Sun, 06 Sep 2015 23:52:00 +1200 Message-ID: <55EC28E0.5030900@orcon.net.nz> References: <87siosqcdi.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1441540417 1265 80.91.229.3 (6 Sep 2015 11:53:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Sep 2015 11:53:37 +0000 (UTC) To: 17390@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 06 13:53:16 2015 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 1ZYYVT-0002Co-9C for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Sep 2015 13:53:11 +0200 Original-Received: from localhost ([::1]:47569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYYVS-0001Yi-Kh for geb-bug-gnu-emacs@m.gmane.org; Sun, 06 Sep 2015 07:53:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYYVP-0001YR-9V for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2015 07:53:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZYYVK-00006H-9E for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2015 07:53:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZYYVK-000067-6A for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2015 07:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZYYVK-0001SR-0Y for bug-gnu-emacs@gnu.org; Sun, 06 Sep 2015 07:53:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <87siosqcdi.fsf@gnu.org> Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Sep 2015 11:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17390 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17390-submit@debbugs.gnu.org id=B17390.14415403325470 (code B ref 17390); Sun, 06 Sep 2015 11:53:01 +0000 Original-Received: (at 17390) by debbugs.gnu.org; 6 Sep 2015 11:52:12 +0000 Original-Received: from localhost ([127.0.0.1]:50526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYYUW-0001Q8-3P for submit@debbugs.gnu.org; Sun, 06 Sep 2015 07:52:12 -0400 Original-Received: from [219.88.242.22] (port=34333 helo=mail.orcon.net.nz) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZYYUT-0001Pi-H4 for 17390@debbugs.gnu.org; Sun, 06 Sep 2015 07:52:10 -0400 Original-Received: from [10.1.1.5] (202-150-102-33.bng1.avl.orcon.net.nz [202.150.102.33] (may be forged)) (authenticated bits=0) by mail.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id t86Bq0Ir020446 for <17390@debbugs.gnu.org>; Sun, 6 Sep 2015 23:52:01 +1200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 X-Bayes-Prob: 0.0001 (Score 0: No Bayes scoring rules defined, tokens from: outbound) X-CanIt-Geo: ip=202.150.102.33; country=NZ; latitude=-41; longitude=174.0000; http://maps.google.com/maps?q=-41,174.0000&z=6 X-CanItPRO-Stream: base:outbound X-Canit-Stats-ID: 01PdLQ0F2 - 465793564af6 - 20150906 X-Scanned-By: CanIt (www . roaringpenguin . com) 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: 208.118.235.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:106186 Archived-At: Johan Bockgård writes: > (info "(elisp) Batch Mode") says: > > Any Lisp program output that would normally go to the echo > area, either using `message', or using `prin1', etc., with > `t' as the stream, goes instead to Emacs's standard error > descriptor when in batch mode. > > This is not correct. Text printed with "`prin1', etc., with `t' as the > stream" goes to stdout, not stderr. (Unlike `message'.) Glenn Morris writes: > To me, it would make more sense for `message' to use stdout too. This bug is still in effect (although it's not clear to me that the documentation should be considered to be what is in error?) It does seems initially intuitive that `message' would go to stdout, but having it go to stderr certainly makes more sense in the context of what the documentation claims -- that output written to the echo area (eq PRINTCHARFUN t) is treated as stderr. At present, `message' seems to be the *only* way of getting output to stderr in batch mode, which isn't ideal, as you don't get the same choice of output formats that you have with all the prin* functions. e.g. The documentation suggests that (princ "foo\n") would write to stdout, and (princ "foo\n" t) would write to stderr, which would seem useful, and much nicer than everything except `message' writing to stdout. However I do note that the functions accepting a PRINTCHARFUN argument tend to say that it will, when `nil', default to the value of `standard-output'; and that latter value (whether in batch mode or not) defaults to `t' -- precisely what is supposed to mean stderr! As such, this seems a bit messy; but given that the bug looks to have been in effect for quite a while now (23.4 behaves the same way), I wonder whether it would be sensible at this point to provide a completely new option for PRINTCHARFUN which explicitly means stderr (or indirectly, via a new `standard-error' variable, seeing as how we have both `standard-input' and `standard-output' vars, but no -error). That way we'd regain(??) the ability to send arbitrary prin* output to stderr in batch mode, without messing with the existing behaviour. Whether or not `message' continued to write to stderr would be a separate question, and I'm not sure what the right answer is, but it would certainly be a backwards-incompatible change.