bug#17390: 24.4.50; Doc bug: Batch Mode

bug#17390: 24.4.50; Doc bug: Batch Mode

[Johan Bockgård]

(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'.)

bug#17390: 24.4.50; Doc bug: Batch Mode

[Glenn Morris]

Johan Bockgård wrote:

> This is not correct. Text printed with "`prin1', etc., with `t' as the
> stream" goes to stdout, not stderr. (Unlike `message'.)

To me, it would make more sense for `message' to use stdout too.

bug#17390: 24.4.50; Doc bug: Batch Mode

[Phil Sainty]

Johan Bockgård <bojohan@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@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.

bug#17390: 24.4.50; Doc bug: Batch Mode

[Johan Bockgård]

Phil Sainty <psainty@orcon.net.nz> writes:

> I wonder whether it would be sensible at this point to provide a
> completely new option for PRINTCHARFUN which explicitly means stderr

It exists and is called `external-debugging-output'.

bug#17390: 24.4.50; Doc bug: Batch Mode

[Noam Postavsky]

tags 17390 fixed
close 17390 25.1
quit

Johan Bockgård <bojohan@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'.)

This was fixed in 25.1.

[1: 565adf2e90]: 2018-02-08 20:32:47 -0500
  Clarify that text-quoting-style doesn't affect *Info* (Bug#24519)
  [...]
  (Batch Mode): Document how text written to standard streams is
encoded.  Fix inaccuracy regarding which output streams are used
by output functions in batch mode.
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=565adf2e90d67de2107343aaf265ec6c3e8fd165