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

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sat, 6 Jul 2019 18:16:03 -0700
> 
> What I *think* you meant is that you want code that outputs diagnostics 
> conveniently, via functions like 'fprintf' and 'message' and 'fatal' etc., to 
> output as much as possible within the constraints of (a) not significantly 
> obstructing convenience and (b) fixing the line-interleaving bugs somehow.

Yes, that's what I meant.

> > I was certain what I wrote will not be interpreted
> > in this way.
> 
> I'm afraid that you were mistaken there. Even now I'm not sure I understand 
> exactly what you meant. It is an area where it's tough to be precise.

Sorry, I'm trying.

> > using the above for diagnostic output, or for informative
> > messages output during an Emacs build, is unrelated to the original
> > problem raised by Lars.  That problem was with messages from a running
> > Emacs, outside of the build process (because the build process use
> > case can be handled by the Make's -O switch), i.e. when Emacs is run
> > as part of some script.
> 
> Sorry, I'm not following you here, as Lars's original email 
> <https://lists.gnu.org/r/emacs-devel/2019-06/msg00710.html> was about 
> messages 
> generated by Emacs running inside the build process.
> 
> We cannot rely on 'make -O' to address the problem, as 'make -O' slows down 
> development, which is why I typically don't use 'make -O' and don't recommend 
> it 
> for building Emacs interactively. 'make -O' can be useful for buildbots where 
> there's a batch process that waits for build completion before publishing it. 
> However, under an interactive Emacs where I want to act on the first 
> diagnostic 
> right away (before the build finishes), 'make -O' is a net minus because it 
> can 
> delay diagnostics significantly, and this delay costs more than it's worth.
> 
> And even if we assumed 'make -O' sufficed for builds (which it doesn't), we 
> can't assume these diagnostics are generated from a single instance of GNU 
> Make. 
> It's reasonably common, for example, that from a terminal window I'll run the 
> shell command "emacs &", and then do other stuff in that window while Emacs 
> occasionally outputs stderr diagnostics. (Although I think this is the sort 
> of 
> thing you're alluding to above, I'm not sure.) So we would have an 
> interleaving 
> problem anyway even if 'make -O' worked well.

This long thread began with a message that is output during a build.
Lars didn't like such messages mixed up from several Emacsen running
in parallel, so 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.

With the 'message' case now solved by your patch (which is fine by me,
thanks), we are now back to the messages which are only output during
the build, or are diagnostic messages about abnormal or even fatal
situations.

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, if you really want, but I
really question the utility of that.

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.  I think using that is a
good compromise.

> +#ifndef DOS_NT /* _IOLBF does not work on MS-Windows.  */

This should be WINDOWSNT, not DOS_NT.

Thanks.