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: read-process-output-max Date: Thu, 01 Apr 2021 10:12:52 +0300 Message-ID: <83r1juh40b.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> <83zgyjj1yf.fsf@gnu.org> <83zgyjgsar.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28630"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, raman@google.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 01 09:14:04 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 1lRrWm-0007La-7y for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 09:14:04 +0200 Original-Received: from localhost ([::1]:56100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRrWl-0007MU-A9 for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 03:14:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49774) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRrVu-0006lp-LD for emacs-devel@gnu.org; Thu, 01 Apr 2021 03:13:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49259) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRrVt-0003CN-TE; Thu, 01 Apr 2021 03:13:09 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4632 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRrVt-00078n-9s; Thu, 01 Apr 2021 03:13:09 -0400 In-Reply-To: (message from Stefan Monnier on Wed, 31 Mar 2021 19:05:59 -0400) 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:267236 Archived-At: > From: Stefan Monnier > Cc: raman@google.com, cpitclaudel@gmail.com, emacs-devel@gnu.org > Date: Wed, 31 Mar 2021 19:05:59 -0400 > > > Another potential issue, in programs that display the arriving stuff > > as it is received, is that showing the text in small chunks is > > generally better (UX-wise) than blasting a 1MB chunk of text to the > > screen in one go. > > If 64kB already arrived, will part of the result really reach the eyes > of the user faster if we process them as 16 chunks of 4kB or do we skip > redisplay between the chunks (just like we skip redisplay when there > are pending input events)? The result of inserting large chunks of text into a buffer that's displayed will be a continuously scrolling window, whereas if we do that in smaller chunks, the text will be static for long enough to allow at least some of it being read (at least with the default scrolling behavior). I think the latter is less annoying, at least in some use cases (think the likes of "M-x compile" and "M-x grep"). > [ BTW, I think a value >=32kB would be desirable since it avoids > breaking UDP datagrams. ] If we want to do that, we should bump the alloca threshold in SAFE_ALLOCA higher, it is currently set at 16KB.