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.bugs Subject: bug#56682: locked narrowing Date: Thu, 01 Dec 2022 09:05:30 +0200 Message-ID: <83pmd3ioxx.fsf@gnu.org> References: <83o7wjc6o2.fsf@gnu.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36748"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 01 08:07:27 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 1p0dfK-0009M0-AX for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Dec 2022 08:07:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0df4-0002e4-OP; Thu, 01 Dec 2022 02:07:10 -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 1p0df0-0002cF-R1 for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 02:07:09 -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 1p0df0-0004aS-Iy for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 02:07:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0dew-0005WX-EF for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2022 02:07:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Dec 2022 07:07:02 +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.166987837121223 (code B ref 56682); Thu, 01 Dec 2022 07:07:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 1 Dec 2022 07:06:11 +0000 Original-Received: from localhost ([127.0.0.1]:37826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0de7-0005WF-8r for submit@debbugs.gnu.org; Thu, 01 Dec 2022 02:06:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38160) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0de4-0005Vz-C1 for 56682@debbugs.gnu.org; Thu, 01 Dec 2022 02:06:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0ddw-0004Lm-I3; Thu, 01 Dec 2022 02:06:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=QbeieaEITqPIbr/wb60qgVZ1vmd8y0fRUKcb5iXQ0kY=; b=fpqrAo7qGyKVlJN9pFEf 27TZ7rYaVY+ogjwTm2BFonYg9xi6w8YCDQQxGGSmYBdw41X0ObSQdaPITtpQLEWWzPPZnqBOj1Kag 64E8AJi8vr5Y2UJSOwXf6CKmBZbKq0Gt3id15EvxVKvilwrZ1B8qdNVBmvsr6pejCW0osOxOuM+Wm sWPJz00LeCTWC9wdnIvQ9GIBnYsSpA9IHHpbmcptwDSJqteVyflCrwHvNdCOAdtGPa3KlKfSfLNlc yoxs8m+jYrn4orbkRvodYh8O1768GtASo4zigzw3PbNT4o1YGr6/z+ipyCpRLTZLIb1OZOE9pLBLU qbbf26c9RhncgA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0ddv-0003Wt-Pt; Thu, 01 Dec 2022 02:06:00 -0500 In-Reply-To: (message from Gregory Heytings on Wed, 30 Nov 2022 22:09:59 +0000) 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:249597 Archived-At: > Date: Wed, 30 Nov 2022 22:09:59 +0000 > From: Gregory Heytings > cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru > > I had to refresh my memory about this, and I think there is a > misunderstanding here: we check whether a buffer contains long lines only > when it is about to be redisplayed and its contents have changed enough > since the last time it was displayed. What happened between these two > redisplays can be anything, e.g. it could be a buffer that has not been on > display during an hour and that has been filled by a process in the > meantime. Using BEGV/ZV is wrong, again because we don't know what > happened between these two redisplays, it could have been filled by a > process and narrowed, and if after switching to that buffer the user > widens it, Emacs would become unresponsive. Or it could be a buffer that > has been emptied in the background by a command, filled with the contents > of a file, and narrowed to some portion of that file (e.g. a single hunk > of a diff file); again if the user widens it to look at the whole file, > Emacs will hang. The only safe way to be certain that a buffer does not > contain long lines is to check the whole buffer. I still don't understand why we need to look beyond the current narrowing: we will never display anything outside of that. Why should we care about what happens in parts of the buffer that we don't display, and thus cannot affect redisplay performance? And again, there are technical problems with doing that without a call to 'widen' -- this is why I made that change: it caused trouble in some situation that I no longer recall. If you want to argue for looking at the entire buffer, you will have to insert a call to 'widen' there, otherwise the code which does that will not be safe. And in any case, the BEG vs BEGV issue is secondary here. My main worry is valid for buffers without any narrowing at all -- in fact, especially for those. So let's leave the BEGV issue alone, or discuss it separately. here it is just a tangent. > > If we are going to narrow the buffer to PT ± N characters, then > > searching inside slightly more than this region (say, twice more or 5 > > times more) should be enough, I think. It might fail in some borderline > > cases, but most files with very long lines have almost all of their > > lines long, so I see no problem here. > > The intention when this detection mechanism was designed was explicitly to > also support non-file visiting buffers, e.g. a shell buffer in which a > user cat's a file with long lines. This takes a minor and insignificant aspect of the idea I presented and ignores the main part. Please respond to the main ideas, not to inaccurate wording. And most buffers with very long lines in real life do come from files, not from shell commands. So even here you take a relatively rare use case and make it more significant than it is. > > OTOH, "punishing" large buffers that have no long lines at all doesn't > > strike me as a good balance. Your proposed patch will solve a > > 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. > > When modiff becomes large enough, we will search again, and the > > threshold of 8 is not so large to prevent it from happening frequently > > enough to be an annoyance. > > Please, let's not throw away something that was designed with care and > about which literally no one complained since it was introduced, for the > sole reason that an artificial benchmark shows a slowdown of ~80 > milliseconds in a 30 MB buffer. That benchmark is an example of many use cases that can happen in real life, in a large buffer with no long lines and a lot of editing activity. I'm surprised you don't see it. > And note that it's not "modiff becomes large enough", it is "modiff > changed enough between two redisplays". Once again, a useless argument about a problem with inaccurate wording. Do you really think I don't understand how modiff works in this case? Why waste energy and bandwidth on such tangents? Let's focus on the main issue at hand. The main issue at hand is how to avoid needless scanning of the entire buffer for long lines, something which doesn't scale well with buffer size. For very large buffers without any long lines, this is a regression in Emacs 29, because Emacs 28 didn't do that. IOW, we make "good" buffers suffer because of the (rare) danger presented by potentially "bad" buffers. We need to look for ways of making this degradation as small and as rare as possible. > > That annoyance will be for no good reason in buffers that have no long > > lines. > > It's not "for no good reason", it's for an excellent reason: it's the > price to pay to ensure that Emacs remains responsive in as many cases as > possible. It will be very hard to explain this "price" to users who never have to deal with very long lines. We must look for every way of making the price lower. > And it's not an annoyance, for all basic editing commands the detection > loop will not run. It will run whenever redisplay discovers that a window needs an update on display, and there was enough changes in buffer text since last redisplay. It should be clear that with low enough threshold for text changes, this could happen quite frequently. > > If you are still unhappy with such a simple heuristics, we could go with > > something slightly more complex, like change the threshold of modiff > > dynamically based on the buffer size and perhaps the number of times we > > already searched without finding long lines -- the larger these two are, > > the higher we could bump the threshold. > > I don't see how such a heuristic could catch a case such as a user cat'ing > a file with long lines in a shell buffer. The modiff value will change by a large delta, because it basically counts the number of characters inserted since last redisplay, right? So the difference CHARS_MODIFF - UNCHANGED_MODIFIED will change by a large value, and will exceed even a higher threshold. AFAIU, this should solve the case you present here.