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: Fri, 02 Dec 2022 09:49:44 +0200 Message-ID: <834juegs87.fsf@gnu.org> References: <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> <47153506021498df087c@heytings.org> <83bkomhlmn.fsf@gnu.org> <4715350602cf2ec6860b@heytings.org> <83a646hkat.fsf@gnu.org> <47153506028bbb3bc8b3@heytings.org> <47153506021115866615@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17847"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, gregory@heytings.org, dgutov@yandex.ru To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 02 08:51:30 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 1p10pW-0004Sb-6j for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 02 Dec 2022 08:51:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p10pJ-0002NJ-VZ; Fri, 02 Dec 2022 02:51:18 -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 1p10p5-0002MC-4V for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2022 02:51:05 -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 1p10p4-0000gy-3D for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2022 02:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p10p3-0003FU-QQ for bug-gnu-emacs@gnu.org; Fri, 02 Dec 2022 02:51:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Dec 2022 07:51: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.166996742112480 (code B ref 56682); Fri, 02 Dec 2022 07:51:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 2 Dec 2022 07:50:21 +0000 Original-Received: from localhost ([127.0.0.1]:45022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p10oO-0003FE-Jk for submit@debbugs.gnu.org; Fri, 02 Dec 2022 02:50:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p10oM-0003F5-7K for 56682@debbugs.gnu.org; Fri, 02 Dec 2022 02:50:19 -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 1p10oF-0008RJ-AC; Fri, 02 Dec 2022 02:50:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=it6UtghwcWBe2pXMk7udM3oZpDIGxycGvfpt5ogmSs8=; b=cGhOWOFOu18x uucofuDO+bU3SwYf9yl8gbgI+vnBe9VsUYpvbAHM89XnrOqs8oOscwm98mwzJ4QOls7oYB/L8GgfB 1+5XBzoqWRMyOzKBftgbQ3k0X76lYyX66HgWpyzwNjus5P3vGKHXZ3TJJN9fyt0FKxkBwd6IAbTcq kLa4L1B+Yv2gVgG15Ai1784JQzaRKwUBBNZJT11j59QvBHBNa7/3+AU2tylskI0zcflCHPR400rGV 4EVgCpE0xOBawuLUeuhP/YsOexwDt9Uuua6A4ZIqVujWB5iGw/TFpXAO7XkvSUOszSaw7mNXN7aqE 46wxqJdcmoJDA/oxeQKnHQ==; 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 1p10oE-00039J-Q5; Fri, 02 Dec 2022 02:50:11 -0500 In-Reply-To: (message from Stefan Monnier on Thu, 01 Dec 2022 18:48:26 -0500) 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:249710 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , 56682@debbugs.gnu.org, dgutov@yandex.ru > Date: Thu, 01 Dec 2022 18:48:26 -0500 > > Do an initial scan on the whole buffer and after that keep a BEG..END > limit approximating the region that has been modified since the last scan. We currently don't have any way of telling what was modified since the last scan. > As long as > > END - BEG < LINE_LENGTH_THRESHOLD - MAX_SEEN_LINE_LENGTH > > then we know we don't need to rescan anything at all. And when we do > need to rescan we can limit the scan to > > BEG - MAX_SEEN_LINE_LENGTH ... END + MAX_SEEN_LINE_LENGTH > > I assume here that we would remember the MAX_SEEN_LINE_LENGTH. I hope we can come up with a less complicated scheme. We only need to know whether there are long lines in a region around point that is large enough to make sure redisplay won't look beyond that. (Gregory disagrees, but I have yet to see a reason why he would be right and I would be wrong in this matter.) We know where the window's point was at the time of the last redisplay, so we can detect when point moves "too far", and trigger rescanning of the region around the new location of point -- this should be a condition in addition to those that currently guard the rescanning loop. Given the above, if the region we actually scan is not the entire BEGV..ZV one, but has its size limited from above by some fixed value, the scanning should scale much better for very large buffers, because the scanning loop will never run more than a fixed upper bound of time. The limit on the region can be large enough to be safe, because the scan is very fast. So only extremely large buffers will not have all of their accessible portion scanned, which is consistent with other measures we take to limit potentially long processing using more or less arbitrary limits, like syntax-wholeline-max, MAX_PARAGRAPH_SEARCH in bidi.c etc. The result is potential inaccuracy and/or degradation, but only in very rare cases.