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, 23 Jun 2019 17:47:10 +0300 Message-ID: <83sgs0mk9d.fsf@gnu.org> References: <83y31xr3aa.fsf@gnu.org> <26154872-1a5c-7302-0f32-b16aff8e0ae7@cs.ucla.edu> <83blytq90m.fsf@gnu.org> <95de57fb-ef8c-a65f-d3ca-4a9e7f0f38bc@cs.ucla.edu> <83a7ecquzb.fsf@gnu.org> <83tvckp5ni.fsf@gnu.org> <83r27op1wb.fsf@gnu.org> <60d1b05d-ef4c-252a-0626-8c69c103fdf0@cs.ucla.edu> <83o92rpk1g.fsf@gnu.org> <9d07a8e2-7f9b-bbfa-b73e-0d7aee09b099@cs.ucla.edu> <83zhmankgu.fsf@gnu.org> <31b12a41-18f2-d20c-55dc-28f7adb8606c@cs.ucla.edu> <83y31tm40j.fsf@gnu.org> <6f34c3a3-2f0a-e581-0dfe-4e4619e0b3dc@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="173861"; mail-complaints-to="usenet@blaine.gmane.org" Cc: schwab@suse.de, larsi@gnus.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 23 16:47:31 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 1hf3mD-000j6Z-Iy for ged-emacs-devel@m.gmane.org; Sun, 23 Jun 2019 16:47:29 +0200 Original-Received: from localhost ([::1]:45110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hf3mC-0008FA-9A for ged-emacs-devel@m.gmane.org; Sun, 23 Jun 2019 10:47:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38809) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hf3m7-0008F4-3Z for emacs-devel@gnu.org; Sun, 23 Jun 2019 10:47:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hf3m5-0004xP-Fr; Sun, 23 Jun 2019 10:47:21 -0400 Original-Received: from [176.228.60.248] (port=3742 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hf3lz-0001aE-Kb; Sun, 23 Jun 2019 10:47:18 -0400 In-reply-to: <6f34c3a3-2f0a-e581-0dfe-4e4619e0b3dc@cs.ucla.edu> (message from Paul Eggert on Sun, 23 Jun 2019 01:34:05 -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:238065 Archived-At: > Cc: schwab@suse.de, larsi@gnus.org, emacs-devel@gnu.org > From: Paul Eggert > Date: Sun, 23 Jun 2019 01:34:05 -0700 > > Eli Zaretskii wrote: > > What if Emacs crashes half way through that loop > > What, due to a hardware error or a buffer overrun or something like that? In > that case all bets are off: Emacs could output nonsense or truncated output > regardless of whether it uses one system call or a hundred. Diagnostic output is precious precisely when "all bets are off". For example, knowing that the loop did N iterations and died on (N+1)st or later can give a very important clue about the cause of the crash. > Besides, if we were allowed to hypothesize nonexistent bugs to argue against a > change to Emacs, then we could easily argue against any change whatsoever. When > thinking about changes to Emacs, it's more productive to consider real problems > than imaginary ones. Bugs aren't hypotheses, they actually happen. And stderr is one facility to diagnose abnormal behavior. Changing the buffering mode of a diagnostic stream globally because of a specific use case is therefore a bad idea. > Line-buffered stderr does a better job of interleaving diagnostics from parallel > instances of Emacs, and this is what prompted the fix in question. Once again, the primary purpose of stderr is to produce diagnostic error messages, so the producing nicer output is much less important than producing as much of the output as possible. > The poorly-interleaved diagnostics have been a practical problem > that has bugged me for a while, and bugs Lars and I assume > others. That use case could have a more specialized solution, such as explicit control of buffering from Lisp or a variant of 'message' that writes to a different stream. There's no need to juggernaut a general-purpose facility for the benefit of a specific use case, and not a very important one at that.