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: Tue, 09 Jul 2019 19:39:03 +0300 Message-ID: <83y31740yg.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> <83tvbx7v9l.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="72417"; 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 Tue Jul 09 18:39:45 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 1hkt9d-000IjK-Go for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 18:39:45 +0200 Original-Received: from localhost ([::1]:51922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkt9c-00049o-Au for ged-emacs-devel@m.gmane.org; Tue, 09 Jul 2019 12:39:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38639) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkt9G-00046h-Co for Emacs-devel@gnu.org; Tue, 09 Jul 2019 12:39:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hkt9D-000849-Q3; Tue, 09 Jul 2019 12:39:20 -0400 Original-Received: from [176.228.60.248] (port=1660 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hkt9D-0006nP-2f; Tue, 09 Jul 2019 12:39:19 -0400 In-reply-to: (message from Paul Eggert on Mon, 8 Jul 2019 19:47:26 -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:238466 Archived-At: > Cc: larsi@gnus.org, daniele@grinta.net, > Emacs Development > From: Paul Eggert > 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.