bug#46388: 27.1; emacs -batch does not output messages immediately when invoked outside of the command prompt

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Thu, 11 Feb 2021 19:25:31 +0000
> Cc: Paul Eggert <eggert@cs.ucla.edu>,
>  46388@debbugs.gnu.org
> 
> (just a small note, “buffer" is NULL under windows

Which is a Good Thing, since otherwise we'd have stderr always fully
buffered on Windows (since _IOLBF on Windows is interpreted the same
as _IOFBF, i.e. fully-buffered).

>, the fn thus returns without flushing anything. Even if buffer was not NULL, 
>the fflush fn would have flushed the content of what ever has been accumulated 
>on the stderr buffer so far, but not the message just  sent to 
>message_to_stderr that we want to print out. Although, there would be this 
>weird effect; message_to_sderr()  does an fwrite of the message followed by an 
>fputc of a newline. This means that if errstream() was to fflush stderr, it 
>would have flushed only the message written by fwrite, and not the newline 
>written by fputc. I think that, if we are indeed considering to explicitly 
>flush the message to stder, the correct place to do it would be directly 
>inside the message_to_stderr(), thanks)

If buferr is NULL, we are using the original stderr, which is supposed
to be unbuffered.

But I think you again are looking at the wrong side of the pipe: the
parent Emacs process reads from a pipe, which as its own buffering.
So whatever we do with Emacs's stderr will only affect subprocesses
when the child process is also Emacs, and will not have any effect on
other programs being run as subprocesses.

The correct solution, one that will seamlessly fix all the aspects of
the buffering, is to add pseudo-console support to Emacs on Windows,
and use that by default on systems that can support it.