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 16:45:03 +0300 Message-ID: <83a68o2i3k.fsf@gnu.org> References: <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> <83o7x42l64.fsf@gnu.org> <83edy02j2n.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16463"; 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.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 01 15:55:36 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 1oIVtP-00049E-Lx for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Aug 2022 15:55:35 +0200 Original-Received: from localhost ([::1]:56738 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIVtN-0004My-Ln for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Aug 2022 09:55:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36572) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIVkA-0003Sn-Af for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 09:46:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50047) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIVk9-0005HT-Rz for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 09:46:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oIVk9-00067x-O1 for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 09:46: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: Mon, 01 Aug 2022 13:46: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.165936152923504 (code B ref 56682); Mon, 01 Aug 2022 13:46:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 1 Aug 2022 13:45:29 +0000 Original-Received: from localhost ([127.0.0.1]:39796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIVjc-000671-Vb for submit@debbugs.gnu.org; Mon, 01 Aug 2022 09:45:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oIVjb-00066n-CR for 56682@debbugs.gnu.org; Mon, 01 Aug 2022 09:45:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49866) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIVjV-0005BL-R4; Mon, 01 Aug 2022 09:45:21 -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=st7tWvI0QcOixXI0WzAbTHPNQQ9rdA/6BrDfLVli9IY=; b=V/uH9Q6wFfM/ 7zIwcnNFUIyE6SAwk9NmjDuEtLVLM2ms70VEcJBnsH+6Vbawd/JHBb0HWGZyYk6I42yuzXLIihr1Y 0sBTgINiAcoRc+zGLiKpHl1jHjZU+iKr2fbnAHV2RgbP5UBHw6H8Fq2yyHf/1FHxTg+nWy0f8Va1D u1l2nTILMfDa42ajK5ccIdKMiJecgQQThompB79xYCgJu2C5JDqg9WnePmFXXA+zZfMuAz/8GDncD ZNnveLgM0e311CCPfMPgwSzShnsSKIO2UVgP+wIydtDGigpCVGeJRvEqPm6WfwD8ECLuhkDQRqrIf nL6j1fcXcN9Llljd3Zjn+Q==; Original-Received: from [87.69.77.57] (port=4289 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 1oIVjR-0004hu-2r; Mon, 01 Aug 2022 09:45:21 -0400 In-Reply-To: <83edy02j2n.fsf@gnu.org> (message from Eli Zaretskii on Mon, 01 Aug 2022 16:24:00 +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:238442 Archived-At: > Date: Mon, 01 Aug 2022 16:24:00 +0300 > From: Eli Zaretskii > Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, > monnier@iro.umontreal.ca > > > diff --git a/src/xdisp.c b/src/xdisp.c > > index 8a19b3bda9..9574d06bd5 100644 > > --- a/src/xdisp.c > > +++ b/src/xdisp.c > > @@ -3472,6 +3472,9 @@ init_iterator (struct it *it, struct window *w, > > &it->bidi_it); > > } > > > > + if (current_buffer->long_line_optimizations_p) > > + it->narrowed_begv = 0; > > + > > Sorry, I wrote that this is OK, but it isn't: if init_iterator is > called with 'struct it' that was already initialized by a previous > call to 'reseat', the above will nuke the narrowing. > > So we need something more complicated. ATM I don't see how to solve > this without manually initializing narrowed_begv before the first call > to init_iterator or start_display. Hmm... I think we should simply unconditionally recompute the narrowing in 'reseat'. At least I couldn't think of a situation where that would cause trouble, and 'reseat' is called rarely enough not to make this expensive. Am I missing something? And another nit: 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))) { it->narrowed_begv = get_narrowed_begv (it->w, window_point (it->w)); it->narrowed_zv = get_narrowed_zv (it->w, window_point (it->w)); } } I think this should pass pos.charpos as the 2nd argument to get_narrowed_begv and get_narrowed_zv, otherwise it might not really correct anything, right? In particular, when lines are truncated, that will definitely happen when we display any line but the very first. Or perhaps we should check that using window-point indeed brings pos.charpos into the narrowed region, and only use pos.charpos if it doesn't?