From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sat, 30 Jul 2022 03:16:29 -0400 Message-ID: References: <837d46mjen.fsf@gnu.org> <8a3eaeef01be5bfaa5ef@heytings.org> <05388e8d8812bfa3695d@heytings.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4040"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56682@debbugs.gnu.org, Eli Zaretskii To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 30 09:17:31 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 1oHgj5-0000sE-4R for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 09:17:31 +0200 Original-Received: from localhost ([::1]:44790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHgj3-0007me-Gz for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 03:17:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHgic-0007ln-OG for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 03:17:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44191) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHgic-0007KM-Ft for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 03:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHgic-0003ds-Bp for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 03:17:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Jul 2022 07:17: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.165916540613974 (code B ref 56682); Sat, 30 Jul 2022 07:17:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Jul 2022 07:16:46 +0000 Original-Received: from localhost ([127.0.0.1]:33940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHgiL-0003dJ-LQ for submit@debbugs.gnu.org; Sat, 30 Jul 2022 03:16:46 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHgiH-0003cy-OK for 56682@debbugs.gnu.org; Sat, 30 Jul 2022 03:16:44 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2AB04100502; Sat, 30 Jul 2022 03:16:35 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F054F100169; Sat, 30 Jul 2022 03:16:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1659165393; bh=NYIZ5BygY0arg7hLRbFiIpcJ4CXhNyVv2ItDBKuXzHs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lHdAPCat66khJ3PAE1UI0x1CQguWhJQp8h1Q9THoJs7cZ6cMa8k+KtePVh6Q8LEMJ 0jHRexWWgo1lJhg4RzRQ9lVu5AiV4bsin2v9KFZ0H2WRA3DB7bw2W5hjt/p7nhs+UO mo+tTzSccQdYHJe4BdZcrJNONZYEzjuXZnaNJ9zKukdLK6F92oZ9geHQ8hWiacH3m9 F7RM5TN4o4oULi/UWl8Q1S30252XNj+iPJCZ7WR7OPHuZPJB5tV6QlXtd9ucnVhCXi q2swn/mrrOIUazZcwVP1q3d6IuMbFfmGYSw/OWOao1dB6LgPD/pXatxSbIhMA6ewbl rl1iuxs3jX8tw== Original-Received: from milanesa (dyn.144-85-173-129.dsl.vtx.ch [144.85.173.129]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 334A1120388; Sat, 30 Jul 2022 03:16:32 -0400 (EDT) In-Reply-To: <05388e8d8812bfa3695d@heytings.org> (Gregory Heytings's message of "Wed, 27 Jul 2022 06:44:53 +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:238235 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. 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. > The only way to make sure that the size of the text is small > enough is a forced narrowing from which fontification-functions > cannot escape. It's clearly not the only way, nor is it an absolute guarantee. I agree that it's a convenient way, tho. > But let's try to be constructive. You tell me that you're not opposed to > reducing the size of the text, and that font-lock.el could enforce > a smaller scope. So could you please design a (Elisp) function (in > font-lock.el) which, given a (beg end) with beg <= end in a buffer, returns > a (beg' end') with beg <= beg' <= end' <= end that are better starting end > end points for the forced narrowing? That function would be run in > handle_fontified_prop, before fontification-functions, and would have > access to the whole buffer. That can't be done. 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. 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`). >>> Think of it as POSIX's ulimits. >> That's also a blunt tool. > It isn't either. Maybe we don't use the same meaning for "blunt". What I mean is that it's a tool whose effect cannot be fine-tuned for specific cases. E.g. limiting the amount of memory used to store images, or the amount of time spent in a particular operation, rather than applying those limits to the whole process (even all its children as well). > It's a practical way to limit what a single process can do Yup, I use it too, but it's a one-size fits all. Eli wrote: > Feel free to suggest better ways of handling these issues, or even > ways to solve this entirely inside font-lock. If and when such > suggestions materialize, I'm sure we will be glad to use them instead > of less elegant/more direct solutions. I'd suggest to keep things mostly as they are but move the decision to ELisp: i.e. pass the beg..end limits to jit-lock and let jit-lock do the narrowing. This way it's easy to later refine the mechanism. Stefan