From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sun, 14 Aug 2022 13:29:42 +0300 Message-ID: <036414cc-c711-efaf-ed5b-f8ccfaca0604@yandex.ru> References: <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> <83o7wnl7ok.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19102"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 14 12:30:20 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 1oNAst-0004p5-NF for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Aug 2022 12:30:19 +0200 Original-Received: from localhost ([::1]:38562 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNAss-0007zL-O2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Aug 2022 06:30:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47530) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNAsd-0007zB-Ep for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 06:30:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46247) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNAsc-0001jr-Qy for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 06:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNAsc-0005sX-Jv for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 06:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Aug 2022 10:30: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.166047299522561 (code B ref 56682); Sun, 14 Aug 2022 10:30:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 14 Aug 2022 10:29:55 +0000 Original-Received: from localhost ([127.0.0.1]:35996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNAsU-0005ro-Nk for submit@debbugs.gnu.org; Sun, 14 Aug 2022 06:29:55 -0400 Original-Received: from mail-wr1-f42.google.com ([209.85.221.42]:33614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNAsS-0005rb-7p for 56682@debbugs.gnu.org; Sun, 14 Aug 2022 06:29:52 -0400 Original-Received: by mail-wr1-f42.google.com with SMTP id v3so6010269wrp.0 for <56682@debbugs.gnu.org>; Sun, 14 Aug 2022 03:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc; bh=BEWsP6QGHa90odlIeTXN493h/Mg9d0DzTnWYf7+ACeY=; b=DG0q6MmMOJigYEDSMhllTSold3p1wb5bZ/GOp7vnJRFBLsjlCqp5ByFugqGEtcD/xG jhZMUAUNEZ4ZIb03uAUDBElluHJc5yjwpfBppgRIK63RKlBw51WgLf+JW8YQ3sxYKf43 xp4meguIYhDLsb7gCa38KAS9M2pYHmw1oEtlee6COzkcPBBXQrjilYbP9O8n9YAzD50F y8ShlbNTRoqYLdO/jIy8QITuwKFvnUVNmF72dWSACccnYos5XmTX1PrWuEwDQ0TWNpS5 R3fLq0L23y2ISrI3/KIquAaC5wu2JWqGbOVq15XA0C3j/Jn2Yo99IfIpcWkUn+VB1Dqs qlmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc; bh=BEWsP6QGHa90odlIeTXN493h/Mg9d0DzTnWYf7+ACeY=; b=hUyLIs2uOrQMgWt2mpXxVgTilYYZend36c28lpi/bsUc1crim1yZhJcDo/BeMUFuFq ze7yBQIgySK1NtSHcwne4jrglH98UUAUbBDhBRPTZjFAmnqYpQJRy3aoYP2pCMySTlkJ 6NMAirLwAm5NqyGxlVZXC7uOHmo7ltUVjbaDYbEjGk/ReL9Jl4TyzTGk7D6dd/BzR/6K MzmYwym9de/rTYHALbCYIJekWGLXk/I3+Ao/u0QgBPTZqFwy+6b/qoFcLWGvHi80ln0A 8VnZ5+SIFAPGoxgxhnkUoE+OMcT3GCNxAkGehDvpurSf1EsYKuqmrBzSR22gtYQQu+mw kgyg== X-Gm-Message-State: ACgBeo0dv53/+QCv4GzinhjSOTAnSU8lGwWJ6s/5q8laWV9QpZPyUutY tWzyHmwldvg4mHIVWhsDCww= X-Google-Smtp-Source: AA6agR7mYTCGRfRFg+s1L3HoCpO+WAMMI8WE/ocZJ6DtWxJd3t9rKmBpJ2rjWT0c03GvZUYgccLWxA== X-Received: by 2002:a05:6000:a13:b0:220:62e6:5f79 with SMTP id co19-20020a0560000a1300b0022062e65f79mr6079022wrb.45.1660472986302; Sun, 14 Aug 2022 03:29:46 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m20-20020a05600c3b1400b003a319b67f64sm9543582wms.0.2022.08.14.03.29.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Aug 2022 03:29:45 -0700 (PDT) Content-Language: en-US In-Reply-To: <83o7wnl7ok.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:239634 Archived-At: On 14.08.2022 08:23, Eli Zaretskii wrote: >> 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. There's no point in doing that. Either we narrow to some area around point (might even using a larger radius like 1 MB), or we we only fontify up to some position. The former easily creates bad fontification. The alternative, of course, is to pay the price of syntax-ppss on larger spans and wait the corresponding amount of time the first time the user scrolls to EOB. That's what the current default on the branch does. >> 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. js-json-mode is not an "alternative", it's just doing what font-lock is supposed to do (I fixed the outstanding problems with the rules). But as Gregory shows, when you get to _really_ large files (like 1 GB JSON file in his example), pressing M-> will still make you wait (I have to wait around 20 seconds). It's still a great improvement from what we had in Emacs 28, though, so I'm fine with this default too. >> 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. If someone agrees with me, they will simply be able to customize font-lock-large-files to choose this strategy. I do not really insist on it being the default. But being able to choose this approach (in the absence of better upcoming alternatives) is a good thing. >> 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. I'm still waiting for people to come forward with other major modes which have the same kind of problems. Preferably ones that are likely to be used with large files. But as mentioned, that does not preclude us from having to choose what to do with _really_ large files.