From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniele Nicolodi Newsgroups: gmane.emacs.devel Subject: Re: `message' not outputting the newline "atomically" Date: Mon, 1 Jul 2019 09:41:52 +0200 Message-ID: <42f4e8e2-c3c6-be09-6b53-3b7b17c1302d@grinta.net> 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 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="270135"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 01 09:41:29 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 1hhqwL-001880-DB for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2019 09:41:29 +0200 Original-Received: from localhost ([::1]:48352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhqwK-0003jr-7M for ged-emacs-devel@m.gmane.org; Mon, 01 Jul 2019 03:41:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55299) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhqvp-0003hE-7C for emacs-devel@gnu.org; Mon, 01 Jul 2019 03:40:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhqvo-00032a-58 for emacs-devel@gnu.org; Mon, 01 Jul 2019 03:40:57 -0400 Original-Received: from zed.grinta.net ([109.74.203.128]:40852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hhqvk-0002xF-G2 for emacs-devel@gnu.org; Mon, 01 Jul 2019 03:40:54 -0400 Original-Received: from black.local (53.149.140.77.rev.sfr.net [77.140.149.53]) (Authenticated sender: daniele) by zed.grinta.net (Postfix) with ESMTPSA id 5BDA1E0E52 for ; Mon, 1 Jul 2019 07:40:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=mail; t=1561966847; bh=h5PgpWQFzeH5hvLKOutY/a2hS3FGNYG4AbRl2NE/FLc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=RpOiA5PG7aJNDd17nstGSAkxnOSnLUjgvCs5h/EDdanQ8npwuXwrCOa732uCvXH0q 6UBgY/c2Yi8e+7NwgYb9dXrapiZTiNovd1nmrsFG9F46sfxRAz2UHF6u2EGdNqfp8s +ac0eSAucPmxeDAwzJW+GviuIMNeA8XJWtDVEe4c= Openpgp: preference=signencrypt In-Reply-To: <838stnkb7y.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 109.74.203.128 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:238261 Archived-At: On 26/06/2019 20:34, Eli Zaretskii wrote: >> Cc: larsi@gnus.org, emacs-devel@gnu.org >> From: Daniele Nicolodi >> Date: Wed, 26 Jun 2019 13:36:54 -0600 >> >> Not that I care much about this, I feel that defending the use case of >> debugging Emacs through printf() statements is rooted in believes akin >> to religious ones, and religious arguments cannot be won with logic. > > It isn't religious at all. We have built-in debugging capabilities > that use stderr, see the trace-redisplay feature as one example. This > particular feature is very valuable for me, as it happens. Because you mention it explicitly, I went and checked how the trace-redisplay feature works. I found only one function used by this feature to outputs something on stderr, debug_method_add(), and this function uses an fprintf() with a format string that is terminated by a new line: fprintf (stderr, "%p (%s): %s\n", ...) to output messages to stderr. I don't think this would be affected in any way by line buffering stderr. Can you please be more precise in what is that makes you worried in relation to trace-redisplay and line buffered stderr? Thank you. Best, Dan