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#56682: Fix the long lines font locking related slowdowns Date: Sun, 14 Aug 2022 08:23:39 +0300 Message-ID: <83o7wnl7ok.fsf@gnu.org> References: <834jyq29o1.fsf@gnu.org> <92da07bd028e3ede61a6@heytings.org> <47894c57-dd8b-5778-240a-3fa6540e4d37@yandex.ru> <92da07bd02941d5537e9@heytings.org> <5308e3b5-a160-17d7-77ee-b1d00acfa20d@yandex.ru> <92da07bd02a6cc861e1a@heytings.org> <837d3lzv8n.fsf@gnu.org> <2c8d6755-cfe2-6559-3fde-3fa30ffb411e@yandex.ru> <83mtcgy44k.fsf@gnu.org> <83k07jx5jn.fsf@gnu.org> <866e510d-a060-7daa-d002-97861d056fa7@yandex.ru> <1144021660321893@iva5-64778ce1ba26.qloud-c.yandex.net> <12348081660379417@sas2-a098efd00d24.qloud-c.yandex.net> <66bbbb95983414e79637@heytings.org> <83wnbckp0q.fsf@gnu.org> <8e884ebe-2d2e-d599-15c3-a5cfe5e6b295@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24710"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 14 07:25:21 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 1oN67l-0006Ec-2k for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Aug 2022 07:25:21 +0200 Original-Received: from localhost ([::1]:54634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oN67j-00061s-QS for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Aug 2022 01:25:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oN67U-00061M-5d for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 01:25:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45882) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oN67S-00027X-Mf for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 01:25:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oN67S-00062f-Gy for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 01:25: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: Sun, 14 Aug 2022 05:25: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.166045464823160 (code B ref 56682); Sun, 14 Aug 2022 05:25:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 14 Aug 2022 05:24:08 +0000 Original-Received: from localhost ([127.0.0.1]:35631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN66Z-00061U-TT for submit@debbugs.gnu.org; Sun, 14 Aug 2022 01:24:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oN66W-00060y-Vb for 56682@debbugs.gnu.org; Sun, 14 Aug 2022 01:24:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38420) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oN66P-00025G-M2; Sun, 14 Aug 2022 01:23:58 -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=uZQ/KLyBWtoBZIgRgxsUqg5fpx4+XLwfRmziB7XAHrY=; b=YkMo6SqzSN6T 3zBTVuoofmrjpUY8fhqkK9iF65ax9skK2DnG31poJKwXsRjr3N3IM4IxZMZIJNdzOl2pWQ5nYcLUR ND7/5Ba5Up8QPtyTxJQ5h2Ug5LFRnLwaxHzqUT8sM0DXfw/EMPO/iRsFZOX39lU5Bjd+QzbY5nEW9 GaUpcXPRFpFvrcdf+8ESLJGF4QhD3ROUPr94NdCXcvSIuZB95XHpyh72w7qaVli3tR9o1gpIkBqne TjP1pxeKBWSHTEUjjvugwjeL9OE2yMThDScTi1pKvAaiXKyN/06OGkVTR1uWahfAE97t24mD3bxHe 6SvW2q6uk32pHFEm/Fa0Cg==; Original-Received: from [87.69.77.57] (port=3409 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 1oN66P-0007QO-5L; Sun, 14 Aug 2022 01:23:57 -0400 In-Reply-To: <8e884ebe-2d2e-d599-15c3-a5cfe5e6b295@yandex.ru> (message from Dmitry Gutov on Sat, 13 Aug 2022 22:08:25 +0300) 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:239614 Archived-At: > Date: Sat, 13 Aug 2022 22:08:25 +0300 > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca > From: Dmitry Gutov > > > Fontifying only the beginning of the file doesn't help when the file > > is first shown at another point, like when Emacs or emacsclient is > > invoked with the +NN[:nn] argument, or the user uses saveplace or > > similar package. That's admittedly rarer than starting at the > > beginning, but it's a valid use case, and I wouldn't like us to > > dismiss it. > > The beginning of the file is the part of it which we can fontify quickly > enough while still doing it correctly. I know, but we are not doing only what is easy to do, do we? We do (or should do) what the users expect. In this case, if we want to fontify some relatively small portion of the document, it should be the portion around where the file is first displayed. > Because the main alternative on offer is to use narrowing and thus risk > getting invalid syntax information. That alternative is a direct and somewhat simplistic way of restricting misbehaving fontification, so as to prevent them from making Emacs unresponsive. Smarter alternatives -- and you seem to be arguing for such -- should be smarter, not less so. They should be like what you installed for JSON on master. > So the "don't fontify past X" strategy is simply based on the idea > that no fontification is probably better than unreliable and > obviously incorrect one. I disagree with that idea, but if someone agrees with you, they can simply turn off font-lock. As was already mentioned many times in this endless discussion. > Now, we could develop more complex approaches from there. But this can > be a starting point, and the user option allows people to choose the > strategy they're most comfortable with. Sorry, I don't consider this (fontifying the beginning of a file) a good starting point for making any progress towards smarter, faster fontifications. The new json-mode is such a starting point, but we should do something similar for other major modes as well.