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#57207: 29.0.50; Fontification is slow after e7b5912b23 (Improvements to long lines handling) Date: Tue, 16 Aug 2022 12:17:10 +0000 Message-ID: <325f95fd2bce114fd74d@heytings.org> References: <87bksmx1j1.fsf@localhost> <5900f208367791fbdfe2@heytings.org> <83bksmka08.fsf@gnu.org> <325f95fd2b7c0cc80613@heytings.org> <83y1voflmb.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="20172"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57207@debbugs.gnu.org, yantar92@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 16 14:20: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 1oNvYI-0004t7-Ew for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 14:20:10 +0200 Original-Received: from localhost ([::1]:44618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNvYH-0001p7-CI for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 08:20:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNvWE-0000ts-5z for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 08:18:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55418) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNvWD-0000LX-Su for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 08:18:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNvWD-0007pI-OO for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 08:18: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: Tue, 16 Aug 2022 12:18:01 +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.166065223430034 (code B ref 57207); Tue, 16 Aug 2022 12:18:01 +0000 Original-Received: (at 57207) by debbugs.gnu.org; 16 Aug 2022 12:17:14 +0000 Original-Received: from localhost ([127.0.0.1]:45167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNvVS-0007oL-1s for submit@debbugs.gnu.org; Tue, 16 Aug 2022 08:17:14 -0400 Original-Received: from heytings.org ([95.142.160.155]:55712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNvVQ-0007oC-Lt for 57207@debbugs.gnu.org; Tue, 16 Aug 2022 08:17:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1660652231; bh=DZFUnWb7Lv8/HAsiU4NX+Hu5IihfeXz/MvTwxocA6Bg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=QuOobmETWnwMdttASqDZpFLUoi2nVT/YSoTlBHtaDMzMR+SMtHMutZqa2/32yyzjI NzIzyVRrpGryrt04V8sCRGuOGZDSwzfFgDKaAjmNrNcmf21ltBy80iv9YSih2veA2r d2+AeWT2owOsg8I4ie2UvquNZuQmvDQd8Ze1CPPidhesMDmU5hes7MOZyTNUe3hzp7 l972aSJ9Qp/aHoZjUs0syJ7u0CJkyrUHi5NtY2RBgC7tyitQfuSX8vqOlMnTq+VXTZ 83KMyVqzQjhndKIucOvsg/vtVZZXOJ6AYvuq4pRU835MV616KVo3qYmPaS4yMUOxhX KnWwEGoXdT0rg== In-Reply-To: <83y1voflmb.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:239908 Archived-At: > > As I said earlier, I've changed my mind about this after I wrote the > above. > I did see that, yes. > > 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. > Hmmm... The fact is that using CHARS_MODIFF avoids rescanning the buffer when "too many" text properties are changed. With xdisp.c, the long lines detection code is not called anymore when scrolling through the (initially unfontified) buffer. The original bug description (additional delays between redisplay cycles in a large buffer) is probably caused by needlessly executing that long lines detection code, at least that's consistent with my earlier experiments. > > 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? > That's possible indeed, let's see what Ihor tells us. > > 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. > Yes, I suspect that this is another bug, separate from the original bug Ihor described. It might be a bug in find_newline1, in the backtrace he sent, find_newline1 returns 10568710 and later 9679581. It's not clear however if that's in the same loop (he asked gdb to "continue" between the two).