From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: `message' not outputting the newline "atomically" Date: Wed, 26 Jun 2019 22:43:12 -0700 Organization: UCLA Computer Science Department Message-ID: <17b87a28-7885-9eee-621c-60d088586f9a@cs.ucla.edu> References: <07619925-e367-fb88-2dd8-27addb2e9052@grinta.net> <68b398b1-3790-b32f-535d-6ea2518f79b8@cs.ucla.edu> <83r27hlkix.fsf@gnu.org> <1d550142-8d66-485b-6796-981351718b53@cs.ucla.edu> <83blykjijy.fsf@gnu.org> <65c60a70-311d-bf9f-b509-d3dd80ddc511@cs.ucla.edu> <83a7e4jh5d.fsf@gnu.org> <838stnkb7y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="236160"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii , Daniele Nicolodi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 27 07:44:02 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 1hgNCT-000zEn-2o for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2019 07:44:01 +0200 Original-Received: from localhost ([::1]:46542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgNCR-0000Qt-LU for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2019 01:43:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33235) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgNBw-0000P7-Bo for emacs-devel@gnu.org; Thu, 27 Jun 2019 01:43:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgNBv-0001jA-ET for emacs-devel@gnu.org; Thu, 27 Jun 2019 01:43:28 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:39440) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hgNBt-0001c3-Ux; Thu, 27 Jun 2019 01:43:26 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C7A8C162625; Wed, 26 Jun 2019 22:43:18 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id cLRvjKowFTuV; Wed, 26 Jun 2019 22:43:18 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1BC9716262A; Wed, 26 Jun 2019 22:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SiClxklpzeY2; Wed, 26 Jun 2019 22:43:18 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E33E0162625; Wed, 26 Jun 2019 22:43:17 -0700 (PDT) In-Reply-To: <838stnkb7y.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:238184 Archived-At: >> However, if that is the route you are suggesting, it is much easier to >> enable line buffering unconditionally ad place fflush() calls where it >> matters, than the other way around. > You are suggesting fflush after every character written? I think he was suggesting enabling line buffering (_IOLBF) unconditionally, and also placing fflush where we want the output right away even on MS-Windows. The fflush would be needed only for MS-Windows, because MS-Windows is the only Emacs platform where using _IOLBF does not work (MS-Windows silently treats requests to use line buffering as if they requested full buffering, which is not what we want for stderr). If this is the compromise needed to fix this problem then let's do it. _IOLBF is a simple and effective solution to this problem on GNU and other POSIXish platforms, and we shouldn't let MS-Windows's lack of support for a useful feature prevent Emacs from using the feature on non-MS-Windows platforms.