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

[Ioannis Kappas]

Hi Eli

Just to recap (with a touch of drama this time).

The following command

emacs -Q --batch --eval="(progn (message \"The bomb will explode in 10
seconds, cut the red cable to disarm\") (sit-for 3600))"

will behave differently depending on the architecture/prompt it is invoked from:

When it is invoked from the Linux terminal or from a plain emacs
eshell (i.e. M-x eshell) prompt  or from a windows command prompt =>
message is printed out immediately, user cuts the red cable, bomb
doesn't explode.

When it is invoked from msys64 mintty terminal or from emacs eshell on
windows => no message is printed out (until emacs -batch returns), no
cables cut, bomb explodes after ten seconds.

How do you suggest we flush the message out so that it is always
displayed to the user irrespective of the architecture/prompt it is
ran on? Is there perhaps an elisp function to flush messages out (e.g.
(progn (message "...") (message-flush!) (sit-for ...))) ?

So far we said:
1. We don't want to a solution where the emacs -batch's stderrr is
forced to unbuffered mode (original patch proposal)
2. message_to_stderr() does not directly or indirectly invoke stderr
flush (at least in windows).

Thanks

On Thu, Feb 11, 2021 at 7:55 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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.