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#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling) Date: Tue, 16 Aug 2022 14:55:56 +0300 Message-ID: <83y1voflmb.fsf@gnu.org> References: <87bksmx1j1.fsf@localhost> <5900f208367791fbdfe2@heytings.org> <83bksmka08.fsf@gnu.org> <325f95fd2b7c0cc80613@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14951"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57207@debbugs.gnu.org, yantar92@gmail.com To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 16 13:57:47 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 1oNvCc-0003iI-Ag for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 13:57:46 +0200 Original-Received: from localhost ([::1]:39686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNvCb-00009d-Cf for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 07:57:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNvBv-00082A-Ei for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 07:57:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55393) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNvBu-0005gb-CZ for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 07:57:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNvBu-0007JA-9Q for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 07:57: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: Tue, 16 Aug 2022 11:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57207 X-GNU-PR-Package: emacs Original-Received: via spool by 57207-submit@debbugs.gnu.org id=B57207.166065097728031 (code B ref 57207); Tue, 16 Aug 2022 11:57:02 +0000 Original-Received: (at 57207) by debbugs.gnu.org; 16 Aug 2022 11:56:17 +0000 Original-Received: from localhost ([127.0.0.1]:45141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNvBB-0007I2-1U for submit@debbugs.gnu.org; Tue, 16 Aug 2022 07:56:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNvB8-0007Ho-Fg for 57207@debbugs.gnu.org; Tue, 16 Aug 2022 07:56:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50720) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNvB2-0005eB-V0; Tue, 16 Aug 2022 07:56:08 -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=YTB9lpFdRQGh+vmfKpksQrq1Tn0lNo2Z/qwFZJbVdH4=; b=n33IAk7UCZXa ohyhCEod/To95XXNYxZmkVv4i5Y63Ji7HrFKPsoDmRwPKc6cw6/j83TcJ5tfAkIotugtsVgG7ISRu B0XHk2/U82XYwn7itRmVHAGGD42mVNQEagIzquqq6uwRZQzBHEzcqjbGjRcedd7H/WUFqabHgAaSO oIMcYSwZehYKuDAJnWrhvzt6WC+TnWyk6S2oOh6eoHNkNFNIGmxTqCIiF/9xrF/OP+Q9VqXE0bh9Z CI6SVlPu1CHysLN8pDMQ9Rv4SMhGiVI6SYBmzpPf4xqWiVWtYVw/p2y9dqAeGVpXUYhBhsmD8KyvK yCKNpqBPXQH+MejWxUa6kA==; Original-Received: from [87.69.77.57] (port=4923 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 1oNvB1-0006Z3-Ux; Tue, 16 Aug 2022 07:56:08 -0400 In-Reply-To: <325f95fd2b7c0cc80613@heytings.org> (message from Gregory Heytings on Tue, 16 Aug 2022 10:47: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:239904 Archived-At: > Date: Tue, 16 Aug 2022 10:47:00 +0000 > From: Gregory Heytings > cc: yantar92@gmail.com, 57207@debbugs.gnu.org > > > Gregory, I suspect that the problem could be in the loop in > > redisplay_window, where we look for long lines. Changing visibility in > > Org changes text properties, and that causes MODIFF to be incremented. > > I actually can cause something similar without Org at all, just by > > scrolling fast through xdisp.c. You can put a breakpoint inside the > > 'if' that guards the re-evaluation of the long-lines in > > redisplay_window, and scroll with C-v through xdisp.c immediately after > > visiting it -- I hit the breakpoint from time to time, although there > > are no changes to the buffer except faces placed by fontifications. > > > > jit-lock runs under with-silent-modifications, but that only adjusts > > SAVE_MODIFF to create an illusion of unchanged buffer, it doesn't affect > > UNCHANGED_MODIFIED. > > > > Indeed, that's problematic: modify_text_properties calls modiff_incr > (&MODIFF, 1). I think the safest change would be to use CHARS_MODIFF > instead of MODIFF, see attached. As I said earlier, I've changed my mind about this after I wrote the above. We update UNCHANGED_MODIFIED in mark_window_display_accurate_1, so if the window completes its redisplay cycle "normally", whatever jit-lock does shouldn't matter for the next redisplay cycle, because UNCHANGED_MODIFIED will be updated from MODIFF. Maybe Org does something that frequently causes a window's redisplay cycle to end prematurely, in which case the code that looks for long lines could be called too frequently. But in that case, your proposed change will have the same problem, I think? What I don't understand is why enlarging the value of the threshold causes Emacs to "hang". If it really is some kind of infloop, I cannot understand how issues like outdated UNCHANGED_MODIFIED could cause that only for some value of the threshold, but not for a smaller value. I thought perhaps there are lines longer than 10000 characters, but none beyond 100000, but this turns out to be false, so with both values of the threshold that loop in redisplay_window should have scanned the entire buffer top to bottom in both cases... So I suspect something else is at work here.