GNU bug report logs - #17390
24.4.50; Doc bug: Batch Mode

Previous Next

Full log

Message #11 received at 17390 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 17390 <at> debbugs.gnu.org
Subject: Re: bug#17390: 24.4.50; Doc bug: Batch Mode
Date: Sun, 06 Sep 2015 23:52:00 +1200

Johan Bockgård <bojohan <at> gnu.org> 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 <rgm <at> gnu.org> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.