Re: `message' not outputting the newline "atomically"

[Paul Eggert]

Eli Zaretskii wrote:

> I proposed -O.  Then Lars said that use of 'message'
> is not limited to building Emacs, and we embarked on the rest of the
> thread.

OK, I see the background better now. However, it's not just 'message', as Emacs 
will output to stderr in a few other places when I run it in the background from 
my terminal window (or whatever), even when Emacs is is not generating debugging 
output or a fatal error message. These other places should also be fixed.

> As for "make -O", could it be that you were talking literally about
> that, i.e. about "make -O=target"?  Because I meant "make -O=line",
> which AFAIR slows down the build only slightly, and provides the
> line-level separation that you want to see

Give the background you mentioned, 'make -O' is a cold trail since it doesn't 
suffice to fix the other problems. That being said, 'make -Oline' does have 
delays that slow me down. For example, when 'make -Oline' compiles src/xdisp.c, 
it doesn't show me any of GCC's output until GCC exits. On my desktop in some 
cases that's a 15-second wait for a diagnostic that I can see in a few 
milliseconds if I don't use -O.

> I don't want us to buffer diagnostics and fatal error messages.  The
> other messages, such as the one which outputs the pdumper fingerprint,
> could be modified to not mix with others

With that constraint in mind, I thought of a fix that's simpler and and more 
straightforward than what I sent you earlier. The idea is to output the other 
messages to stdout, not stderr. That way, they'll avoid the interleaving 
problem, and it'll be easier to separate them from debugging diagnostics and 
fatal error messages. Proposed patch attached; it attempts to identify all the 
places that output these "other messages".

0001-Send-informative-messages-to-stdout-not-stderr.patch
Description: Text Data