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: Fix the long lines font locking related slowdowns Date: Sat, 30 Jul 2022 16:18:20 +0300 Message-ID: <83fsii68o3.fsf@gnu.org> References: <83bktghrn0.fsf@gnu.org> <8a3eaeef010995a5da8d@heytings.org> <837d40ds09.fsf@gnu.org> <83zggwcby5.fsf@gnu.org> <83o7xccagi.fsf@gnu.org> <831qu7daxb.fsf@gnu.org> <83sfmnb7yg.fsf@gnu.org> <837d3ybh5z.fsf@gnu.org> <136c4fe0fc74196714aa@heytings.org> <83pmhp89ov.fsf@gnu.org> <136c4fe0fc39573addc9@heytings.org> <83k07x8738.fsf@gnu.org> <136c4fe0fcdf00ef9a11@heytings.org> <83h73183r7.fsf@gnu.org> <136c4fe0fc0fceb0d752@heytings.org> <838roc8ka7.fsf@gnu.org> <83tu706obt.fsf@gnu.org> <83h7306ifa.fsf@gnu.org> <83edy37pul.fsf@gnu.org> <83pmhn55sk.fsf@gnu.org> <65cb7c73fdc753518d35@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9451"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 30 15:19:14 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 1oHmN8-0002Kf-BD for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 15:19:14 +0200 Original-Received: from localhost ([::1]:42702 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHmN7-0004ES-Am for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 09:19:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHmMy-0004Di-Jz for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 09:19:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44570) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHmMv-000205-Pt for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 09:19:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHmMv-0001NF-MN for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 09:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Jul 2022 13:19: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.16591871235255 (code B ref 56682); Sat, 30 Jul 2022 13:19:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Jul 2022 13:18:43 +0000 Original-Received: from localhost ([127.0.0.1]:34318 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHmMc-0001Mh-Pd for submit@debbugs.gnu.org; Sat, 30 Jul 2022 09:18:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHmMY-0001MC-Se for 56682@debbugs.gnu.org; Sat, 30 Jul 2022 09:18:39 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35798) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHmMT-0001y2-IV; Sat, 30 Jul 2022 09:18:33 -0400 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=PyC6bPaISAZRmCfysNQdYrdG+79zlF3AwvUXTRaKprM=; b=QuQ/3g5z0EPx Fo93qDI9CnY0jYGJt28fh7PvG8KOSAWhJ2stBrn6X50p6FlP7xd51nuNcnw6UROVmZ+XJ4ki9OzwQ eMXgSMsPAUmi8J+6WGpYSsRlxEXlCV3RH/MlY7cA+L9dVYRHJN+TZX/HyUZi9VpXQGUwqH0GP1n0s nqtoft14JDxyL4q4//hfoOr1AOAHbo4dKUw+l8EiFPXbxkvZUS2WYo9hMOJnOpBAW1MEdeIyT+iW6 Em/7DrXCo6ADOJNOdqAdieLWJ3OYtjiu+WSXcOT+PAp+L7c/wBIENM8YDJlUHNjppiPx5JeoLa+pP LzfEGlc4cWn7q+/O2tYadg==; Original-Received: from [87.69.77.57] (port=4507 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 1oHmMQ-0001U3-KX; Sat, 30 Jul 2022 09:18:33 -0400 In-Reply-To: <65cb7c73fdc753518d35@heytings.org> (message from Gregory Heytings on Sat, 30 Jul 2022 11:34:03 +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" Xref: news.gmane.io gmane.emacs.bugs:238274 Archived-At: > Date: Sat, 30 Jul 2022 11:34:03 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, > monnier@iro.umontreal.ca > > C-s aan SPC RET positions point at 730072. When typing C-s aan SPC in a > not yet fontified buffer, it->narrowed_begv and it->narrowed_zv are > correctly positioned around that position, at 706860 and 732564 > respectively. But the iterator is late, and is still at the position at > which it was after C-s aan (without SPC); the first occurrence of "aan" is > at 152274, the corresponding narrowing bounds are 128520 and 154224, which > means that it has stopped at 154224. So if we "reseat" the narrowing for > fontification-functions around the position 154224 of the iterator, the > narrowing becomes 141372-167076, which is well before the position of "aan > ", namely 730072. At that point, isearch has found a match, and puts the > match overlay at 167076 (the last possible position of the narrowed > portion) and beyond, instead of putting it at 730072. What I see is that isearch puts the match overlay on text that starts at 167076 and ends at 730068 (the latter is the beginning of the match), instead of on text between 730068 and 730072. > In short, it seems to me that using the position of the iterator is a too > fragile solution, and that it is better to not apply a narrowing when the > iterator is outside of the narrowing bounds. But this means we give up on the narrowing, which means the display could be very slow. And I've found the culprit: we weren't restoring point after lifting the locked narrowing. narrow-to-region can move point if the new restriction puts point outside of the region. So what was happening is that isearch-update was calling pos-visible-in-window-group-p to see whether the match is visible, and that call would move point from under the feet of isearch-update, because pos-visible-in-window-p calls display routines. So any subsequent uses of point would use a completely wrong value of point. I've now made narrow-to-region preserve point across locked narrowing, and the problem went away. Ugh! this one was a bitch to debug!