From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Phil Estival Newsgroups: gmane.emacs.devel Subject: Re: no buffer to flush the error output in ? Date: Wed, 18 Sep 2024 01:04:25 +0200 Message-ID: References: <86frpybfb2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33101"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 18 01:05:49 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sqhGX-0008Tc-Ei for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Sep 2024 01:05:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sqhFv-00059m-Sz; Tue, 17 Sep 2024 19:05:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sqhFt-00058X-SF for emacs-devel@gnu.org; Tue, 17 Sep 2024 19:05:10 -0400 Original-Received: from smtp-42ad.mail.infomaniak.ch ([84.16.66.173]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sqhFr-00067o-Cv; Tue, 17 Sep 2024 19:05:09 -0400 Original-Received: from smtp-4-0001.mail.infomaniak.ch (smtp-4-0001.mail.infomaniak.ch [10.7.10.108]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4X7cn94BtNzBfh; Wed, 18 Sep 2024 01:05:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=7d.nz; s=20240212; t=1726614301; bh=a4sfLWjXelH+RNKhbICCufC+IQFsqoyWf2AvoEsXKrw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dkjUOt6AdUo42Rz2/GmYrRmQEBF8MWdciOmzsxb3XxLo4T6q5XhpgGbTMmKMWJAqV 5YZcL5hbJeWYhRzHwtwE0UJy/hAUI3V7tA8Gv6X65QBiTFSBYKMypEBBiC8tgZ9+JI JTs52+OV4T9FmG9AO8VQ7heeudh9bkaeOjI8rZbQ0gBF7tE8r2rTNz7P92+baKXNf+ k75nG8c2FEodMMrXo6i91HvtzQfCt1UsolF2hq3VNMdnqW9ZM78PQPo54Funo1lEaU Yo4GWxDnIBAum3q8xqnkvlz3Zej/f/jMzpqWJSYMFccTA0FuxK6DS4xB+piGRiLzvB WT8qz74DL0Cbg== Original-Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4X7cn91PH3zgxK; Wed, 18 Sep 2024 01:05:01 +0200 (CEST) Content-Language: fr In-Reply-To: <86frpybfb2.fsf@gnu.org> X-Infomaniak-Routing: alpha Received-SPF: pass client-ip=84.16.66.173; envelope-from=pe@7d.nz; helo=smtp-42ad.mail.infomaniak.ch X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323707 Archived-At: * [2024-09-17 15:06] Eli Zaretskii: >> Date: Tue, 17 Sep 2024 12:06:54 +0200 >> From: Phil Estival >> >> [[info:elisp#Synchronous Processes]] says >> >> You can’t directly specify a buffer to put the >> error output in; that is too difficult to >> implement. >> >> Can someone explain why please ? > > Because you'd need to read process output from two independent file > descriptors at the same time, I guess. E.g., the rate of readning to > each one of the descriptors could be (and very frequently is) very > different, > and you don't want to slow down reading from stdout because > you want to check stderr. I see. This is occuring in wait_reading_process_output. There is a process prioritization of lower file descriptors, but this would impede the overall output reading. I had missed [[info:elisp#Asynchronous Processes][elisp#Asynchronous Processes]]. make-process can have a buffer or a pipe process attached to the standard error of subprocess. (If STDERR is nil, standard error is mixed with standard output). My questionning comes from an interactive command shell based on comint, the performance are not significant. In the end the output has to be separated somehow (prompt, result output and errors). When not separating the channels, additional escapde codes are needed plus various semantics that has to be filtered with regex acrobatics, e.g. - 165 matches in 147 lines for "regex" in buffer: comint.el.gz<28.2> - https://gitlab.freedesktop.org/Per_Bothner/specifications/blob/master/proposals/semantic-prompts.md - http://per.bothner.com/blog/2019/shell-integration-proposal/ >> But you can achieve this result by >> sending the error output to a temporary file and >> then inserting the file into a buffer when the >> subprocess finishes. >> >> Only when it finishes? But there must certainly exist a way >> to have stdout/err be separated buffered streams... right ? > > You can separate them, yes, but the problem is how to read from both, > see above. And since Emacs waits for the process to exit anyway, why > does it matter that you get the stderr stuff only after it exits? > I'll to get back to comint and try to understading if starting the subprocess by providing the stderr channel is meaningfull. Cheers, Phil