From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Sv: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?] Date: Wed, 31 Mar 2021 09:02:00 +0300 Message-ID: <83zgyjj1yf.fsf@gnu.org> References: <87r1jxd3d8.fsf@gnu.org> <8e549f23-db75-2ef1-4399-0fb52e5efa6f@gnu.org> <87zgykn5qc.fsf@gnus.org> <83sg4ckbfw.fsf@gnu.org> <87mtukn463.fsf@gnus.org> <83o8f0kaoj.fsf@gnu.org> <83mtukk9b3.fsf@gnu.org> <2e968b98-2264-03e7-d0b2-5570c94b6fb7@gmail.com> <838s64k3xk.fsf@gnu.org> <8260671e-df0a-e471-79fb-82f80e11696a@gmail.com> <837dlok1zj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=gb18030 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37019"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org To: "T.V Raman" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 31 08:02:27 2021 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 1lRTvu-0009Wl-Re for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Mar 2021 08:02:26 +0200 Original-Received: from localhost ([::1]:56060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRTvt-0007eb-Rt for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Mar 2021 02:02:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRTvG-0007EM-T0 for emacs-devel@gnu.org; Wed, 31 Mar 2021 02:01:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54693) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRTvG-0003NB-Fg; Wed, 31 Mar 2021 02:01:46 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2724 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRTvF-0008LZ-2L; Wed, 31 Mar 2021 02:01:46 -0400 In-Reply-To: (raman@google.com) 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267207 Archived-At: > From: "T.V Raman" > Cc: Cl¨Śment Pit-Claudel , > emacs-devel@gnu.org > Date: Tue, 30 Mar 2021 13:53:02 -0700 > > While all other things get discussed, could we perhaps have url.el be > updated to locally bind read-process-output-max to a larger value, say > 1mb? I don't think this would be TRT, because that variable affects all the communications with all the subprocesses running at that time. To do something less blunt, we need a per-process attribute. But that is only justified if indeed the effect in most scenarios related to url.el is profoundly positive. Just seeing the improvement in one synthetic test case is not enough for drawing project-wide conclusions about the default behavior, IMO.