From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Mon, 15 Aug 2022 11:10:12 +0800 Message-ID: <87mtc6yzfv.fsf@localhost> References: <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> <036414cc-c711-efaf-ed5b-f8ccfaca0604@yandex.ru> <5900f20836753183a6ac@heytings.org> <5c22e38a-5dcd-860e-28a0-b4a5ede6a21b@yandex.ru> <877d3awb92.fsf@localhost> <87pmh2z277.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21848"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, Gregory Heytings , Eli Zaretskii , Dmitry Gutov To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 15 05:10:12 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 1oNQUV-0005V7-MB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Aug 2022 05:10:11 +0200 Original-Received: from localhost ([::1]:35708 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNQUU-0001ya-2p for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Aug 2022 23:10:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNQUM-0001yI-O2 for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 23:10:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50464) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNQUM-0006Eo-Ec for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 23:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNQUM-00056L-AY for bug-gnu-emacs@gnu.org; Sun, 14 Aug 2022 23:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Aug 2022 03:10: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.166053296019542 (code B ref 56682); Mon, 15 Aug 2022 03:10:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 15 Aug 2022 03:09:20 +0000 Original-Received: from localhost ([127.0.0.1]:40209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNQTg-000558-1j for submit@debbugs.gnu.org; Sun, 14 Aug 2022 23:09:20 -0400 Original-Received: from mail-pl1-f180.google.com ([209.85.214.180]:40839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNQTc-00054u-Ti for 56682@debbugs.gnu.org; Sun, 14 Aug 2022 23:09:18 -0400 Original-Received: by mail-pl1-f180.google.com with SMTP id x23so5380896pll.7 for <56682@debbugs.gnu.org>; Sun, 14 Aug 2022 20:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc; bh=S9RxKsy2KcluoGjsqGbSjEeaf0BNmLPxm1M14N3DWsI=; b=hsos9EahqsRjfokpbj2VMjuqdw5EghihMAzyEo9wmP1bzT/Woveszi1JGnyYTlpomb hMg1/XA0+xBVQV3U2O2YNCRA9thW2uEK+hyKPj3i1gSr/44b9A2eixHHv/PdHo8W24Kq ntk46W4nhYIfdB35aWUDGxHFQfH4oQbZA+YUCEo7ZFFyOiSRIMfOKFCQZIrf00CLZvPs ebRjhqOOdKxaViqznn259L2X1Bkt6tuG3SDu0lIL81mwprXTKpxWkTTmxzCxT/gT+aHI 8ohp0BevQ4R76zaa1I3ZJN9LmpZ0BiCMQwYXley24BgM9AMeQklhqIaPEWweGAonHxtj 07mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc; bh=S9RxKsy2KcluoGjsqGbSjEeaf0BNmLPxm1M14N3DWsI=; b=irjv0p70MkosIekOkCbZ257p628Z42zF5P6GXG7pikVzfm47Eww1HHErgYFZDDj3p2 v0et7tBVhTDcdVTWVRqCCBXUd8i0udfSsBFA8gwaxE4X2SbXjqJygsY5yCWXAL/8haj1 niv0nC6g2AUL2QfQgjgkpTx9w3KKQAwG/RNEo8oWYc0Tioj8TkfCTPzRmlfpOWJISfyQ F5V1JPaWP7AkpZJ9SUe0JG4gJwb8WEgE5vxNIBQKJqi9s7lOmH4DggvtlfaAFAwh+7X8 kZw0F+bzeSxY+G0HZiXyeeu8P79zPC0CrVT2JIssfw2orNZ+D6AcS2/P/Kn9b/Kwmwdm khYA== X-Gm-Message-State: ACgBeo38CeX3EayTEQjmq+1uTxVODm8KD5GnjILWIbu6EnrFoXpK8f+c ofzxqNkdZkWmgL8rl9zFoBI= X-Google-Smtp-Source: AA6agR6UnTiGEcGDDqsN3FQp4CCrk4dN4agAgc2b+68fiuSoAPqeCuNXMIjV2dQ3s7EKoFdojd3J7Q== X-Received: by 2002:a17:90b:3b43:b0:1f4:e3ad:e45a with SMTP id ot3-20020a17090b3b4300b001f4e3ade45amr25994881pjb.87.1660532950927; Sun, 14 Aug 2022 20:09:10 -0700 (PDT) Original-Received: from localhost ([115.154.175.57]) by smtp.gmail.com with ESMTPSA id u26-20020a63455a000000b0041c45d76b6bsm4944277pgk.38.2022.08.14.20.09.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Aug 2022 20:09:10 -0700 (PDT) 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:239719 Archived-At: Stefan Monnier writes: >>>> This is needed by Org parser to determine the syntax element at point. >>> But font-lock widens before using Org-mode's `font-lock-keywords`, so >>> there should be no need for Org-mode to widen in that case. >> Yes, but Org parser is not written explicitly for font-locking purposes. >> org-element-at-point knows nothing about buffer restriction upon >> calling and thus has to widen to ensure correctness. > > That will break uses of MMM-mode where one of the chunks is using > Org-mode. Admittedly, this is unlikely, but still: It would be much > better to arrange to do `widen` *outside* of Org-mode's font-lock (and > indentation) code. The fact that MMM-mode is relying on narrowing is a bug in MMM-mode. Polymode (an alternative to MMM-mode) is using a different approach. Correct me if I am wrong, but I assume that having a specific major mode in buffer implies that the whole buffer is considered to contribute to the major mode. If the Org parser does not ensure that buffer is widened then the parser output may depend on the narrowing state. For font-lock, it also means that different fontification must be used with/without narrowing - something that font-lock will fail to achieve unless buffer is re-fontified every time the narrowing changes. Further, Org parser is caching parse results and reuse them to not re-parse on every invocation. The need to maintain separate parser caches for every possible narrowing state will be a nightmare. Especially considering the user narrowing may also be an option and having a different parser/command behaviour will be unexpected to the user. More generally, prohibiting the innocent-looking (save-restriction (widen) ...) means that font-lock-keywords cannot safely call any kind of general-purpose API function without checking (widen) usage inside that function and inside all the deeper nesting levels. This will be fragile, especially for user-defined keywords. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92