From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#56682: locked narrowing Date: Thu, 01 Dec 2022 20:49:18 +0000 Message-ID: <47153506021498df087c@heytings.org> References: <83lernc5gu.fsf@gnu.org> <83k076dd7d.fsf@gnu.org> <83czcyd8jf.fsf@gnu.org> <83a682d66r.fsf@gnu.org> <837d36ceno.fsf@gnu.org> <37dd2827f54f8bbda5e3@heytings.org> <735c1d5b-0d64-a8e1-3aaa-91fc0248abd3@yandex.ru> <97049541-f5b4-ed3b-b8de-7c0bdc86f0f5@yandex.ru> <6e305c9b-7702-133a-3347-f64db05ade3f@yandex.ru> <83mt89kt10.fsf@gnu.org> <834juglesn.fsf@gnu.org> <83r0xkjw5s.fsf@gnu.org> <83pmd3ioxx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6E39bTqZ8a" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25312"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 01 21:50:25 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1p0qVk-0006J2-Do for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Dec 2022 21:50:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0qVV-0002ZB-IZ; Thu, 01 Dec 2022 15:50:09 -0500 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 1p0qVQ-0002Y5-Bb for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 15:50:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p0qVN-0000EO-Vp for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 15:50:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0qVN-0001eK-SF for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 15:50:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Dec 2022 20:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.16699277636328 (code B ref 56682); Thu, 01 Dec 2022 20:50:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 1 Dec 2022 20:49:23 +0000 Original-Received: from localhost ([127.0.0.1]:41849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0qUk-0001e0-UB for submit@debbugs.gnu.org; Thu, 01 Dec 2022 15:49:23 -0500 Original-Received: from heytings.org ([95.142.160.155]:39736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0qUi-0001du-Q6 for 56682@debbugs.gnu.org; Thu, 01 Dec 2022 15:49:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1669927759; bh=OqN0rluh+frO5xYWB+S1K0CW/Zk31ew7EPeG+c1A6PI=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=RwsUzKpTxHbwcHnVF+LhLRnz1RtuEInrpvzyxVRMuZZFQfSqqlSTbfwFKW3n5lt/9 8y/ilvAQ8nb1Uo1vYXjRTknliL3kM1qaBAGIaSJ665KmOEYyV329nhho5LHYyyzKGG bu1LGNNJ2cwnM38mnZ4dkdDhoSW8lqdg1+N9hhGl8WSPTYbZks7grQzmQJ/H5SSB8N AfEt77VQJ4REbggi+bBnDIecxIFnLLtfvG0OcatB6ifBVFIoA5CNib0tDYP+3aoyE4 yUxXdmfMJ8RGYQwD0i5LhZ9TTC/9TTnB0lpOM60r9OZNUy6XXduzmIvMkjLouDwbPl R+Q1Xq0tIQ1Sg== In-Reply-To: <83pmd3ioxx.fsf@gnu.org> Content-ID: <4715350602df9071c5ad@heytings.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249668 Archived-At: --6E39bTqZ8a Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: <4715350602b4ddf9aaee@heytings.org> > > I still don't understand why we need to look beyond the current=20 > narrowing: we will never display anything outside of that. Why should=20 > we care about what happens in parts of the buffer that we don't display,= =20 > and thus cannot affect redisplay performance? > My plain English explanation is apparently not clear enough, so here is a= =20 recipe: 1. M-: (let ((large-file-warning-threshold nil)) (find-file "dictionary.jso= n") (narrow-to-region 4000000 4004000)) RET 2. C-x n w 3. Kaboom! >>> If we are going to narrow the buffer to PT =C2=B1 N characters, then=20 >>> searching inside slightly more than this region (say, twice more or 5= =20 >>> times more) should be enough, I think. It might fail in some=20 >>> borderline cases, but most files with very long lines have almost all= =20 >>> of their lines long, so I see no problem here. >> >> The intention when this detection mechanism was designed was explicitly= =20 >> to also support non-file visiting buffers, e.g. a shell buffer in which= =20 >> a user cat's a file with long lines. > > This takes a minor and insignificant aspect of the idea I presented and= =20 > ignores the main part. Please respond to the main ideas, not to=20 > inaccurate wording. > I'm sorry to hear you read it that way. It was not my intention, and it's= =20 not insignificant: the point I wanted to make is that it's important to=20 catch cases in which long lines are added into buffers that do not yet=20 contain long lines. So it's important to keep in mind that we're not only= =20 discussing _files_ with long lines, which is a case that could have been=20 easily caught by adding a check at the moment the file is read in. > > And most buffers with very long lines in real life do come from files,=20 > not from shell commands. So even here you take a relatively rare use=20 > case and make it more significant than it is. > That was a case that was explicitly discussed three months ago. We cannot= =20 suddenly decide that it's an insignificant one, or a not significant=20 enough one. And I do agree that it's less common in real life to have=20 long lines in comint buffers than to open files with long lines. Another= =20 example is an interpreter outputting a (large enough) bignum. >>> OTOH, "punishing" large buffers that have no long lines at all doesn't= =20 >>> strike me as a good balance. Your proposed patch will solve a=20 >>> particular use case, but it cannot solve all of them. >> >> Indeed, by definition no heuristic can solve all problems. > > I'm proposing what should be a better heuristic. > As far as I can tell, there are two possible ways to catch such=20 situations: 1. The first one is to _not_ use a heuristic, and to check in _each_=20 redisplay cycle whether a certain portion of the buffer around point=20 contains long lines. This adds a fixed cost to all calls to redisplay,=20 which four months ago did not seem TRT to do. 2. The second one is to use a heuristic, which is what we do now, and to=20 check from time to time, when the buffer contents have changed "enough",=20 whether the buffer now contains long lines. When the buffer is edited=20 with small changes between each redisplay cycle, which is what happens in= =20 the vast majority of cases, using that heuristic adds _no_ cost whatsoever= =20 to calls to redisplay. The cost is added to only a few calls to=20 redisplay, and it is not fixed anymore, it is more important for a large=20 buffer than for a small one. Doing that seemed TRT four months ago. > > That benchmark is an example of many use cases that can happen in real=20 > life, in a large buffer with no long lines and a lot of editing=20 > activity. I'm surprised you don't see it. > I don't see it, indeed. And I'm surprised that nobody complained about it= =20 during the last four months. Do you have a recipe with which I could see= =20 that effect? I just tried to edit dictionary-pp.json "heavily" (large=20 kills and yanks), and Emacs remained responsive, I did not experience any= =20 hiccups. Neither with emacs -Q nor with my config. (Of course, that was= =20 with the patch applied.) > > The main issue at hand is how to avoid needless scanning of the entire=20 > buffer for long lines, something which doesn't scale well with buffer=20 > size. For very large buffers without any long lines, this is a=20 > regression in Emacs 29, because Emacs 28 didn't do that. IOW, we make=20 > "good" buffers suffer because of the (rare) danger presented by=20 > potentially "bad" buffers. We need to look for ways of making this=20 > degradation as small and as rare as possible. > Yes, it's a compromise. As I explained above, the only other possible=20 compromise that is safe enough is to make _all_ buffers "suffer" (but=20 suffer less). --6E39bTqZ8a--