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: Wed, 30 Nov 2022 17:31:59 +0200 Message-ID: <83r0xkjw5s.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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27491"; 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 Wed Nov 30 16:33:22 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 1p0P5N-0006tv-R3 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Nov 2022 16:33:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0P58-0003gM-Hj; Wed, 30 Nov 2022 10:33:06 -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 1p0P57-0003gC-A1 for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 10:33: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 1p0P56-0005fC-Uu for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 10:33:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0P53-0006Ss-R4 for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 10:33: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: Wed, 30 Nov 2022 15:33: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.166982236224844 (code B ref 56682); Wed, 30 Nov 2022 15:33:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Nov 2022 15:32:42 +0000 Original-Received: from localhost ([127.0.0.1]:33467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0P4j-0006Se-NG for submit@debbugs.gnu.org; Wed, 30 Nov 2022 10:32:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0P4f-0006SX-Vz for 56682@debbugs.gnu.org; Wed, 30 Nov 2022 10:32:41 -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 1p0P4a-0005c7-18; Wed, 30 Nov 2022 10:32:32 -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=GXvzoH/q4/uYxVHl/ciJsJ0edks1l8lB7p75SdqDelI=; b=HJIHs/xTDLX8bHBNqM3j bQ4t9w3OAcH8Aj0izz6zlFvGJbE8R/GX0Pw4JK+o1k1KGCet9B21VxWNdjw8Ktz48+m3bYzPShyrW 2nJ5n493JJGQDkQ0ZevGG7q9ajWlJ+A5Ulxum4uu8GNCrhRjzBXH6a0QXN7abcZl8N3rXInAoOPA4 pkoW1BV0lovSydM3YMXjSxPr8L/+p8bqV7ASquzUKu6HnoV5tEUfXz8EGokbBzCv+as1JAed0N3Oa ZtlOUJd3VsfYO8+wQW/wlhez52I4dXrtuJxS5bhxOYDnfMmbxEEFjTfeLRwMaaV33SBudSNeBO2M1 v3gf9foVOdElYA==; 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 1p0P4Z-0006O4-E5; Wed, 30 Nov 2022 10:32:31 -0500 In-Reply-To: (message from Gregory Heytings on Wed, 30 Nov 2022 14:40:36 +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:249520 Archived-At: > Date: Wed, 30 Nov 2022 14:40:36 +0000 > From: Gregory Heytings > cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru > > > I don't think I understand why it should be problematic or unsafe to > > limit the same loop we have to a smaller region of the buffer. > > > > I see that you already changed the loop to scan from BEG to Z to only scan > from BEGV to ZV; somehow I missed that change. I don't think even that is > correct: a command could insert text in the buffer outside of BEGV/ZV. It could (although that would be an unusual thing to do), but that's immaterial: the display engine will never look outside of the restriction, and so searching beyond that is not useful. Moreover, safe code in Emacs cannot look beyond BEGV..ZV without calling 'widen', because various primitives and subroutines don't expect that and will barf sooner or later; that's why I made that change in the loop. > While limiting the loop to a smaller region of the buffer looks like a > reasonable thing to do, the question is: how can we determine that region? > And I don't see how this can be done, because the detection code is called > only when a buffer is about to be displayed, and at that moment we cannot > know where characters were inserted in the buffer. What the code does now > is "if enough characters have been inserted in the buffer since last > redisplay, check again whether the buffer contains long lines". 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. 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. 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. That annoyance will be for no good reason in buffers that have no long lines. 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. But I wonder whether this is justified. I'd say let's find a fixed value that works in all the examples we know about (we have about a dozen, I think), and leave it at that until someone reports a real-life problem with it.