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: Sun, 31 Jul 2022 10:11:42 +0300 Message-ID: <83r1214uz5.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> <83fsii68o3.fsf@gnu.org> <65cb7c73fdf6704d19d5@heytings.org> <835yje62vz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33327"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: gregory@heytings.org, gerd.moellmann@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 31 09:13:11 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 1oI38Q-0008VY-Kh for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 09:13:10 +0200 Original-Received: from localhost ([::1]:42452 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oI38P-0004ri-Hn for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Jul 2022 03:13:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI38I-0004rY-I1 for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 03:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46565) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oI38I-0005bS-8j for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 03:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oI38I-0004Ns-3U for bug-gnu-emacs@gnu.org; Sun, 31 Jul 2022 03:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Jul 2022 07:13: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.165925152716789 (code B ref 56682); Sun, 31 Jul 2022 07:13:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 31 Jul 2022 07:12:07 +0000 Original-Received: from localhost ([127.0.0.1]:36313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI37P-0004Mj-Gu for submit@debbugs.gnu.org; Sun, 31 Jul 2022 03:12:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oI37L-0004ME-GE for 56682@debbugs.gnu.org; Sun, 31 Jul 2022 03:12:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51182) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oI37F-0005WO-BC; Sun, 31 Jul 2022 03:11:57 -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=P2bskg2tA+NzPZ9OZYLXuOKeVFKF7QGNexS5NT8dMhc=; b=q5QNXvD79C9g Kpe7urKPHsvyotKwf1Y4OORuwbq0nuJc0X+19K38V4Is/9KLoh1OV7jewULZk3TbW0nzPxF/rjlgq 6F6UaPczROJaC9JyXNoWafXoYX5EFtagjonu41shKvBnZ1fd16ZToGqUBg5RRV4mJu525AvRXCyDg hvCQ5VIHN6J9Nwe4sy/09XFFl96wNAvovDYFtnzrlMoS7XA88ZJjLgN3jPqukulEmIvuuMVteOb71 xXXkQzq2yz4d0ekHHOOTOhIBh74skftBJPxVSWfOHOQphqGVLHdPVzm5xusWGKeNvEtImWjRc9kfn lrVWa66AFbOeCzY31kcI5Q==; Original-Received: from [87.69.77.57] (port=2830 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 1oI37E-0007YJ-RA; Sun, 31 Jul 2022 03:11:57 -0400 In-Reply-To: <835yje62vz.fsf@gnu.org> (message from Eli Zaretskii on Sat, 30 Jul 2022 18:23:12 +0300) 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:238317 Archived-At: > Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, > monnier@iro.umontreal.ca > Date: Sat, 30 Jul 2022 18:23:12 +0300 > From: Eli Zaretskii > > > Date: Sat, 30 Jul 2022 13:31:42 +0000 > > From: Gregory Heytings > > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, > > monnier@iro.umontreal.ca > > > > So the only remaining question is whether it is necessary to recompute > > narrowed_begv and narrowed_zv in init_iterator: > > I tend to think we should, but let me think about this some more. Here are my thoughts. First, I think the setting of narrowed_begv and narrowed_zv should be done in 'reseat', not in init_iterator. The latter always calls the former when invoked to start iteration of buffer text, but we also call 'reseat' from other places, when we "jump" the iterator to a new place, potentially far from the last. If nothing else, this should help with truncate-lines, where using window_point is basically right only for the point's line. And currently, init_iterator computes and sets the narrowing even when we iterate on strings, which is unneeded and incorrect. Whether always to correct narrowed_begv and narrowed_zv if we are reseating to a position outside the narrowing, is a more complicated question. The basic problem here is that we don't have an easy way of restoring the previous narrowing (except by unwind_protect), and the display code sometimes calls init_iterator or start_display using the iterator that already has these members set by previous code, a situation which we currently cannot easily detect. However, when this code runs as part of redisplay, we generally don't expect the original narrowing to be insufficient, except perhaps in the truncate-line case. So I think we should correct narrowed_begv and narrowed_zv only if either the 'redisplaying_p' flag is reset (meaning the display code is being invoked outside of redisplay) or it->line_wrap == TRUNCATE. Comments? thoughts?