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: Mon, 01 Aug 2022 15:38:43 +0300 Message-ID: <83o7x42l64.fsf@gnu.org> References: <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> <83r1214uz5.fsf@gnu.org> <8c7321f2f39b7a28dd18@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33263"; 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 Mon Aug 01 14:40:25 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 1oIUif-0008W1-8a for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Aug 2022 14:40:25 +0200 Original-Received: from localhost ([::1]:36470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIUie-0004cC-8K for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Aug 2022 08:40:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIUiI-0004DK-Pw for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 08:40:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49858) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIUiI-0000r6-Fw for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 08:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIUiI-00022i-BA for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 08:40: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: Mon, 01 Aug 2022 12:40: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.16593575497747 (code B ref 56682); Mon, 01 Aug 2022 12:40:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 1 Aug 2022 12:39:09 +0000 Original-Received: from localhost ([127.0.0.1]:39598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIUhQ-00020s-Jb for submit@debbugs.gnu.org; Mon, 01 Aug 2022 08:39:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIUhM-00020H-Qc for 56682@debbugs.gnu.org; Mon, 01 Aug 2022 08:39:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48244) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIUhC-0000kV-N0; Mon, 01 Aug 2022 08:38:54 -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=7hMOsjiZtqj1G5n0LW2KKzx3KfGBBh9c8gjAUkH1yVE=; b=bfC+REyN5+WU t2sQe2fEHewm9sJYBv6WnlLGEzm8hh9GFxQ91rKePFeXOkx7/nkHGb2ZcJYvWmaQBROB05sxRxEFV Q/JYOkhTv6QxgUI4aZqNSqV7+e5Zj3GLcErDEsbGLxWgiWx6+M+GeLuZkTzN1SvBO8FWOcL7Y39Mo 4/ko9CP2wCa3ybovWti5ZuSqzuU06MSwrmrZ8MtulXVzjvJTMlKNH07Pa7MtVngFOIk8MYSs0cZWD 9NERL89RFMKyP6ApGns/SmtPguFpyZs8hnt35yPo+BN5VOT1cRe6dyjzwNrVHINxdYF+DI9VCocZm ngrnG3qoEqej3UdC5qvLLQ==; Original-Received: from [87.69.77.57] (port=4159 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 1oIUhC-0003KJ-5x; Mon, 01 Aug 2022 08:38:54 -0400 In-Reply-To: <8c7321f2f39b7a28dd18@heytings.org> (message from Gregory Heytings on Sun, 31 Jul 2022 22:54:00 +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:238423 Archived-At: > Date: Sun, 31 Jul 2022 22:54:00 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, > monnier@iro.umontreal.ca > > > 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. > > > > I admit I do not really understand your last two paragraphs, but I tried > to do what you suggested, and it doesn't seem to introduce regressions, so > I pushed it to the new feature branch. Thanks. I will try to explain some more; feel free to ask questions if something's still unclear. You can see in the sources that both init_iterator and start_display are many times called with 'struct it' that was used by the caller, so it could already have the narrowed_begv and narrowed_zv members initialized by the caller. If we discover that we want to recalculate these values, we'd then need to restore the previous value before we return, so that the caller will see the same values it used before the call. But we have no easy way of doing that, and moreover, cannot even detect that these members were initialized. The inability to detect that they were initialized is due to the fact that we don't initialize 'struct it' before we call init_iterator, and so these fields can originally have any arbitrary value. Which means, for example, that tests like this: if (current_buffer->long_line_optimizations_p) { if (!it->narrowed_begv <<<<<<<<<<<<<<<<<<<<<<<<<< || ((pos.charpos < it->narrowed_begv || pos.charpos > it->narrowed_zv) && (!redisplaying_p || it->line_wrap == TRUNCATE))) are not necessarily reliable, because we never initialize narrowed_begv to zero, AFAICT. Right? The other part of my reasoning is that callers of the display code which are outside redisplay could legitimately move the iterator far from point: think about pos-visible-in-window-p and its ilk. So, when we are not called by redisplay, I think it would be preferable to update the narrowing due to these considerations.