From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: `message' not outputting the newline "atomically" Date: Sun, 07 Jul 2019 17:51:34 +0300 Message-ID: <83tvbx7v9l.fsf@gnu.org> References: <07619925-e367-fb88-2dd8-27addb2e9052@grinta.net> <68b398b1-3790-b32f-535d-6ea2518f79b8@cs.ucla.edu> <83pnn1lkej.fsf@gnu.org> <83tvccjrpo.fsf@gnu.org> <83zhm3i285.fsf@gnu.org> <7a39d680-6234-1301-74e5-62d599f500f6@cs.ucla.edu> <838stfd0pp.fsf@gnu.org> <835zojd0fx.fsf@gnu.org> <834l43czz8.fsf@gnu.org> <5c979663-9ded-4273-11d1-483345053a6f@cs.ucla.edu> <831rz7cvoh.fsf@gnu.org> <540324b5-fad3-ded0-5018-6abb494ce126@cs.ucla.edu> <83blyaaq5l.fsf@gnu.org> <73e8afc0-2151-9c8b-26c5-454fcd2f361d@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="146831"; mail-complaints-to="usenet@blaine.gmane.org" Cc: larsi@gnus.org, daniele@grinta.net, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 07 17:01:12 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hk8fA-000bpW-Es for ged-emacs-devel@m.gmane.org; Sun, 07 Jul 2019 17:01:12 +0200 Original-Received: from localhost ([::1]:35774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hk8WQ-0000CN-Rc for ged-emacs-devel@m.gmane.org; Sun, 07 Jul 2019 10:52:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52741) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hk8Vw-0000CF-RG for emacs-devel@gnu.org; Sun, 07 Jul 2019 10:51:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41924) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hk8Vu-0001pM-E3; Sun, 07 Jul 2019 10:51:40 -0400 Original-Received: from [176.228.60.248] (port=4741 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hk8Vt-0000ZM-SG; Sun, 07 Jul 2019 10:51:38 -0400 In-reply-to: <73e8afc0-2151-9c8b-26c5-454fcd2f361d@cs.ucla.edu> (message from Paul Eggert on Sat, 6 Jul 2019 18:16:03 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238391 Archived-At: > Cc: larsi@gnus.org, daniele@grinta.net, emacs-devel@gnu.org > From: Paul Eggert > 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 > 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.