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 19:47:42 +0800 Message-ID: <87lerp4tk1.fsf@localhost> References: <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> <87mtc6yzfv.fsf@localhost> <3a1232a17bf48a4a693e@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1030"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier , Dmitry Gutov To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 15 13:48:01 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 1oNYZc-000AYk-Vm for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Aug 2022 13:48:00 +0200 Original-Received: from localhost ([::1]:46218 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oNYZb-0001ht-GT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Aug 2022 07:47:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60610) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNYYr-0001f1-Ir for bug-gnu-emacs@gnu.org; Mon, 15 Aug 2022 07:47:17 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51319) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oNYYf-00022N-Tj for bug-gnu-emacs@gnu.org; Mon, 15 Aug 2022 07:47:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oNYYf-0006tW-Qb for bug-gnu-emacs@gnu.org; Mon, 15 Aug 2022 07:47:01 -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 11:47:01 +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.166056401326472 (code B ref 56682); Mon, 15 Aug 2022 11:47:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 15 Aug 2022 11:46:53 +0000 Original-Received: from localhost ([127.0.0.1]:41064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNYYW-0006ss-J1 for submit@debbugs.gnu.org; Mon, 15 Aug 2022 07:46:52 -0400 Original-Received: from mail-pj1-f46.google.com ([209.85.216.46]:40604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNYYT-0006sf-Dy for 56682@debbugs.gnu.org; Mon, 15 Aug 2022 07:46:51 -0400 Original-Received: by mail-pj1-f46.google.com with SMTP id s5-20020a17090a13c500b001f4da9ffe5fso14161516pjf.5 for <56682@debbugs.gnu.org>; Mon, 15 Aug 2022 04:46:49 -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=XAZluhK3OwUQizXMfUZo/v4yZo/SClYBIVkGwSyjgjM=; b=jiXKZPPk2czCunTfwnzfIHA79LwQ45x3JiRHFfQkRHRrT0HWlOlV6Y+kk6PW/t49Ns LzXK/VjVN1s07FvAlC6zjjp3euDpxEywHcVOA2DZOOa4vGqHqLewmlqivWGMQYUoTA7U SylRwHeBv6LMmj0hL00+YwFicC3uUuk0K1xzddzAXvsa57PDxwftt4EjuJ/I2xUQoN0s bZd5MmyP2joZt3H5RGnBFN2Pv+3ITT5MAMehDpJXzS4BM9zDgCGXwWgOnHfWc7mOmFPj a4BcFLk3Pp9nm3tJMkCYgZlRoahwLoG8FssJpaeIhEHB/dmrB19n17NImlvJl+vJ43yf S7nw== 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=XAZluhK3OwUQizXMfUZo/v4yZo/SClYBIVkGwSyjgjM=; b=Bo8/79BDjTbeZWv52dkmLVd5KZAQuuudZFtoJ4ZKKvyDexU5JbmKe+fLrrptKY0Aok 7EEdpSGkACVURadRgidsnhRm4zp4meFLu5JBrwO6q1NUhoySqsaIzSOpDXbSIop0HCNp B5DN9GCdJhXiB0rEZTQ7HNda69BwamV9k3AZcgd0hIA9IeiTwH3tmx4gpPloh+bykDww hmUrijpEq9xHwZCyk0aZgWdi5F/TtkCDsqqZnIFni1RZ0oWizQdUe2t9wFSqXpp3usGY cK7dmYXQl9jXuTNFafox6ikHfMooNcxcmc5tNQ/VMn4M4WiVKxyzJjSUsUgjDJJyORT6 qwUA== X-Gm-Message-State: ACgBeo3s4yWzXEwQLF05Vk4Q1oT18/j38+qeMMc/JOYIcKAxjcOmXAXH qXSe9wgz02WfjDjkYibtnF0= X-Google-Smtp-Source: AA6agR46Qe2JuFQemNm8j0dPp8O7MBTTq8hm24kW59Q7WyeRjF9sbxMqkdM+FOud9ck68t7f5dN7Pw== X-Received: by 2002:a17:90a:b391:b0:1f3:6c3:392c with SMTP id e17-20020a17090ab39100b001f306c3392cmr27405403pjr.166.1660564003626; Mon, 15 Aug 2022 04:46:43 -0700 (PDT) Original-Received: from localhost ([2409:8a70:2bf:80b0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id z15-20020a170902cccf00b00170d34cf7f3sm2614945ple.257.2022.08.15.04.46.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Aug 2022 04:46:42 -0700 (PDT) In-Reply-To: <3a1232a17bf48a4a693e@heytings.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:239779 Archived-At: Gregory Heytings writes: > I'm not sure I correctly understand what you mean, but it seems to me that > the fact that the Org parser caches its results implies that Org doesn't > need to access the whole buffer to make "local" decisions. It can use the > data in cache for everything that is outside of the current narrowing, and > update the portion of the cache corresponding to the current narrowing. > IOW, there is no need to maintain separate parser caches for each possible > narrowing state. Am I misunderstanding something? Cache existence is not guaranteed. When cache does not exist, Org must widen. If not, the cache will be valid only for the current narrowing. When cache do exist, Org may not need to widen. But that also mean that widening has happened in the past when the cache was generated. At the end, Org does need to be able to widen safely. At least in some cases. -- 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