From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Apr 2023 18:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 62780@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.168123902423573 (code B ref -1); Tue, 11 Apr 2023 18:51:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Apr 2023 18:50:24 +0000 Received: from localhost ([127.0.0.1]:38205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmJ4S-000688-GE for submit@debbugs.gnu.org; Tue, 11 Apr 2023 14:50:24 -0400 Received: from lists.gnu.org ([209.51.188.17]:44218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmJ4N-00067t-Im for submit@debbugs.gnu.org; Tue, 11 Apr 2023 14:50:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmJ4N-0000eE-5n for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:50:19 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmJ4L-0002pW-13 for bug-gnu-emacs@gnu.org; Tue, 11 Apr 2023 14:50:18 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5E0FF240590 for ; Tue, 11 Apr 2023 20:50:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681239014; bh=dQx/qEOM2uVJC1SY9Zq8ZruMlVr93R8SSTxCq+05Yvc=; h=From:To:Subject:Date:From; b=F9SOQDV9XxBwR/dlJzE3G+UYYvKDhRi8J3cyLzRAcy/CXD/66ul0oMbJwIpItuGgB /9MO3wQnb7C7BwvVgfOLW7TuGd7hOPW1THc7wB+IRTIouSGEUhBNaeAYdHqcpro78S VB3qJwZTKp1IyZogJrElwCKDGfpPXjOmg+BAdVtGCs7foT9D3ejKiX/iPv0baq1jaI G+Ds4OYqgwpTk2aa21V3qQ8qdNvVY8jhnR/xYq56InM/1cx3QnQd7g9ZYz0Aa285Sn Y4NLL1BLJoE0+bHzPyKAygOQwsKZlmxN748NHxAWJEuzwbQC7LUm4m3JPblG89jxuT UrVpLEkiNurYw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PwvzV0Hckz6twj for ; Tue, 11 Apr 2023 20:50:13 +0200 (CEST) From: Ihor Radchenko Date: Tue, 11 Apr 2023 18:52:43 +0000 Message-ID: <87mt3e8d50.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Try the following: 1. emacs -Q 2. M-x org-mode 3. M-x org-table-create 30x30 4. M-: (setq show-trailing-whitespace t) 4. M-x org-table-insert-column (20x times) 5. M-> type something 6. Observe significant lag when typing. CPU profiler does not expose much. In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.17.8) of 2023-04-05 built on localhost Repository revision: fa669c4b17c04eff852eb23a6179ccb8fab864db Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 System Description: Gentoo Linux -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Apr 2023 19:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168124110327378 (code B ref 62780); Tue, 11 Apr 2023 19:26:01 +0000 Received: (at 62780) by debbugs.gnu.org; 11 Apr 2023 19:25:03 +0000 Received: from localhost ([127.0.0.1]:38266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmJbz-00077V-Ga for submit@debbugs.gnu.org; Tue, 11 Apr 2023 15:25:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmJbw-00076v-5m for 62780@debbugs.gnu.org; Tue, 11 Apr 2023 15:25:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmJbq-0004Zf-Da; Tue, 11 Apr 2023 15:24:54 -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=F5s4/Wm2nHMDCs5KsFg4L/vsTch641E/fUEcy5Y7O1o=; b=Amk/+Nej5gNd FbsWg+Yx5rR/gwxOVPx9coq/fnkA1hRxD+maNM4Sx6yyhiCbLPe1EFq7IJmjJS/MtND2T1lN84+ib uMS04f3M6evcGbnMyyObE0jLZw6kxBs/UfjOFxVKfZiBU5opxchNiFUMzL3d89XZfO0lB78ZgskUC gPn18EwTptIUEiO1sjq/xrygrsG3fWZ66Fqo0+D5c9c8kYbDsoiDpBsaJGv/PD5m22xMKf1MuGMo+ KBAOG6Xns9tz/jADIkjnn6fHlWlVmwU7Tq/OJ9Xk8+6pqN2mUnfIGCaYCrSvRGkzGOVGLIjU0cy0n y3n29qEAkOV2ZSPC5KDfGg==; Received: from [87.69.77.57] (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 1pmJbe-0000AX-Gq; Tue, 11 Apr 2023 15:24:53 -0400 Date: Tue, 11 Apr 2023 22:25:25 +0300 Message-Id: <83y1my8bmi.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87mt3e8d50.fsf@localhost> (message from Ihor Radchenko on Tue, 11 Apr 2023 18:52:43 +0000) References: <87mt3e8d50.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Date: Tue, 11 Apr 2023 18:52:43 +0000 > > 1. emacs -Q > 2. M-x org-mode > 3. M-x org-table-create 30x30 > 4. M-: (setq show-trailing-whitespace t) > 4. M-x org-table-insert-column (20x times) > 5. M-> type something > 6. Observe significant lag when typing. CPU profiler does not expose much. show-trailing-whitespace disables quite a few redisplay optimizations, including even the cursor-motion optimization (when nothing has changed on display except the position of point). And full thorough redisplay becomes slow when you have relatively long lines, because Emacs is forced to consider all of them. In addition, org-table seems to put a large number of 'display' properties (like, 2 per cell?), which also slows down redisplay. Are you saying there's been a regression in Emacs 30 in this situation wrt Emacs 29 and Emacs 28? I don't think I see a regression in my testing here. From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Apr 2023 19:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168124192128671 (code B ref 62780); Tue, 11 Apr 2023 19:39:02 +0000 Received: (at 62780) by debbugs.gnu.org; 11 Apr 2023 19:38:41 +0000 Received: from localhost ([127.0.0.1]:38298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmJpB-0007SN-3J for submit@debbugs.gnu.org; Tue, 11 Apr 2023 15:38:41 -0400 Received: from mout02.posteo.de ([185.67.36.66]:43417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmJp8-0007S7-DC for 62780@debbugs.gnu.org; Tue, 11 Apr 2023 15:38:38 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id B3C0824013F for <62780@debbugs.gnu.org>; Tue, 11 Apr 2023 21:38:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681241912; bh=JFqQ67xTgcVvGFmr45TMH9iG2cpYZBxliYTSbKUO59s=; h=From:To:Cc:Subject:Date:From; b=QUNzszmwHU3oiRhlEkyrvimlCIR87YA2lYX6aMmU0KouodlhWEshG887apF8WZjmy PRErvk2FyyDsEs+NqKnxa2xF8XHbmK9Rasq8jgIhavJk3yKViFhcIkop5+NbHw5gCu 1TBL0XjHpbggILgWBgpCtNs9UgwnCmcEEHK4VlhIQE0Wq6+58JL4Sv4oDL7MRugY3k EOnvGDsSpAndXrM1CkuNAqsX/xvdp7GgIIJREy0wg3GR9QjJZuDYAnf2Xrj4m4LErv OThg7Io3LKQCQuaNifXdCXuszle/jU7ufdutwd1BOSsCvzpVKxl/C19R0scalhJhN3 bTQ3jv8oCFihg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pwx3D08qnz9rxP; Tue, 11 Apr 2023 21:38:31 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83y1my8bmi.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> Date: Tue, 11 Apr 2023 19:41:01 +0000 Message-ID: <87h6tm8awi.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > show-trailing-whitespace disables quite a few redisplay optimizations, > including even the cursor-motion optimization (when nothing has > changed on display except the position of point). And full thorough > redisplay becomes slow when you have relatively long lines, because > Emacs is forced to consider all of them. Well. But it is not even that big of a file. And the lines are shorter than window width. I could understand Emacs lagging on some really large file or long lines, but this does not look large at all! > In addition, org-table seems to put a large number of 'display' > properties (like, 2 per cell?), which also slows down redisplay. These properties are for the purpose of bidirectional ordering: (defconst org-table--separator-space-pre (propertize " " 'display '(space :relative-width 1)) "Space used in front of fields when aligning the table. This space serves as a segment separator for the purposes of the bidirectional reordering. Note that `org-table--separator-space-pre' is not `eq' to `org-table--separator-space-post'. This is done to prevent Emacs from visually merging spaces in an empty table cell. See bug#45915.") Maybe there is a better way? > Are you saying there's been a regression in Emacs 30 in this situation > wrt Emacs 29 and Emacs 28? I don't think I see a regression in my > testing here. No, I do not mean a regression. But the slowdown appears to be unreasonable for such a small test case. What is the point having `show-trailing-whitespace' if it is this much inefficient? Maybe a simple font-lock rule can be better? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Apr 2023 07:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.16812839435771 (code B ref 62780); Wed, 12 Apr 2023 07:20:02 +0000 Received: (at 62780) by debbugs.gnu.org; 12 Apr 2023 07:19:03 +0000 Received: from localhost ([127.0.0.1]:38869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmUkw-0001V0-W7 for submit@debbugs.gnu.org; Wed, 12 Apr 2023 03:19:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36068) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmUkt-0001UF-CJ for 62780@debbugs.gnu.org; Wed, 12 Apr 2023 03:19:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmUkn-0002ux-S5; Wed, 12 Apr 2023 03:18:53 -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=6cUumKfvd3Wb4OvJdSp5ZqqBX53T/sT7v93fXniXtJg=; b=az7OMiUeokqq B6Mz6aH/PHRgjjVmOONGvStdyck38eiq69bH05NMzkO0i/hd9LOAGLaq2iB8K98JB/QDbZIZhiszw /DNQVWhMH04YQ2Eiw+JO3InN6/a26F/rePMJIXvK1iYTD4zUX7WiSOMw0nL3RHSH0WCeITaql59UR ft5l0hXPegQ4dFnRemCn7G266PXC+oKkdEa1yQZ7PGd09F36c+weSi0wQHSvSpgnec0sGmmuHHQj0 xjpjCZnoRZTE0rNgiypdr29dUja1g6qR/9dXavL6fzYf09gusta9gEK0XWVqX6KFWhaF1eKuXh91t Y7lMGjILRz37cSe3e0o9xQ==; Received: from [87.69.77.57] (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 1pmUkn-0004eK-9M; Wed, 12 Apr 2023 03:18:53 -0400 Date: Wed, 12 Apr 2023 10:19:38 +0300 Message-Id: <83bkjt8t4l.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87h6tm8awi.fsf@localhost> (message from Ihor Radchenko on Tue, 11 Apr 2023 19:41:01 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Tue, 11 Apr 2023 19:41:01 +0000 > > Eli Zaretskii writes: > > > show-trailing-whitespace disables quite a few redisplay optimizations, > > including even the cursor-motion optimization (when nothing has > > changed on display except the position of point). And full thorough > > redisplay becomes slow when you have relatively long lines, because > > Emacs is forced to consider all of them. > > Well. But it is not even that big of a file. The size of the file doesn't matter, only what's shown in the window matters. > And the lines are shorter than window width. Not here, they aren't: a 50x30 table takes more than twice the default window width of "emacs -Q". However, I don't think this aspect is important, either. > > In addition, org-table seems to put a large number of 'display' > > properties (like, 2 per cell?), which also slows down redisplay. > > These properties are for the purpose of bidirectional ordering: > > (defconst org-table--separator-space-pre > (propertize " " 'display '(space :relative-width 1)) > "Space used in front of fields when aligning the table. > This space serves as a segment separator for the purposes of the > bidirectional reordering. > Note that `org-table--separator-space-pre' is not `eq' to > `org-table--separator-space-post'. This is done to prevent Emacs from > visually merging spaces in an empty table cell. See bug#45915.") I understand. But it's definitely what causes most of the slowdown; show-trailing-whitespace just adds the last straw. With the patch below I can see no slowdown at all with your recipe. > Maybe there is a better way? Maybe. Can you point me to the discussion which caused you to use these display properties there? I think this was done in two steps: first you added the same display property as pre and post, then made them subtly different; I need to re-read the discussions that led to both of these. Alternatively, if you can describe the use cases where these properties are needed, that could be enough for me to try to look for alternative solutions. > > Are you saying there's been a regression in Emacs 30 in this situation > > wrt Emacs 29 and Emacs 28? I don't think I see a regression in my > > testing here. > > No, I do not mean a regression. But the slowdown appears to be > unreasonable for such a small test case. What is the point having > `show-trailing-whitespace' if it is this much inefficient? Maybe a > simple font-lock rule can be better? See above: show-trailing-whitespace is not the main culprit here; these particular display properties are. If you could produce a perf profile with this recipe, it might give ideas for speeding up the C code without any changes on the Lisp level. Btw, these properties were introduced into org-table.el some time ago, so how come this issue comes up only now? Aren't Org tables used quite a lot? diff --git a/lisp/org/org-table.el b/lisp/org/org-table.el index 5116b11..658b5aa 100644 --- a/lisp/org/org-table.el +++ b/lisp/org/org-table.el @@ -4354,11 +4354,12 @@ org-table--align-field ("r" (make-string spaces ?\s)) ("c" (make-string (/ spaces 2) ?\s)))) (suffix (make-string (- spaces (length prefix)) ?\s))) - (concat org-table--separator-space-pre + (concat " " ;org-table--separator-space-pre prefix field suffix - org-table--separator-space-post))) + " " ;org-table--separator-space-post + ))) (defun org-table-align () "Align the table at point by aligning all vertical bars." From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Apr 2023 07:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.16812850427573 (code B ref 62780); Wed, 12 Apr 2023 07:38:02 +0000 Received: (at 62780) by debbugs.gnu.org; 12 Apr 2023 07:37:22 +0000 Received: from localhost ([127.0.0.1]:38902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmV2g-0001y4-7S for submit@debbugs.gnu.org; Wed, 12 Apr 2023 03:37:22 -0400 Received: from mout01.posteo.de ([185.67.36.65]:44169) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmV2c-0001xo-LQ for 62780@debbugs.gnu.org; Wed, 12 Apr 2023 03:37:21 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 270082401BD for <62780@debbugs.gnu.org>; Wed, 12 Apr 2023 09:37:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681285033; bh=uQrAbt+WAv8awox7S/uO9VstM9jenVUqfXz658Z2pIk=; h=From:To:Cc:Subject:Date:From; b=kjGwrryJaNTPMQ3BVZWOUOBbsO0Njy65nIAxOyUS8hFu9v9PQJwcC0D2a05cBSESQ cAIG8qbxlm8eZtTmaOLz/6MSXxIb4MUk1MtBSsFxcrvX5j0dqhGYUNzVFh5tK0bAzH zx5Zv2FceuPhivyt/cGO2wCGEKvBy5CksVxddsMAuyA2dXxgAs2BiWgFvV6jCEsyWM QNSgJxUPM/SGPxVj75ERGzrFfGNaNi48DXcWcGxOKlD0cYjfQiUzNpFuy+ygTeju0T /4cFU/8N8HewAvavU+UT/dcQlnbg4ULYguKOMO8cAaKbZ+6bIh3MtiWrjrm2l5Dzne zS93YE/5t//Rw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PxF0S4JSBz6tsg; Wed, 12 Apr 2023 09:37:12 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83bkjt8t4l.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> Date: Wed, 12 Apr 2023 07:39:37 +0000 Message-ID: <87edop8s7a.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Maybe there is a better way? > > Maybe. Can you point me to the discussion which caused you to use > these display properties there? I think this was done in two steps: > first you added the same display property as pre and post, then made > them subtly different; I need to re-read the discussions that led to > both of these. The first step was in https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00526.html Then, we had an issue with empty cells || with Emacs joining two spaces with eq text properties. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45915 >> No, I do not mean a regression. But the slowdown appears to be >> unreasonable for such a small test case. What is the point having >> `show-trailing-whitespace' if it is this much inefficient? Maybe a >> simple font-lock rule can be better? > > See above: show-trailing-whitespace is not the main culprit here; > these particular display properties are. If you could produce a perf > profile with this recipe, it might give ideas for speeding up the C > code without any changes on the Lisp level. Ok. I will look into it. If we can speed this up, it will hopefully benefit more than just this particular scenario. > Btw, these properties were introduced into org-table.el some time ago, > so how come this issue comes up only now? Aren't Org tables used > quite a lot? I guess things are not that much obvious without show-trailing-whitespace. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Apr 2023 07:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168128624710490 (code B ref 62780); Wed, 12 Apr 2023 07:58:01 +0000 Received: (at 62780) by debbugs.gnu.org; 12 Apr 2023 07:57:27 +0000 Received: from localhost ([127.0.0.1]:38961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmVM7-0002j8-8j for submit@debbugs.gnu.org; Wed, 12 Apr 2023 03:57:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47538) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmVM4-0002iu-OY for 62780@debbugs.gnu.org; Wed, 12 Apr 2023 03:57:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmVLy-0003PQ-S2; Wed, 12 Apr 2023 03:57:18 -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=tbKH8FVHUYznpxutO0lNy+j+40O9xnZb3nhQ8EtM37A=; b=pqa9Hp1ROsmC 2DINy3TYkWQQR6u1v+ZOPI8entD+MWt00PmANgccxd/eNaq9FXe59LCmueVeLS7Df1rWAO/5WbkJa EZpUhH7fFT+1L9qcTt/PVPmKvyg6c9yP4sqlpQeFQyHFzSkNE2RSoKP1C7Mh5dvwoeq9J3BKGMdnU kx8hDgeckBBLsJr4R6LNrNE0aY66KY9zj0a8i2XCyYV4y8e78axye7HvAb90vScPIUDEBffzRRlxC CCMS7A6jiqeN9hwb93m3SLPNBx3AUkElQnFK8h6VvP4Nm8jLJQkjMYMd7lHE88bVObBX0bsagkPlp bGrXRvXA/4bmhaFDLbiIQg==; Received: from [87.69.77.57] (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 1pmVLx-0005FL-VL; Wed, 12 Apr 2023 03:57:18 -0400 Date: Wed, 12 Apr 2023 10:58:02 +0300 Message-Id: <835ya18rcl.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87edop8s7a.fsf@localhost> (message from Ihor Radchenko on Wed, 12 Apr 2023 07:39:37 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87edop8s7a.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Wed, 12 Apr 2023 07:39:37 +0000 > > Eli Zaretskii writes: > > >> Maybe there is a better way? > > > > Maybe. Can you point me to the discussion which caused you to use > > these display properties there? I think this was done in two steps: > > first you added the same display property as pre and post, then made > > them subtly different; I need to re-read the discussions that led to > > both of these. > > The first step was in > https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00526.html > > Then, we had an issue with empty cells || with Emacs joining > two spaces with eq text properties. > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45915 Thanks, will look into those. > > Btw, these properties were introduced into org-table.el some time ago, > > so how come this issue comes up only now? Aren't Org tables used > > quite a lot? > > I guess things are not that much obvious without show-trailing-whitespace. I see a substantial slowdown even with show-trailing-whitespace turned off. From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Apr 2023 09:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168137905532303 (code B ref 62780); Thu, 13 Apr 2023 09:45:02 +0000 Received: (at 62780) by debbugs.gnu.org; 13 Apr 2023 09:44:15 +0000 Received: from localhost ([127.0.0.1]:42543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmtV0-0008Ow-UB for submit@debbugs.gnu.org; Thu, 13 Apr 2023 05:44:15 -0400 Received: from mout01.posteo.de ([185.67.36.65]:45089) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmtUx-0008Of-L4 for 62780@debbugs.gnu.org; Thu, 13 Apr 2023 05:44:12 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D27032401FB for <62780@debbugs.gnu.org>; Thu, 13 Apr 2023 11:44:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681379045; bh=q9KHG5EgvQW8zyLzQe64lAa90FS7hXk+89Ix5NQ8Xh0=; h=From:To:Cc:Subject:Date:From; b=B5WmFGrdKs4H5CtAKGO2RAC93LRVQBXPCedZmC7FGdNingbxSx1u/VhwmRE79H+tw BKJOHGWMV2YQAZ4YU+PJlMz3I3YLwnQ3JJK0sKfV6t2JrtJ3qY9rA1VWN/A1Ek7U4Y yTjXACEEXytDJUGmg6/WIPJmxCPM3hdTQd+NGSm1HXiJb2C7/ttqxRJwyLyWDwvldU Bvg72ztzwAEJZ3vLTdtIrICzJr4paiQz3iC3ffnoRMEJfvy3tMZaZqZblFMyc485MT /SaiH0dYrL43ZnWF9FwsY0nPPBgYkEMWk1gUBfYfKCKeHEObRqWFIW2HufZWQAxfzO XmSvAissrwHJQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PxvmP1cV2z6tsf; Thu, 13 Apr 2023 11:44:05 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83bkjt8t4l.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> Date: Thu, 13 Apr 2023 09:46:31 +0000 Message-ID: <87bkjsf72g.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > See above: show-trailing-whitespace is not the main culprit here; > these particular display properties are. If you could produce a perf > profile with this recipe, it might give ideas for speeding up the C > code without any changes on the Lisp level. Here are perf results when typing, using the same recipe. Full summary: 29.89% emacs emacs [.] lookup_char_property 16.58% emacs emacs [.] next_interval 13.99% emacs emacs [.] Fassq 5.44% emacs emacs [.] find_interval 5.17% emacs emacs [.] Fcdr 3.97% emacs emacs [.] Fnext_single_property_change 2.32% emacs emacs [.] composition_compute_stop_pos 1.51% emacs emacs [.] validate_interval_range 1.03% emacs emacs [.] get_char_property_and_overlay 0.99% emacs emacs [.] textget 0.79% emacs emacs [.] plist_get 0.77% emacs emacs [.] produce_stretch_glyph 0.76% emacs emacs [.] balance_an_interval 0.54% emacs emacs [.] lface_hash Call graph: (next_interval is spread thin across the call graph, used all over the place) 99.10%--command_loop_1 97.65%--read_key_sequence 97.55%--read_char 97.51%--redisplay redisplay_internal 97.49%--redisplay_windows internal_condition_case_1 redisplay_window_0 97.49%--redisplay_window |65.03%--try_window ||32.55%--display_line || 28.90%--get_next_display_element || 28.83%--next_element_from_buffer || 28.75%--handle_stop || 23.87%--compute_stop_pos || 23.52%--composition_compute_stop_pos || 21.61%--find_composition || 21.31%--Fnext_single_property_change || 17.84%--textget || 16.84%--lookup_char_property || 6.15%--builtin_lisp_symbol || 5.28%--make_lisp_symbol || 5.94%--Fassq || 32.47%--partial_line_height move_it_to | 31.11%--move_it_in_display_line_to | 28.95%--get_next_display_element | 28.86%--next_element_from_buffer | 28.80%--handle_stop | ... 16.75%--lookup_char_property |32.42%--set_vertical_scroll_bar 32.41%--move_it_to 31.05%--move_it_in_display_line_to 28.86%--get_next_display_element ... 16.54%--lookup_char_property -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Apr 2023 10:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.16813826737157 (code B ref 62780); Thu, 13 Apr 2023 10:45:02 +0000 Received: (at 62780) by debbugs.gnu.org; 13 Apr 2023 10:44:33 +0000 Received: from localhost ([127.0.0.1]:42593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmuRM-0001rM-Tc for submit@debbugs.gnu.org; Thu, 13 Apr 2023 06:44:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54678) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmuRI-0001r6-Dv for 62780@debbugs.gnu.org; Thu, 13 Apr 2023 06:44:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmuRC-0000im-BP; Thu, 13 Apr 2023 06:44:22 -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=DykV/vW7eXMPVIUVRZS7AVjzljdg3bMENS2RyezoNxQ=; b=HtE3joT1uI2M HZlBehpRIWewlBRmjdDnpRNIK1pWfyZ9owllR0i0SRKaz7cTVRQnFYHqkvkAAz3VEl5iL1zVyGBRa j6ywwX3q3ZD5LW5cIZiaAS82h5jf6WgHBv/64fFsPr+OoWcqPpdDDB2OwUpNLGTPP9xW0u2WN9z6w aQGD9CJTGncHH6C/sLappO9opO/2foqEMOAaXbLSEz5tlZwcM7diCBHwIb0FVmiQAQt7rzRsOiFme YZrD/bYeLb7pjuT9+E/ekW8kdyO2eboJIEKeXodpc6f5VsPMpGQMqSWk0eorTND0Uno3CxPle/NTx p8abSXqSEvlJSX5gIdIsfw==; Received: from [87.69.77.57] (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 1pmuRB-0005XA-FF; Thu, 13 Apr 2023 06:44:21 -0400 Date: Thu, 13 Apr 2023 13:45:07 +0300 Message-Id: <83ttxk3vt8.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87bkjsf72g.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Apr 2023 09:46:31 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Thu, 13 Apr 2023 09:46:31 +0000 > > Eli Zaretskii writes: > > > See above: show-trailing-whitespace is not the main culprit here; > > these particular display properties are. If you could produce a perf > > profile with this recipe, it might give ideas for speeding up the C > > code without any changes on the Lisp level. > > Here are perf results when typing, using the same recipe. > > Full summary: > > 29.89% emacs emacs [.] lookup_char_property > 16.58% emacs emacs [.] next_interval > 13.99% emacs emacs [.] Fassq > 5.44% emacs emacs [.] find_interval > 5.17% emacs emacs [.] Fcdr > 3.97% emacs emacs [.] Fnext_single_property_change > 2.32% emacs emacs [.] composition_compute_stop_pos > 1.51% emacs emacs [.] validate_interval_range > 1.03% emacs emacs [.] get_char_property_and_overlay > 0.99% emacs emacs [.] textget > 0.79% emacs emacs [.] plist_get > 0.77% emacs emacs [.] produce_stretch_glyph > 0.76% emacs emacs [.] balance_an_interval > 0.54% emacs emacs [.] lface_hash > > Call graph: > > (next_interval is spread thin across the call graph, used all over the place) > > 99.10%--command_loop_1 > 97.65%--read_key_sequence > 97.55%--read_char > 97.51%--redisplay redisplay_internal > 97.49%--redisplay_windows internal_condition_case_1 redisplay_window_0 > 97.49%--redisplay_window > |65.03%--try_window > ||32.55%--display_line > || 28.90%--get_next_display_element > || 28.83%--next_element_from_buffer > || 28.75%--handle_stop > || 23.87%--compute_stop_pos > || 23.52%--composition_compute_stop_pos > || 21.61%--find_composition > || 21.31%--Fnext_single_property_change > || 17.84%--textget > || 16.84%--lookup_char_property > || 6.15%--builtin_lisp_symbol > || 5.28%--make_lisp_symbol > || 5.94%--Fassq > || 32.47%--partial_line_height move_it_to > | 31.11%--move_it_in_display_line_to > | 28.95%--get_next_display_element > | 28.86%--next_element_from_buffer > | 28.80%--handle_stop > | ... 16.75%--lookup_char_property > |32.42%--set_vertical_scroll_bar > 32.41%--move_it_to > 31.05%--move_it_in_display_line_to > 28.86%--get_next_display_element > ... 16.54%--lookup_char_property This unfortunately says that looking up text properties is what takes a large fraction of the time, which is consistent with the fact that there are a lot of text properties in the buffer, and they happen almost every character. So maybe the immediate band-aid would be to offer a user option, by default off, which will control whether these 'display' properties are used: only users who actually need to type bidirectional text inside the table will need to turn on the option. Another possibility is to use "Method 1" I described in https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00526.html I know I said afterwards that Method 2 was better (and it is), but I obviously didn't consider the effect on performance, and neither had a test case for that back then. So maybe Method 1, while theoretically less desirable, will in practice do the job and avoid the performance issues, assuming that the invisibility aspect can be ignored (i.e. users won't mind having 1-pixel thin spaces in the cells). From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Apr 2023 11:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168138438210876 (code B ref 62780); Thu, 13 Apr 2023 11:14:01 +0000 Received: (at 62780) by debbugs.gnu.org; 13 Apr 2023 11:13:02 +0000 Received: from localhost ([127.0.0.1]:42702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmusv-0002pC-SV for submit@debbugs.gnu.org; Thu, 13 Apr 2023 07:13:02 -0400 Received: from mout02.posteo.de ([185.67.36.66]:59295) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmuss-0002oo-9J for 62780@debbugs.gnu.org; Thu, 13 Apr 2023 07:13:00 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5EDED240461 for <62780@debbugs.gnu.org>; Thu, 13 Apr 2023 13:12:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681384372; bh=Aa1ks4pUN/bllbNQvTmT1H/GCqfjSRhq0bjsXv5I108=; h=From:To:Cc:Subject:Date:From; b=YtSmfW1t9RtdmwAB42/4esUceme7hLfeiGeOMibJ8Q+q44reVnce5y6jb5flbx3YU 5yjRn+Ah4gaUb6vkulxg+Sml26KO5pyLaZRJ0gteJBoKjETD1WX9VShVw6FaVhaxPa cFPcQzyKGWCYt46f3dW6S9TRi6Rd3G7kHS8eGNj930i9aURLLe5UbTd6NwRhyX/SHy bcH5iRLBnixEwXtHFbM+XiQjOPNF1rcmw5updtCMEeMLnbnjfm4nNvMw9CvaMtzzlq jNhZ9+8M+AdKWRbhJLskXOny/0UBH1qCHBdGh5cnfekmJaedLUNa9bwkitJ74ZgEPC GDwhO8vhDbJoA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pxxkq5jkDz9rxB; Thu, 13 Apr 2023 13:12:51 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83ttxk3vt8.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> Date: Thu, 13 Apr 2023 11:15:21 +0000 Message-ID: <873554f2ye.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> 28.86%--get_next_display_element >> ... 16.54%--lookup_char_property > > This unfortunately says that looking up text properties is what takes > a large fraction of the time, which is consistent with the fact that > there are a lot of text properties in the buffer, and they happen > almost every character. This looks up a very specific text property - 'composition. The property that does not even exist in the buffer. The lookup takes so long because buffer interval tree is very fragmented - each table cell adds at least 4 intervals. May Emacs hold a property cache and make textget search EQ property lists just once? Or, may it make sense to maintain additional interval trees for some important text properties like 'invisible/'composition/'display? These trees will only track text regions containing these important text properties? Then, `next-single-property-change' can be much, much faster compared to the current scan across all the buffer intervals. > So maybe the immediate band-aid would be to offer a user option, by > default off, which will control whether these 'display' properties are > used: only users who actually need to type bidirectional text inside > the table will need to turn on the option. While it might fix the immediate issue for some set of users, it will also limit our options to make use of 'display text property in tables. In particular, it will be nice to auto-adjust the table column width with pixel precision - one of the top-requested features for Org. > Another possibility is to use "Method 1" I described in > > https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00526.html > > I know I said afterwards that Method 2 was better (and it is), but I > obviously didn't consider the effect on performance, and neither had a > test case for that back then. So maybe Method 1, while theoretically > less desirable, will in practice do the job and avoid the performance > issues, assuming that the invisibility aspect can be ignored > (i.e. users won't mind having 1-pixel thin spaces in the cells). I'd very much prefer to avoid Method 1. It will "litter" the Org files, unless we also remove these symbols during save. And people will definitely complain about kill containing "weird" staff. So, then also substring filters. I am afraid that Method 1 will cause more trouble in practice. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Apr 2023 14:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168139635012319 (code B ref 62780); Thu, 13 Apr 2023 14:33:02 +0000 Received: (at 62780) by debbugs.gnu.org; 13 Apr 2023 14:32:30 +0000 Received: from localhost ([127.0.0.1]:44393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmxzy-0003Cb-3g for submit@debbugs.gnu.org; Thu, 13 Apr 2023 10:32:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmxzw-0003CI-Gj for 62780@debbugs.gnu.org; Thu, 13 Apr 2023 10:32:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmxzq-0004pk-U6; Thu, 13 Apr 2023 10:32:22 -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=kaPXF1/Q6LGnsxleOqg7ocizU/d5eABS43Jds4GSS/k=; b=p4VkmdeyxK+B P8GTYF3AVL2qAed7Ku5ovdxnn5+lAg60CDBuPdHIibJ4o7I2o4KWPcFUfvUZWPcxQjfD6U8crTRnD SpVw353TubnOSBg3EeLPaC6FMznOCSvrhy4h/pc8D22cwaj++pVKpzaOiH/sMrg61w5s58j+wUraJ KtPAaBzlq2dY+tiEF+lfkP06ID/bBX3NZ1vIGL4OpJKCyRgQpcBikoV3bQudrTKnW14gR9yeNR2g7 /T7/CStXS/vWUK9UTy06b53dm+DioAOanvvi78Y/Qkgr9R8vkRvfizQeB16rbrwqJyUl0QOMcXruB ugaJQLBOm8IzJKH/W3RuyQ==; Received: from [87.69.77.57] (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 1pmxzq-0000Zx-Ci; Thu, 13 Apr 2023 10:32:22 -0400 Date: Thu, 13 Apr 2023 17:33:09 +0300 Message-Id: <83sfd34ztm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <873554f2ye.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Apr 2023 11:15:21 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Thu, 13 Apr 2023 11:15:21 +0000 > > Eli Zaretskii writes: > > >> 28.86%--get_next_display_element > >> ... 16.54%--lookup_char_property > > > > This unfortunately says that looking up text properties is what takes > > a large fraction of the time, which is consistent with the fact that > > there are a lot of text properties in the buffer, and they happen > > almost every character. > > This looks up a very specific text property - 'composition. Are you sure? look up_char_property is also called for processing 'display' properties. Here's the chain: handle_display_prop -> get_char_property_and_overlay -> Fget_text_property -> textget -> lookup_char_property > The property that does not even exist in the buffer. The lookup > takes so long because buffer interval tree is very fragmented - each > table cell adds at least 4 intervals. > May Emacs hold a property cache and make textget search EQ property > lists just once? > > Or, may it make sense to maintain additional interval trees for some > important text properties like 'invisible/'composition/'display? These > trees will only track text regions containing these important text > properties? Then, `next-single-property-change' can be much, much faster > compared to the current scan across all the buffer intervals. These ideas came up before, but implementing them is not easy and would add quite a bit of complexity. We could, perhaps, keep a buffer-local flag to record whether 'composition' property was ever set on any buffer text, but once the flag is set, we won't easily know if it could be reset. Moreover, I just disabled static compositions completely, by making find_composition return zero immediately, which basically avoids the calls to next/previous-single-property-change which search for 'composition' property, and I still see quite a significant slowdown with the recipe of this bug (50x30 org-table). Can you reproduce this? If you can, what does the profile say now? From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 09:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168146387727647 (code B ref 62780); Fri, 14 Apr 2023 09:18:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 09:17:57 +0000 Received: from localhost ([127.0.0.1]:45503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnFYw-0007Ba-AM for submit@debbugs.gnu.org; Fri, 14 Apr 2023 05:17:57 -0400 Received: from mout01.posteo.de ([185.67.36.65]:58657) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnFYg-0007B4-Nk for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 05:17:45 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A5A59240291 for <62780@debbugs.gnu.org>; Fri, 14 Apr 2023 11:17:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681463844; bh=HgwtyvwJHTSjvFtbH6FVfAKdxYdQOT1WBVLX6wC8hZE=; h=From:To:Cc:Subject:Date:From; b=f/XaJNhH99XETWjTciUt3nlMTnzprp9NS7UeVtUIiH4Rf6rgwG3sH1S5Li3zmj3Rr 3m68tRmH6ojaWd0s1taVpH6982mATVar220Nic/Ep1Xt33jrc89req2HOC8esM493i PB0S4gUXEoL/DfeHKNioOBShQ5r7I+us2pU2gsW8o7+KPSS53k2GPPWKBSF7uJFiII BEJSqglX7w4llFnW48+B58XxLr2J5mFKOV9cpTxCHwl5N/1c2XPmHgyqquf+aQzIUp NOVoDWus1FEZN3Wgad7SMbZLyoWsliZfuO/x6g9bzzmbc5FExzJ3DR2m5YqB1yw9Wx 4lrbd1QZ9LZwQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PyW78042gz9rxP; Fri, 14 Apr 2023 11:17:23 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83sfd34ztm.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> Date: Fri, 14 Apr 2023 09:20:01 +0000 Message-ID: <87zg7an7lq.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> This looks up a very specific text property - 'composition. > > Are you sure? look up_char_property is also called for processing > 'display' properties. Here's the chain: > > handle_display_prop > -> get_char_property_and_overlay > -> Fget_text_property > -> textget > -> lookup_char_property AFAIU, it does not show up in the call graph. So, even if it is called, somehow, it should be fewer times. May composition be queried excessively compared to 'display? >> Or, may it make sense to maintain additional interval trees for some >> important text properties like 'invisible/'composition/'display? These >> trees will only track text regions containing these important text >> properties? Then, `next-single-property-change' can be much, much faster >> compared to the current scan across all the buffer intervals. > > These ideas came up before, but implementing them is not easy and > would add quite a bit of complexity. Is it a problem to keep multiple interval trees: one for all properties, and several for individual properties? Then, all the code dealing with intervals can be extended, repeating interval tree edits for the extra trees. When the special properties are requested, we can then work with special trees instead. > We could, perhaps, keep a > buffer-local flag to record whether 'composition' property was ever > set on any buffer text, but once the flag is set, we won't easily know > if it could be reset. I do not feel like it will improve things in practice - complex buffers with 'display/'composition properties are the ones that tend to be slow. Simpler buffers with less text properties are already not problematic. > Moreover, I just disabled static compositions completely, by making > find_composition return zero immediately, which basically avoids the > calls to next/previous-single-property-change which search for > 'composition' property, and I still see quite a significant slowdown > with the recipe of this bug (50x30 org-table). Can you reproduce > this? If you can, what does the profile say now? I cannot reproduce. The typing has no noticeable delays. I used ./configure && make with @@ -421,6 +421,7 @@ find_composition (ptrdiff_t pos, ptrdiff_t limit, ptrdiff_t *start, ptrdiff_t *end, Lisp_Object *prop, Lisp_Object object) { + return 0; Best, Ihor From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 10:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.16814686435742 (code B ref 62780); Fri, 14 Apr 2023 10:38:01 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 10:37:23 +0000 Received: from localhost ([127.0.0.1]:45613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnGny-0001UY-UD for submit@debbugs.gnu.org; Fri, 14 Apr 2023 06:37:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnGnn-0001U7-Da for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 06:37:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pnGnh-0005G8-TL; Fri, 14 Apr 2023 06:37:05 -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=6jTLJOFPDCe+Ums3T6PkiLTVGnJ1HGMRHmy/JS4aEdI=; b=WxzqPI+aPy2s mzzeJGA9b6v2P32hx+ubLVBlljVASAptaEnGaLrJWf1jgOlgubX9DHRg3+ioqGHaZbuHeLvw3uONB 7m59LmTXUyKj7jjYpB0B18c3zSPJtOc0AOBzgHUew5ibPqUZRyglZK9HBUE1vyCGa7H70SbEOE8jo JmzKtHmZViC6x5Njn31Xa0IpkEkVJMYU7Y1Qu2DSD1WUUlcKmGmeA3y6gaRQ+Lf8PdaiggG04/cdk 3MPMMWRt8zQ9FFFe9SW20PfpmPwXoQ7FcqsgH4nEd24YuQ5Peena/apgq9CNwkpmunm7mjtzhRQ3U nx4rxfWRF/v2+FBexyoH5w==; Received: from [87.69.77.57] (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 1pnGnh-0001TC-9e; Fri, 14 Apr 2023 06:37:05 -0400 Date: Fri, 14 Apr 2023 13:37:02 +0300 Message-Id: <83ttxig375.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87zg7an7lq.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Apr 2023 09:20:01 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Fri, 14 Apr 2023 09:20:01 +0000 > > Eli Zaretskii writes: > > > Moreover, I just disabled static compositions completely, by making > > find_composition return zero immediately, which basically avoids the > > calls to next/previous-single-property-change which search for > > 'composition' property, and I still see quite a significant slowdown > > with the recipe of this bug (50x30 org-table). Can you reproduce > > this? If you can, what does the profile say now? > > I cannot reproduce. > The typing has no noticeable delays. Your build is optimized, yes? Try building without optimizations, you will see quite significant delays just by creating the table. In any case, if you think disabling static composition can be a reasonable option for Org Table users (do they use prettify-symbols-mode, for example, in the same buffer where they have Org tables?), that should be easy. > Is it a problem to keep multiple interval trees: one for all properties, > and several for individual properties? Yes, I think so, because search for any non-nil properties will be greatly complicated. But if someone wants to work on such a split, and can present working code, I won't reject it without testing. From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 11:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168147202521474 (code B ref 62780); Fri, 14 Apr 2023 11:34:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 11:33:45 +0000 Received: from localhost ([127.0.0.1]:45675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnHgW-0005aH-H8 for submit@debbugs.gnu.org; Fri, 14 Apr 2023 07:33:44 -0400 Received: from mout01.posteo.de ([185.67.36.65]:34353) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnHgT-0005a2-N3 for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 07:33:42 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D89F02402F6 for <62780@debbugs.gnu.org>; Fri, 14 Apr 2023 13:33:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681472014; bh=6KI1cKf2eYad1621gCZeCVXL4tysWK25vTY0N5lrT9U=; h=From:To:Cc:Subject:Date:From; b=MC/LCCJO8bTvA1nldNQtxdtobxup20wFEEQLmBVpcLhMrojCAArS48SXy4BVlSFnC WZmwtsfgty7K8EWbL7LwvxAfMOph6Z7c2Et6uyxbYaUfsND6+y+Eircp9L5DUm3EtT rm/HDgUzZaOq78eWfm3SxtMSqG8T5u9j64KC0Hi+4HXWR+p1rM575KoE8sXzBehsWe V4a5Od+8qf46G5gTtY2if2yT8GWqev5oDnJaDM/SYaaULQkKB1fpgPIX3lAPHzJKnD riqDNohdgWIpBW9LB1mBYM+SVnCg2ixVhawIiK2JkRRJp0ZmGhccBITEvWYUgJ/tTY VboZQMCwgzOlw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PyZ8G3HXBz9rxf; Fri, 14 Apr 2023 13:33:34 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83ttxig375.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> Date: Fri, 14 Apr 2023 11:36:09 +0000 Message-ID: <87pm86n1au.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> I cannot reproduce. >> The typing has no noticeable delays. > > Your build is optimized, yes? Try building without optimizations, you > will see quite significant delays just by creating the table. Sure, but there is no obvious culprit then: 4.01% emacs emacs [.] lookup_char_property 3.04% emacs emacs [.] make_lisp_symbol 3.01% emacs emacs [.] find_interval 2.85% emacs emacs [.] next_interval 2.37% emacs emacs [.] XSYMBOL 2.27% emacs emacs [.] SYMBOLP 2.16% emacs emacs [.] make_lisp_symbol 2.06% emacs emacs [.] make_lisp_symbol Various functions contribute almost equally with relatively larger (yet, just 4%) contribution from lookup_char_property called from face_at_pos (according to the call graph). I looked into the number of calls to face_at_pos, find_composition, and handle_display_prop. The number of calls is almost the same. Thus, my guess is that find_composition is somehow slower than the other two functions. Looking int the code, I can see that handle_display_prop does not call Fnext_single_property_change at all and face_at_pos limits the forward lookup by TEXT_PROP_DISTANCE_LIMIT. In contrast, compute_stop_pos calls composition_compute_stop_pos without making use of TEXT_PROP_DISTANCE_LIMIT (AFAIU) and looks all the way to point-max. (Do I understand correctly that it implies O(N_intervals^2)??) > In any case, if you think disabling static composition can be a > reasonable option for Org Table users (do they use > prettify-symbols-mode, for example, in the same buffer where they have > Org tables?), that should be easy. I'd still prefer to find a better way and leave this workaround as the last resort. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 12:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168147398825862 (code B ref 62780); Fri, 14 Apr 2023 12:07:01 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 12:06:28 +0000 Received: from localhost ([127.0.0.1]:45710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnICC-0006j4-5I for submit@debbugs.gnu.org; Fri, 14 Apr 2023 08:06:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnICA-0006ip-MO for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 08:06:27 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pnIC5-0008GQ-8I; Fri, 14 Apr 2023 08:06:21 -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=aisgFXqnHaLwYecvJx/pGVRRAfUh2/SRvg3vp6JjePA=; b=AEZTfoHLK5Ya JUL0li23uevL0/qWBEYdN6+Z/ZBiVnni2ESxtvHS7VxUyMBNPNCRCx7jUCz5mB/vPPZyaF3EJwz18 FTU3SLj2qglidgx0UA8zQ8OO36gM93v1iTbJOtEupRzxVW0BwM7psbwEirY6WfWGLdX1l5Af0y3CH /2Y186NHIvSYCjUWZp7qQDKpHo8/QAyLF78dy4M2jT0NK+pXIKdNjfKOeedINizX0A5r/jqY5g4O7 NIgz1CC3UD0CLpouZenDnzpiRmwDWRR3Qm8v9NHtjR3KcLe6KGYwiGFwL3cYUbIDOdBWsebZOjnc4 gh5BO14Pvsn2QX54CYDaEg==; Received: from [87.69.77.57] (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 1pnIC4-0006Zb-Gb; Fri, 14 Apr 2023 08:06:20 -0400 Date: Fri, 14 Apr 2023 15:06:17 +0300 Message-Id: <83pm86fz2e.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87pm86n1au.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Apr 2023 11:36:09 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Fri, 14 Apr 2023 11:36:09 +0000 > > Eli Zaretskii writes: > > >> I cannot reproduce. > >> The typing has no noticeable delays. > > > > Your build is optimized, yes? Try building without optimizations, you > > will see quite significant delays just by creating the table. > > Sure, but there is no obvious culprit then: The culprit is the humongous number of calls to handle_stop, I think. > Looking int the code, I can see that handle_display_prop does not call > Fnext_single_property_change at all and face_at_pos limits the forward > lookup by TEXT_PROP_DISTANCE_LIMIT. In contrast, compute_stop_pos calls > composition_compute_stop_pos without making use of > TEXT_PROP_DISTANCE_LIMIT (AFAIU) and looks all the way to point-max. (Do > I understand correctly that it implies O(N_intervals^2)??) > > > In any case, if you think disabling static composition can be a > > reasonable option for Org Table users (do they use > > prettify-symbols-mode, for example, in the same buffer where they have > > Org tables?), that should be easy. > > I'd still prefer to find a better way and leave this workaround as the > last resort. OK, I have an idea: I think the fact that compute_stop_pos calls find_composition (via composition_compute_stop_pos) is a mistake, because the 'composition' text property is found by the previous code in compute_stop_pos, exactly like we find 'display' and 'fontified'. So compute_stop_pos has no reason to call find_composition. But to test this idea, I need enough test cases that use the 'composition' property to make sure the property still works after I disable that call. Can you collect a few test cases which use the 'composition' property, with or without Org tables? I guess prettify-symbols-mode is one of them, but are there others? I will then try to find time to test this idea. From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 12:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: yantar92@posteo.net Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168147505027868 (code B ref 62780); Fri, 14 Apr 2023 12:25:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 12:24:10 +0000 Received: from localhost ([127.0.0.1]:45757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnITK-0007FQ-0X for submit@debbugs.gnu.org; Fri, 14 Apr 2023 08:24:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46980) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnITE-0007EX-2D for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 08:24:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pnIT8-0006rX-G3; Fri, 14 Apr 2023 08: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=KJKgo708bek7uO4NegQvsX3Zrc54RWFAOhx3K5/2RfA=; b=FjfJQLZ5IQCV 9GKNULwPkG/qi/VAXe1rOXPzwWLPlpPeOUv5yBhMzFLoQJWOQbH4TTiqD9C+SDVFU5YkU/IkpSOmN NzLjt3OUef3JOwhvog8ih1Lkaan1RdLpaijCu5XtbF8BQltuIWCZU2sLe66cm508w/mX62xsDdFvl dVZITMgjO1FqezKAZWy+jWZBn5FfZ7a9jciAyGlKr57J4NBcfL5LBfYLA8zWUOxAXZw48Ye0MsHvg LZ0ek3LZO1CkdktAQL2WTYzlkWy6iN3BQbZuYZsXUfKagPfr+OuUm6SqqafOfXp7EI0ii2DcG0Gsv 1FrjJDomdIkuErNIYLp7Hg==; Received: from [87.69.77.57] (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 1pnIT6-0004WF-RM; Fri, 14 Apr 2023 08:23:58 -0400 Date: Fri, 14 Apr 2023 15:23:55 +0300 Message-Id: <83mt3afy90.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83pm86fz2e.fsf@gnu.org> (message from Eli Zaretskii on Fri, 14 Apr 2023 15:06:17 +0300) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 62780@debbugs.gnu.org > Date: Fri, 14 Apr 2023 15:06:17 +0300 > From: Eli Zaretskii > > > From: Ihor Radchenko > > Cc: 62780@debbugs.gnu.org > > Date: Fri, 14 Apr 2023 11:36:09 +0000 > > > > Looking int the code, I can see that handle_display_prop does not call > > Fnext_single_property_change at all and face_at_pos limits the forward > > lookup by TEXT_PROP_DISTANCE_LIMIT. In contrast, compute_stop_pos calls > > composition_compute_stop_pos without making use of > > TEXT_PROP_DISTANCE_LIMIT (AFAIU) and looks all the way to point-max. (Do > > I understand correctly that it implies O(N_intervals^2)??) Btw, it is not true that we are looking all the way to point-max in this case: you will see in composition_compute_stop_pos that it limits the search to the next 500 buffer positions: void composition_compute_stop_pos (struct composition_it *cmp_it, ptrdiff_t charpos, ptrdiff_t bytepos, ptrdiff_t endpos, Lisp_Object string) { ptrdiff_t start, end; int c; Lisp_Object prop, val; /* This is from forward_to_next_line_start in xdisp.c. */ const int MAX_NEWLINE_DISTANCE = 500; if (charpos < endpos) { if (endpos > charpos + MAX_NEWLINE_DISTANCE) endpos = charpos + MAX_NEWLINE_DISTANCE; } [...] if (charpos < endpos && find_composition (charpos, endpos, &start, &end, &prop, string) && start >= charpos && composition_valid_p (start, end, prop)) From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 12:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168147515728058 (code B ref 62780); Fri, 14 Apr 2023 12:26:01 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 12:25:57 +0000 Received: from localhost ([127.0.0.1]:45761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnIV2-0007IU-OS for submit@debbugs.gnu.org; Fri, 14 Apr 2023 08:25:57 -0400 Received: from mout01.posteo.de ([185.67.36.65]:39061) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnIV0-0007IH-HD for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 08:25:55 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 92E59240048 for <62780@debbugs.gnu.org>; Fri, 14 Apr 2023 14:25:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681475148; bh=m2YeayJYobX3S3XbqCnisPPaFUiwLgCLm5BZvB0JnsA=; h=From:To:Cc:Subject:Date:From; b=Dg4UTearouuYTUFC5xVPjdxx73My5Az22qSWrrrUar4HMegDX14QEVW8E3XivGNt7 GwedhKEhfWYyZXkAyi9niwKfzuXgjiyuFmCxJYGCedfs69qdGdrlwvfwF06VYkuIPD h0K5Olrbso15lW2XIEjuilq+vpMpJ+BfBnen1hf34A6i/uIrQ/XsUvfKiJD3zyDXpR F4mgfdMoA0mC5LeQrgmBzv5X2jP9udcTDFMtah42PeyzK9ifjjvtGKYRdMh6zzNUOK FWlA59drT4alkmbMt2157YmIw5Rqt3qKryoYKbmiL4v8Rl2dndMEc7FSdm54HQM+RK pz7wsXPlw9gYA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PybJX0W74z9rxH; Fri, 14 Apr 2023 14:25:48 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83pm86fz2e.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> Date: Fri, 14 Apr 2023 12:28:25 +0000 Message-ID: <87edommyvq.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > But to test this idea, I need enough test cases that use the > 'composition' property to make sure the property still works after I > disable that call. Can you collect a few test cases which use the > 'composition' property, with or without Org tables? I guess > prettify-symbols-mode is one of them, but are there others? I will > then try to find time to test this idea. 1. The most obvious is prettify-symbols-mode in Emacs sources Say, (setq-local prettify-symbols-alist '(("!" . ?=C2=AC)) M-x prettify-symbols-mode 2. https://github.com/integral-dw/org-superstar-mode You can use tests/*.org example files Also, https://github.com/jdtsmith/shakespeare.org has a giant example Org file. And https://github.com/casouri/valign/blob/master/test.org has a number of example tables (though the package itself does not use composition). 3. Typing using TeX input method will produce composed glyphs. The same if you set org-pretty-entities to t and then type \alpha, \beta, etc in Org buffers. 4. Composing long spans of text might be a reasonable edge case to test. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 12:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168147660630553 (code B ref 62780); Fri, 14 Apr 2023 12:51:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 12:50:06 +0000 Received: from localhost ([127.0.0.1]:45805 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnIsP-0007wj-Kp for submit@debbugs.gnu.org; Fri, 14 Apr 2023 08:50:06 -0400 Received: from mout01.posteo.de ([185.67.36.65]:55597) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnIsM-0007w8-QD for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 08:50:03 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E69D824029A for <62780@debbugs.gnu.org>; Fri, 14 Apr 2023 14:49:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681476595; bh=EGNwHoQLCAl6pj+KCFY0yyLqOqMRSa8E06/cLTKXUIo=; h=From:To:Cc:Subject:Date:From; b=YDs3lvOUlQ5Ibber0LbNQUJpg+pXDQJHkPCHt3CGqldWa+aATO/MuzpzyLpGk1k1F Nsuz7tV2SpWXmpOwQMaI6zZhvSQbVfL9Kt7ZqR8LvCNuF+P4ls/Q9UxnTj/DaW6nIr O1M/bf3THk77ZySZ+AeGjKNmsHDvtl7IQHBWMs+vXOU+AoNC4S+hZ4ouSSXilyd9Gz waZumDQtSJ3+LImy9BZMTdsB2NDRHR9GavZob0A3t5Sxzfy1fwg2o8lduRpbSms6gb R3CryFtqyQoSzWs2FBBdidd0zGhEcFFv4MmxulRPOoKHs1KTqiQG2NNEvOQE973+f5 4tmINjglHoFOw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PybrL2HyHz9rxQ; Fri, 14 Apr 2023 14:49:54 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83mt3afy90.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <83mt3afy90.fsf@gnu.org> Date: Fri, 14 Apr 2023 12:52:32 +0000 Message-ID: <878reumxrj.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Btw, it is not true that we are looking all the way to point-max in > this case: you will see in composition_compute_stop_pos that it limits > the search to the next 500 buffer positions: Sure. Though 500 is clearly not small enough threshold. Also, I am a bit confused about the purpose of /* Make sure the above arbitrary limit position is not in the middle of composable text, so we don't break compositions by submitting the composable text to the shaper in separate chunks. We play safe here by assuming that only SPC, TAB, FF, and NL cannot be in some composition; in particular, most ASCII punctuation characters could be composed into ligatures. */ in compute_stop_pos AFAIU, it tries hard to not stop in the middle of composed region. Then, why need to fall back to 500 in the composition_compute_stop_pos call? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 13:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168148028114259 (code B ref 62780); Fri, 14 Apr 2023 13:52:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 13:51:21 +0000 Received: from localhost ([127.0.0.1]:45850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnJph-0003hv-3o for submit@debbugs.gnu.org; Fri, 14 Apr 2023 09:51:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnJpe-0003hG-VC for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 09:51:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pnJpZ-00017z-6p; Fri, 14 Apr 2023 09:51:13 -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=nGrlzUztodMFl2HqlYY1Pv1sy9jImBCzsd9hz55eZ3w=; b=Y4r030835Kzi 7iP+uXKuJrspibJ8mgu+LB/VO3989RU0TnUnXKQb98g/BE885X8UOeCzuuc9ixnxdQzgGYowVH8T1 M2Q0z7GwZ9/q6NVZu6CgMj6R4oESem6wA1PjtUKSi/Eyxcv2aAFm9RXkmj8Zh2+7Ju1wL7Ntzb6iE lfJmDRd8Jab//Y/9A1Jp7V4MS62/x0BcMSQXXmhCvb6iWTOd8chfXjp6kPT8AoYMeBvXJTX0GhvEb djNDTedZ/NlaqM0MBAKb+5a419GIoYWm2yknVk7uVjKcM2nyUn/JAnPa6bF5QexaaQdCQKegq+/+i wSU0TeAQcCLZ1WpHpjAvpw==; Received: from [87.69.77.57] (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 1pnJpW-000272-QH; Fri, 14 Apr 2023 09:51:12 -0400 Date: Fri, 14 Apr 2023 16:51:08 +0300 Message-Id: <83fs92fu7n.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <878reumxrj.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Apr 2023 12:52:32 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <83mt3afy90.fsf@gnu.org> <878reumxrj.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Fri, 14 Apr 2023 12:52:32 +0000 > > Also, I am a bit confused about the purpose of > > /* Make sure the above arbitrary limit position is not in the > middle of composable text, so we don't break compositions by > submitting the composable text to the shaper in separate > chunks. We play safe here by assuming that only SPC, TAB, > FF, and NL cannot be in some composition; in particular, most > ASCII punctuation characters could be composed into ligatures. */ > > in compute_stop_pos > > AFAIU, it tries hard to not stop in the middle of composed region. That one is mainly about automatic compositions, not static compositions. > Then, why need to fall back to 500 in the > composition_compute_stop_pos call? Because composition_compute_stop_pos is called from many other places, for other reasons. From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 13:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168148046614602 (code B ref 62780); Fri, 14 Apr 2023 13:55:01 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 13:54:26 +0000 Received: from localhost ([127.0.0.1]:45859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnJsg-0003nQ-0e for submit@debbugs.gnu.org; Fri, 14 Apr 2023 09:54:26 -0400 Received: from mout02.posteo.de ([185.67.36.66]:53445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnJsd-0003mx-Up for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 09:54:24 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 26C14240383 for <62780@debbugs.gnu.org>; Fri, 14 Apr 2023 15:54:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681480458; bh=I9JWLOhsoDginbEOd9jUMh9fNdSWAJTDD9+kfIvitH8=; h=From:To:Cc:Subject:Date:From; b=SdZALmTMNnDGqBgd1l0LcVQr4AsClVNtf0Cemx7xaJI/R5/rtBYySGmjcD8lPDSQz P6KM1kVckYwlDYFhddEF8OCfj7bNDda7BLvsRF/QPxE+S2FiXw9KC9KJgJb/+fon1d EZB78EUii5diGFmeQCrK6KLZvHeMPAEfmMc0ablRV3pUuYtabckr59UKQWvPHGKP6p RkRq6ffirzTJQ/FFP/iXEumGVLn/cIaim0Lk+WVH4oJc5GdZb8qThKu0Qyc/1Pb34m n8iXLvoQgB+OWnPsAJhrhhLF3IKmcRdpX1gSt5GV8pNIAEONFC6nEGtAlKufdk44B+ dZo+F2A5jk+FA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PydGd6GYvz6tv5; Fri, 14 Apr 2023 15:54:17 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83fs92fu7n.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <83mt3afy90.fsf@gnu.org> <878reumxrj.fsf@localhost> <83fs92fu7n.fsf@gnu.org> Date: Fri, 14 Apr 2023 13:56:55 +0000 Message-ID: <873552mus8.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> AFAIU, it tries hard to not stop in the middle of composed region. > > That one is mainly about automatic compositions, not static > compositions. >> Then, why need to fall back to 500 in the >> composition_compute_stop_pos call? > > Because composition_compute_stop_pos is called from many other places, > for other reasons. I see. But can the same limit be re-used for static compositions? At least within the specific call to composition_compute_stop_pos from compute_stop_pos? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168148366721849 (code B ref 62780); Fri, 14 Apr 2023 14:48:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 14:47:47 +0000 Received: from localhost ([127.0.0.1]:47261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnKiJ-0005gK-7p for submit@debbugs.gnu.org; Fri, 14 Apr 2023 10:47:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnKiH-0005fT-65 for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 10:47:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pnKiB-0007mI-KA; Fri, 14 Apr 2023 10:47:39 -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=7FVzhj0bmFXgEh5jd7l0GP3X+3YigSsU8FnesYWHMyo=; b=FYIcS1dwwEpr vmKzdMxYfzn2N1iYyETXCHPnqSOjR4v0r7uGBpeR8WYHe8axeLtKjqXOLCVKRUeJvpLDSRJtsyNBM m2WrVUDaYe3weGVgSVxKB/0zHihkeqro/vosVKhJcrtbSHVV/rf+R0Fbfz0evO/HxF1zcKGGklryB p6heoR0j3kSg91FVdSApkn3wHE0OH3h3JqE4bUKvsdRTBFsN8m2/G/AbeVgJd563yic0O2tirGEKk Z1AVarlMwo2EBNyXDi98gO9HwnqLbiOqysHrcyisFs8YkuHGRflhT7GkD8OyFpxW6zTxvi9m3nivv MbxpCQagpbQZLsfyCtsHfQ==; Received: from [87.69.77.57] (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 1pnKiA-00027Z-Cd; Fri, 14 Apr 2023 10:47:39 -0400 Date: Fri, 14 Apr 2023 17:47:35 +0300 Message-Id: <83edomfrlk.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <873552mus8.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Apr 2023 13:56:55 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <83mt3afy90.fsf@gnu.org> <878reumxrj.fsf@localhost> <83fs92fu7n.fsf@gnu.org> <873552mus8.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Fri, 14 Apr 2023 13:56:55 +0000 > > Eli Zaretskii writes: > > >> AFAIU, it tries hard to not stop in the middle of composed region. > > > > That one is mainly about automatic compositions, not static > > compositions. > > >> Then, why need to fall back to 500 in the > >> composition_compute_stop_pos call? > > > > Because composition_compute_stop_pos is called from many other places, > > for other reasons. > > I see. But can the same limit be re-used for static compositions? Which limit is that? From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168148403022979 (code B ref 62780); Fri, 14 Apr 2023 14:54:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 14:53:50 +0000 Received: from localhost ([127.0.0.1]:47274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnKo9-0005yZ-J0 for submit@debbugs.gnu.org; Fri, 14 Apr 2023 10:53:49 -0400 Received: from mout01.posteo.de ([185.67.36.65]:56309) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnKo7-0005yJ-US for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 10:53:48 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id EB9512401DE for <62780@debbugs.gnu.org>; Fri, 14 Apr 2023 16:53:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681484022; bh=gYAfjJORPSAqzEmHq2WUZTyzzdhlDhvrD1vVjgsIRO8=; h=From:To:Cc:Subject:Date:From; b=PzW5DRbgZmiD/D4BvnXMSpGD9g5cDeiS9z7bmOCAIjOKmjAnaDE3cXIrD89jyWJRg g8kOOzhh98Gqfw1Uo2nwwSyqgYUQhfB7WiQoph9Kbfudcs/A7ku0dHbqydM7e/3Ftc 23ubGD6kuQTUWCWccM/wQP/9HoXWGzUpAECx9hhuFln8bzV+xDZZkjVNW8FEwiTp3M DmEymz3ctFV2C+lnU+hDOqVtzK6wf02ZnfVkP0O7giXApviY+fzGwI5o2AcX+u9USR MPonlPsA9IU9hz6SHzm4mriezp2E9K1TXou0l0doqI+Fu7zJwf0f+dvW7MpS1NIQAU CJatm/Ks1bKsw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Pyfb91wP5z9rxH; Fri, 14 Apr 2023 16:53:40 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83edomfrlk.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <83mt3afy90.fsf@gnu.org> <878reumxrj.fsf@localhost> <83fs92fu7n.fsf@gnu.org> <873552mus8.fsf@localhost> <83edomfrlk.fsf@gnu.org> Date: Fri, 14 Apr 2023 14:56:13 +0000 Message-ID: <87zg7aldgy.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> I see. But can the same limit be re-used for static compositions? > > Which limit is that? I am referring to limit in compute_stop_pos. It is unused when calling composition_compute_stop_pos. Of course, if your idea with completely bypassing composition_compute_stop_pos call works, it will be even better. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 15:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168148480124756 (code B ref 62780); Fri, 14 Apr 2023 15:07:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 15:06:41 +0000 Received: from localhost ([127.0.0.1]:47298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnL0a-0006RE-Jo for submit@debbugs.gnu.org; Fri, 14 Apr 2023 11:06:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnL0Y-0006Qu-QP for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 11:06:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pnL0S-0003BU-90; Fri, 14 Apr 2023 11:06:32 -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=BnAv13ZcDFPSNqGzYK0T5R+RyjsRP6Sjz7B1SRrci0A=; b=NwH1F93xxCcP WBgCDNZogywwg7CFv2/eijfW41uyKu0sJ0ct9CgL51gUzEMbRNF06NnAsVePyBMDfI7tDgWpuIjai WvcpGYFc34nvOz6YFyGPrKxWyMWsqg674axvqtr/vlXdRu/jAfG03iXbPKvnwQ/MeFf2KgUzQmEuS SoNBeg/Jn2kOj/xOWNVYb5APohUti7hy8HBRyLlfBs33PpE319DeI9PiGVkck3jdo7iUAVtxCk+zG tVAdIDOtyQ2zVpI4TcW24zU0AqjYD7XnbkwQamCR74/4ko19mxfWp1vvE8YkZwNE6S59tmuqdx20i ml0FX8PttQLxXTSP+4rq1Q==; Received: from [87.69.77.57] (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 1pnL0R-0008Fd-P1; Fri, 14 Apr 2023 11:06:32 -0400 Date: Fri, 14 Apr 2023 18:06:29 +0300 Message-Id: <83bkjqfqq2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87zg7aldgy.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Apr 2023 14:56:13 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <83mt3afy90.fsf@gnu.org> <878reumxrj.fsf@localhost> <83fs92fu7n.fsf@gnu.org> <873552mus8.fsf@localhost> <83edomfrlk.fsf@gnu.org> <87zg7aldgy.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Fri, 14 Apr 2023 14:56:13 +0000 > > Eli Zaretskii writes: > > >> I see. But can the same limit be re-used for static compositions? > > > > Which limit is that? > > I am referring to limit in compute_stop_pos. It is unused > when calling composition_compute_stop_pos. You want to reduce the limit inside composition_compute_stop_pos from 500 to 100? If you try that, does it speed up this scenario enough to consider such a change? > Of course, if your idea with completely bypassing > composition_compute_stop_pos call works, it will be even better. We cannot bypass composition_compute_stop_pos in compute_stop_pos, because it also looks for auto-composable characters, those controlled by composition-function-table. But I think we _can_ avoid calling find_composition from composition_compute_stop_pos in this particular case. From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 15:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.168148568026288 (code B ref 62780); Fri, 14 Apr 2023 15:22:02 +0000 Received: (at 62780) by debbugs.gnu.org; 14 Apr 2023 15:21:20 +0000 Received: from localhost ([127.0.0.1]:47312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnLEl-0006pu-PX for submit@debbugs.gnu.org; Fri, 14 Apr 2023 11:21:20 -0400 Received: from mout02.posteo.de ([185.67.36.66]:48349) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnLEj-0006ph-J8 for 62780@debbugs.gnu.org; Fri, 14 Apr 2023 11:21:18 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 92213240333 for <62780@debbugs.gnu.org>; Fri, 14 Apr 2023 17:21:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681485671; bh=AulPT+XzEavKkj71Mw6eB0xXFwfWKP/lBwh7EVKY1x4=; h=From:To:Cc:Subject:Date:From; b=AbWPQGsO1cSsKLuu8XSaS1yWzAEW6K0TX2/gn6ouOBY4qs106Q23hvQy4WnUE4Xd3 927Sb/zCbaoyWvEhWH4a+TWwVj45jWqivWAbgednIi8RsofEhelhtqQCMBNUvFIjCd Lh/Nzty+acFxAI/jfAartxwFBw2ny9GXRYuz+Wk6ASrObQt0KhB72Xyxp/FC3q76g/ EbgUnvlFmFK/zTogYF+kiIxOO4m8ETeKGvkHXjXMdtz2s378eZboXbK+lZa1kDmfkv FmcAYbOTxWL+Jyb3LfOzws6iMbfX7OboJjiwEP4d1O1ehFNgXuFoQWseeXt9MKt1ub BTrcN6yiqDdEw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PygBv1Sd5z6txF; Fri, 14 Apr 2023 17:21:11 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83bkjqfqq2.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <83mt3afy90.fsf@gnu.org> <878reumxrj.fsf@localhost> <83fs92fu7n.fsf@gnu.org> <873552mus8.fsf@localhost> <83edomfrlk.fsf@gnu.org> <87zg7aldgy.fsf@localhost> <83bkjqfqq2.fsf@gnu.org> Date: Fri, 14 Apr 2023 15:23:48 +0000 Message-ID: <87wn2elc6z.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> I am referring to limit in compute_stop_pos. It is unused >> when calling composition_compute_stop_pos. > > You want to reduce the limit inside composition_compute_stop_pos from > 500 to 100? If you try that, does it speed up this scenario enough to > consider such a change? There is a noticeable speed up on the optimized build. The delay is not completely gone though. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Apr 2023 08:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.16827586635989 (code B ref 62780); Sat, 29 Apr 2023 08:58:02 +0000 Received: (at 62780) by debbugs.gnu.org; 29 Apr 2023 08:57:43 +0000 Received: from localhost ([127.0.0.1]:35214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psgOl-0001YX-Ff for submit@debbugs.gnu.org; Sat, 29 Apr 2023 04:57:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34206) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psgOe-0001YD-Ik for 62780@debbugs.gnu.org; Sat, 29 Apr 2023 04:57:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psgOX-00078p-N5; Sat, 29 Apr 2023 04:57:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/LuRCxx2du7Kz+gsmUeLn08OfTwrXOJ+jNrqmPjUukE=; b=nxoFrZPvM7ihAvuII5Zo YZ969iEQ+JOSC0X2fCcFx4tiJprX/57yTz91i0GGyrT1TKYx0RGPpY2ziVUVjL5huJ9Cadh3TRSIX vmbv1QYyLUm2V29cW91rhrecc4YZsGbNLRCs2E91ZdH5LFkODQC2lu7H1MPkZ3tNP8zcogPmgx3FG EeaB8BgKYEZAOop3k/lAgYg1jwbt/FDufvPb6y/MXliESEwpNIOsypxJJ1H1TrReAT4/hZ+4TRb/P tgU/ReC0DVOcp+khF1cGtBnfuI1+UAhxzKeVFF8hqcykM9IysoMqRWueYEYNN1W0ywzGNypwrHy9G 2T+WMfg6c671ZA==; Received: from [87.69.77.57] (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 1psgOJ-0003OI-5W; Sat, 29 Apr 2023 04:57:29 -0400 Date: Sat, 29 Apr 2023 11:57:51 +0300 Message-Id: <835y9fqd4g.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87edommyvq.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Apr 2023 12:28:25 +0000) References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <87edommyvq.fsf@localhost> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 62780@debbugs.gnu.org > Date: Fri, 14 Apr 2023 12:28:25 +0000 > > Eli Zaretskii writes: > > > But to test this idea, I need enough test cases that use the > > 'composition' property to make sure the property still works after I > > disable that call. Can you collect a few test cases which use the > > 'composition' property, with or without Org tables? I guess > > prettify-symbols-mode is one of them, but are there others? I will > > then try to find time to test this idea. > > 1. The most obvious is prettify-symbols-mode in Emacs sources > Say, (setq-local prettify-symbols-alist '(("!" . ?¬)) M-x > prettify-symbols-mode > > 2. https://github.com/integral-dw/org-superstar-mode > You can use tests/*.org example files > Also, https://github.com/jdtsmith/shakespeare.org has a giant example > Org file. And https://github.com/casouri/valign/blob/master/test.org > has a number of example tables (though the package itself does not > use composition). > > 3. Typing using TeX input method will produce composed glyphs. The same > if you set org-pretty-entities to t and then type \alpha, \beta, etc > in Org buffers. > > 4. Composing long spans of text might be a reasonable edge case to test. Thanks, and apologies for the long delay. I've now installed on master several optimizations related to search of composable characters by the display engine. I tested some of the above scenarios (not all of them), and they seem to work as well as before. Do these changes make significant improvements in redisplay speed in org-table buffers? If not, can you tell me where are the hot spots after these changes? Also, if you see any regressions due to these changes, please report them. I will keep this bug open for now. From unknown Sun Jun 15 08:54:21 2025 X-Loop: help-debbugs@gnu.org Subject: bug#62780: 30.0.50; Redisplay gets slow when using Org tables + show-trailing-whitespace Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Apr 2023 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62780 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 62780@debbugs.gnu.org Received: via spool by 62780-submit@debbugs.gnu.org id=B62780.16827912575092 (code B ref 62780); Sat, 29 Apr 2023 18:01:02 +0000 Received: (at 62780) by debbugs.gnu.org; 29 Apr 2023 18:00:57 +0000 Received: from localhost ([127.0.0.1]:36623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psosS-0001K4-Tj for submit@debbugs.gnu.org; Sat, 29 Apr 2023 14:00:57 -0400 Received: from mout01.posteo.de ([185.67.36.65]:59171) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1psosQ-0001Jo-Ky for 62780@debbugs.gnu.org; Sat, 29 Apr 2023 14:00:55 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id ABC20240241 for <62780@debbugs.gnu.org>; Sat, 29 Apr 2023 20:00:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682791248; bh=6EjiGFvap2iG6BvRhZO08mGags39Iajm541IPHIQ2c8=; h=From:To:Cc:Subject:Date:From; b=Iihe3VymLpN1w0NedIHKzLW+ASG5+yvqbjGcXzVtcIHpRWS/g2kkrjZkl+PkA0JjT IPc4F6rIUljiHTHVFqFF3PFbsFNxiiySgFJa5ofpCMEDvz7RxcFm/gpNznCpsdIOUK fYw1GikGtoVcNXzFdyKfApdKbDyyyEt/nnDGinlSiHGwqIxyc/XA55iQ2NG4eUo/de tDO8xsmdT3DqIzYY0esXycoBJmL2Wvz2ff7AVDV1hdV6DLI/t9angSoheNHqZsdmLm OVMcJ+Xig6IUIyy98drSzyDjpRmG3uEEA9lzUXpMsbGu2ywcxSFr7jyhWvgBNdV/bZ 8Wv/fFDS1/x9g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q7y280Pd9z6twh; Sat, 29 Apr 2023 20:00:47 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <835y9fqd4g.fsf@gnu.org> References: <87mt3e8d50.fsf@localhost> <83y1my8bmi.fsf@gnu.org> <87h6tm8awi.fsf@localhost> <83bkjt8t4l.fsf@gnu.org> <87bkjsf72g.fsf@localhost> <83ttxk3vt8.fsf@gnu.org> <873554f2ye.fsf@localhost> <83sfd34ztm.fsf@gnu.org> <87zg7an7lq.fsf@localhost> <83ttxig375.fsf@gnu.org> <87pm86n1au.fsf@localhost> <83pm86fz2e.fsf@gnu.org> <87edommyvq.fsf@localhost> <835y9fqd4g.fsf@gnu.org> Date: Sat, 29 Apr 2023 18:03:48 +0000 Message-ID: <871qk2ftvf.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > I've now installed on master several optimizations related to search > of composable characters by the display engine. I tested some of the > above scenarios (not all of them), and they seem to work as well as > before. Thanks! > Do these changes make significant improvements in redisplay speed in > org-table buffers? If not, can you tell me where are the hot spots > after these changes? With my normal (optimized) build, I can no longer observe typing latency using the original reproducer. > Also, if you see any regressions due to these changes, please report > them. I will keep this bug open for now. So far so good. At least for the compositions I use personally in my pretty-symbols config. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at