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 13:17:25 +0000 Message-ID: <65cb7c73fd45b850af27@heytings.org> References: <837d46mjen.fsf@gnu.org> <8a3eaeef01be5bfaa5ef@heytings.org> <05388e8d8812bfa3695d@heytings.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="5255"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, Eli Zaretskii To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 30 15:18:18 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 1oHmME-0001B4-Ba for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 15:18:18 +0200 Original-Received: from localhost ([::1]:42142 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHmMD-0003ng-2V for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 09:18:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36192) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHmLy-0003nW-Rm for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 09:18:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHmLy-0001vP-JJ for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 09:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHmLy-0001LL-D0 for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 09:18:02 -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 13:18: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.16591870495119 (code B ref 56682); Sat, 30 Jul 2022 13:18:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Jul 2022 13:17:29 +0000 Original-Received: from localhost ([127.0.0.1]:34309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHmLQ-0001KU-WA for submit@debbugs.gnu.org; Sat, 30 Jul 2022 09:17:29 -0400 Original-Received: from heytings.org ([95.142.160.155]:59170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHmLP-0001KM-3a for 56682@debbugs.gnu.org; Sat, 30 Jul 2022 09:17:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1659187045; bh=2DLdhc1tCn/eO1O6770Qpd8AyCdSo7tsR+Oq/lGJJtU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=gewHmlakurKRM72g5WZYQYDsk4QX7I1cwgHgD07aPYQX4C1pVEdW7wizERIlOtg9v tPt10jeHrU0Y5giMUjQYkdFmk12u1qQ73HzkBtIE5X5OO9u/lP7MOeo6RGvPJVlMPc VSvm9Wrd/cQ6WxTvmLPDhkSiRyMhlarJH2ujNVMfGYOmFH8/h5rJ7do9Sbmda/ZPWW QgHrETVsvg98npF/3itJyx5Xl0xw94BpmT4BK7slWMXIzQq0i5fOt1jNVGb9X7v3OR qyS+5aSKsC120po/9kk5pJw176rg/ZcsQFw0fY+7a5nRhDKPUP29IH0XLs0Rr4s1sg dDTFMgSppfsrw== In-Reply-To: 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:238273 Archived-At: >>> I'm not opposed to reducing the size of the text that's considered, but >>> doing it via narrowing is a blunt tool. >> >> It isn't. > > There's no point arguing about it. I find it to be and you don't and > that's that. > Actually, with your explanation below that "blunt" means for you "cannot be fine-tuned", I agree with you. > > The reason why I find it to be is because it removes all possibilities > of making different choices for different elements depending on the cost > of those elements and the amount of available information. > With that I also agree. It would be better to have a refined decision method, but at the moment it doesn't exist. > > What I think would be a better option is to (somehow) pass the > `beg..end` "limit" to jit-lock which can then pass it on to its own > clients (e.g. font-lock) so they each can make their own choices. > I sent a patch a few hours ago in this thread. The limit of what you suggest is that its effect would depend on the goodwill of major and minor mode authors, which could decide to ignore these beg..end recommendations altogether. Whereas the point of that feature is more or less to protect Emacs users from major and minor modes, to make sure that Emacs remains responsive when the buffer contains long lines. Also, there are other users of fontification-functions besides jit-lock-function. (And for some reason the patch I sent does not give the results I would have expected, font-locking is still too slow, but it's perhaps a bug in the patch.) > > E.g. the syntax-ppss part of the job performed by font-lock is heavily > cached, does not depends on lines, is theoretically always computed from > BOB but with a cache which makes it fast even when working near EOB (tho > it can still be somewhat slow when jumping from BOB to EOB, but that > depends on the size of the buffer, not the size of lines). This part > *should* ignore your limits, which will make sure comments and strings > are recognized correctly at least in simple cases (i.e. cases which > don't depend on `syntax-propertize-function`). > I see. Do you see a way to somehow extract the syntax-ppss part out of font-lock? Would that be feasible? And another question: can syntax-ppss not be used to determine a "good starting position" for the narrowing, outside of any comments or strings (if possible)?