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: Tue, 16 Aug 2022 10:22:40 -0400 Message-ID: References: <12348081660379417@sas2-a098efd00d24.qloud-c.yandex.net> <66bbbb95983414e79637@heytings.org> <83wnb9hadb.fsf@gnu.org> <395454dd-7238-c5d0-e924-2f65a186baa7@yandex.ru> <83r11hh4pm.fsf@gnu.org> <3a1232a17b09ce88af40@heytings.org> <4ebdfdc3-4aeb-7ebb-b5ba-43b5c9b0aaa1@yandex.ru> <3a1232a17b80387503f4@heytings.org> <881ac6c7-116c-49d0-8f19-4a3778260914@yandex.ru> <3a1232a17b37db7a2498@heytings.org> <3a1232a17bf656136616@heytings.org> <325f95fd2b09b959fddd@heytings.org> <325f95fd2b33afdbb5e6@heytings.org> <325f95fd2b4bf15b4058@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="10650"; 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 , Dmitry Gutov To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 16 16:23:10 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 1oNxTJ-0002W5-BR for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 16:23:09 +0200 Original-Received: from localhost ([::1]:60978 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNxTI-0006p9-Bp for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Aug 2022 10:23:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48948) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNxTC-0006p1-Fw for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 10:23:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58197) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNxTC-0004Bq-7P for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 10:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNxTC-0005Vd-3K for bug-gnu-emacs@gnu.org; Tue, 16 Aug 2022 10:23: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: Tue, 16 Aug 2022 14:23: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.166065977121146 (code B ref 56682); Tue, 16 Aug 2022 14:23:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 16 Aug 2022 14:22:51 +0000 Original-Received: from localhost ([127.0.0.1]:47946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNxT1-0005V0-EU for submit@debbugs.gnu.org; Tue, 16 Aug 2022 10:22:51 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:35767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNxSy-0005Un-Vp for 56682@debbugs.gnu.org; Tue, 16 Aug 2022 10:22:49 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3FFDC4409FD; Tue, 16 Aug 2022 10:22:43 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DAB764410A9; Tue, 16 Aug 2022 10:22:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1660659761; bh=irxaOFS0yqAKBybbR9Dn+BV4e3QGnyyntRapJiJsmH8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=d9OD7DfZCTOn2J5NL5VpD/xzKp0RHRkItHLPKuXCEC0aVq7mFHSd0d2YaX/i95xZ7 qsrmIypP1FoAkv2H5KKjEf6K31CcwnivgIf+Yhtg2E0MvWGR95fCcJt4+ZEWmTLnU2 WhHUu2fzPuOhWJyroG19pkrhfEgEyCtif8qXzXBtVrlUrwKy9tRUhRLFFdaz+l6T6k PsNHPzuWfaH6K0tq+yVJBu/9uQOlb3/+xSbRi1ZmbNhoI0npSGXGeWkLxjBdg0vq3w h7MGhiAFiRZaNO+na8RV6XcAioj4gNLj7j8s+sdLrOT1fpXMhUoyhzQendDwBdhBSD EXrgJ6x0fc15w== Original-Received: from pastel (unknown [45.72.195.111]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A691312030A; Tue, 16 Aug 2022 10:22:41 -0400 (EDT) In-Reply-To: <325f95fd2b4bf15b4058@heytings.org> (Gregory Heytings's message of "Tue, 16 Aug 2022 14:03:16 +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:239957 Archived-At: Gregory Heytings [2022-08-16 14:03:16] wrote: >>> Without assuming that computers have infinitely fast CPUs, that is? >> If the font-lock rules to use in the buffer depend on whether the first >> line of the buffer starts with #! or not, then your narrowing will break >> them even tho they could work perfectly fine in a 1TB buffer without >> requiring an infinitely fast CPU (since they don't need to scan the whole >> buffer: just the region of interest plus the first 2 chars). > Why on earth should a font-lock rule check, inside each redisplay cycle, > whether the first line of the buffer starts with #! or not? [ Nitpick: font-lock is not triggered "inside each redisplay cycle". ] Because it's simple and efficient. > Isn't that an information that can, and in fact should, be cached? "Can" maybe, "should" probably not since managing the cache will be more trouble than it's worth. Also, in your case you'd need that info to always be up-to-date, in which case it's not really a "cache" (since that word usually refers to something that may be available but isn't guaranteed to be so, and is re-filled lazily), but a redundant representation of the data (which is usually more costly to manage). Stefan