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: Wed, 10 Aug 2022 19:08:18 +0300 Message-ID: <83fsi4qdxp.fsf@gnu.org> References: <83r11uzs8n.fsf@gnu.org> <14845631-c2ef-8371-8606-c858092e3192@yandex.ru> <83mtcizov2.fsf@gnu.org> <83h72qzheq.fsf@gnu.org> <25717d84-3411-a93a-3620-e04fe0571aff@yandex.ru> <83edxuzemr.fsf@gnu.org> <83a68hzz0a.fsf@gnu.org> <6ae35c93062c589b2e02@heytings.org> <7b7fbad7-55ac-49b8-840f-7f89a7e8771a@yandex.ru> <6ae35c93064b3588974c@heytings.org> <6ae35c9306c515f420d8@heytings.org> <87k07gwkjq.fsf@gmx.net> <87fsi4wiel.fsf@gmx.net> <837d3gs4p0.fsf@gnu.org> <83tu6kqnf1.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30595"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, gregory@heytings.org, stephen.berman@gmx.net, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 10 18:09: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 1oLoGc-0007lr-HH for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Aug 2022 18:09:10 +0200 Original-Received: from localhost ([::1]:54606 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oLoGb-0000ML-KA for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Aug 2022 12:09:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLoGU-0000Kd-7K for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 12:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60822) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLoGT-0008Qe-Ta for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 12:09:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oLoGT-0006KL-Oq for bug-gnu-emacs@gnu.org; Wed, 10 Aug 2022 12:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Aug 2022 16:09: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.166014771824291 (code B ref 56682); Wed, 10 Aug 2022 16:09:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 10 Aug 2022 16:08:38 +0000 Original-Received: from localhost ([127.0.0.1]:50571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLoG6-0006Jj-8y for submit@debbugs.gnu.org; Wed, 10 Aug 2022 12:08:38 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLoG2-0006JU-II for 56682@debbugs.gnu.org; Wed, 10 Aug 2022 12:08:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35964) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLoFv-0008MK-Pz; Wed, 10 Aug 2022 12:08:27 -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=/gZPuGPhQI1Pnw/E/7f8zOex1Ik/6MuYzvwmkHhMyK0=; b=B1QYf7Qan0Qh cDTVPk6Hc55ZGbsMpQy99Hmzj6ExY29P7f3xhHHv3eyYP6F9E4+2TebMr5j4eLCUzxJ1X26uV7OFh y07HVcZjTVKfVw1jFnI6jYxQqrJXqOt0dYVfeDQg/xVLilLrAuNtvEsAL7L7syvEg4SZMCE/J08g+ 221xKt1Y/E2IsuI8y3Pkqjt+bm6I7di1qmD6x4TqONJ7zWWzQ0nXX06hbOHcL7iVlp4ZPBmi+QHOg PcnNLIeH2QtR19u6a4wQ/J5i+rZlp/hmDMT7zPEpLAzmpzDo8DO4v6K5EzotXYBrleUZlQsyWOQ6d tUjo3bpdXXylpTjnjwZcQg==; Original-Received: from [87.69.77.57] (port=4098 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 1oLoFv-0004ej-95; Wed, 10 Aug 2022 12:08:27 -0400 In-Reply-To: (message from Dmitry Gutov on Wed, 10 Aug 2022 18:44:53 +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:239309 Archived-At: > Date: Wed, 10 Aug 2022 18:44:53 +0300 > Cc: 56682@debbugs.gnu.org, stephen.berman@gmx.net, monnier@iro.umontreal.ca > From: Dmitry Gutov > > Shouldn't the scanner be limited by the same narrowing that the > long-line optimizations create? Given its existing effect on font-lock, > limiting bidi searches seems like a no-brainer. Like I said: it _is_ limited. But the limitation is smarter than just some arbitrary number of character positions, because it is tuned to this particular processing. Note that the effect of it in this case is not as dramatic as font-lock: it does slow down C-n/C-p, but not catastrophically so, not like we've seen with the files we used for the long-lines speedups. And if someone does think it's a catastrophe, they can always disable the BPA, perhaps even globally, if they know they will never need to look closely at bidirectional text: the effects are hardly visible unless you actually read the text. > Alternatively, I would perhaps propose to perform said searching at two > junctions: when the buffer is visited (and the text is inserted and, > thus, unavoidably read), and when the buffer is saved (perhaps at that > point Emacs might have info about the added ranges, to avoid searching > through the whole buffer). The downside would be that the first added > R2L character might be displayed incorrectly until the buffer is saved. This is impossible without a complete redesign of how the bidi display works: it saves no information in the buffer object, none whatsoever. The information is recomputed every time the display code is called, and only for the portion of the buffer that needs to be traversed or displayed; then it is discarded. There are no caches of any kind that keep the information after redisplay has done its job.