From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sat, 30 Jul 2022 11:34:03 +0000 Message-ID: <65cb7c73fdc753518d35@heytings.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> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13230"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 30 13:35:13 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 1oHkkS-0003DX-6W for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 13:35:12 +0200 Original-Received: from localhost ([::1]:45970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHkkR-00025d-3q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 07:35:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50784) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHkkI-00025U-At for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 07:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44422) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHkkI-0002ED-22 for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 07:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHkkH-0000YM-TA for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 07:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Jul 2022 11:35: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.16591808462047 (code B ref 56682); Sat, 30 Jul 2022 11:35:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Jul 2022 11:34:06 +0000 Original-Received: from localhost ([127.0.0.1]:34171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHkjO-0000Wx-5o for submit@debbugs.gnu.org; Sat, 30 Jul 2022 07:34:06 -0400 Original-Received: from heytings.org ([95.142.160.155]:59012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHkjM-0000Wp-Kc for 56682@debbugs.gnu.org; Sat, 30 Jul 2022 07:34:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1659180843; bh=mLNyyfq73syCEDomCdHpny5AvJIJ/9YiY0qUKyNzkfE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=8r9xom1ALHTulE4Hi+DG3CHXHLzTgdlu/6Wa+As1CgA7IAhs/EKotNFnmUV7bZbKb MhzyGCQ7EJiHtd0UkCorDLvR2DoO/JAf6gvQi+JZeEBNUvfVKjLGeG8LZTTFgxw076 hae56cVS6fBtFMbfpDfaLhJlbmyszSDWaamgrWOGFZ8KJPClZzJee9+okK2FQxQaS8 9ZCteobxH4S5TwawVd8rbDprwsGg6WBEu5yJxKNe3CedTCYuS+2YQgQGoz4VjbD7qG kOXxKzF2CW0sk55JdAoDeBu1r3GvMrCDCmk0rOR4/gIQgfyTFRFCVfWYc5pOvq+Oxq DR7alV0Fsu0eQ== In-Reply-To: <83pmhn55sk.fsf@gnu.org> 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:238255 Archived-At: >> Actually that doesn't work correctly. A recipe: >> >> emacs -Q >> M-: (progn (set-frame-width nil 119) (set-frame-height nil 38)) RET >> C-x C-f dictionary.json RET y >> C-s aan SPC >> >> Now you'll see that the last line at the bottom of the window, which >> does not contain "aan ", is highlighted. Is the following okay from >> your point of view? > > I see the problem, but I don't understand how it could be related to > handle_fontified_prop. The highlight in this case is the isearch > highlighting of matches, and those are shown via overlays, not via face > text properties, so AFAIK handle_fontified_prop doesn't handle them. > > Do you understand the relation of this to handle_fontified_prop? > I cannot claim that fully understand what happens, but see below. What I do know is that that problem wasn't present before 9c12c3b7c5, and that it disappears with: diff --git a/src/xdisp.c b/src/xdisp.c index b1ee7889d4..8c62f088b8 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -4412,13 +4412,8 @@ handle_fontified_prop (struct it *it) ptrdiff_t begv = it->narrowed_begv ? it->narrowed_begv : BEGV; ptrdiff_t zv = it->narrowed_zv; ptrdiff_t charpos = IT_CHARPOS (*it); - if (charpos < begv || charpos > zv) - { - begv = get_narrowed_begv (it->w, charpos); - if (!begv) begv = BEGV; - zv = get_narrowed_zv (it->w, charpos); - } - Fnarrow_to_region (make_fixnum (begv), make_fixnum (zv), Qt); + if (begv <= charpos && charpos <= zv) + Fnarrow_to_region (make_fixnum (begv), make_fixnum (zv), Qt); } As far as I understand, what happens is this: 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. 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.