[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: `message' not outputting the newline "atomically"
Date: Tue, 09 Jul 2019 19:39:03 +0300

> Cc: address@hidden, address@hidden,
>  Emacs Development <address@hidden>
> From: Paul Eggert <address@hidden>
> Date: Mon, 8 Jul 2019 19:47:26 -0700
> > 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.

With recent GCC versions emitting several lines of diagnostics for
several related but different files, using -Oline avoids mixing up
diagnostics from different sources, which is something someone may
wish to have.  Sure, it slows things down a little, but free lunches
are no longer available.  Whether this is a price one wants to pay
depends on the situation and on what one needs to do or test.  Like
with any other Make option; for example, I sometimes don't use -jN
because I need to avoid parallelism for some reason or another, and it
certainly slows down the build.

> > 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".

I feel we are going in circles whose radius doesn't get smaller, which
means we will never converge.  We already found an agreed solution for
'message' and 'vmessage', so why step back and re-introduce them into
the problem again?  Switching 'message' to use stdout is something I
don't think we can reasonably consider, as that changes behavior Emacs
had for decades.

As for other messages, I think the vast majority are diagnostics, and
thus using stdout for them is inappropriate, as it will get in the way
of using Emacs in scripts.  Anything that has "warning" or "error" or
"failed" or any similar words in the message is definitely for stderr.

IOW, as I already said, I see only one candidate for stdout here: the
pdumper fingerprint, and even there I'm not 100% sure.  All the other
messages you suggested to output to stdout are diagnostics, and should
stay on stderr.  The exception is 'message' and 'vmessage', where we
already arrived at an acceptable solution which uses a stream that is
line-buffered, but separate from stdout.

Hmm... about 'message', though: what would happen if a script says
2>foo? will the file 'foo' remain empty if we use any stream but
stderr inside message_to_stderr?  If so, maybe even the solution I
thought will be acceptable isn't.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]