From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Aug 2023 09:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 65451@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.169269663524642 (code B ref -1); Tue, 22 Aug 2023 09:31:01 +0000 Received: (at submit) by debbugs.gnu.org; 22 Aug 2023 09:30:35 +0000 Received: from localhost ([127.0.0.1]:58586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYNic-0006PN-TF for submit@debbugs.gnu.org; Tue, 22 Aug 2023 05:30:35 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYNia-0006P8-Fs for submit@debbugs.gnu.org; Tue, 22 Aug 2023 05:30:33 -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 1qYNiS-0007Wr-62 for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2023 05:30:24 -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 1qYNiO-0008Pw-VB for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2023 05:30:23 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4DF16240101 for ; Tue, 22 Aug 2023 11:30:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692696618; bh=PK3Oda/wFPw5GWyEc+PUBvXRzmEm0++n+0AnyRAH5Wc=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=XJ7sRH4fIHqcPw64YAnFVly5smAxm3n++Zkxb8x0Kk795hx4IUIF2bFqQsJU+O94L M50k6uBJeOVOAODkv15ObMIJSPue/wuavxd4HBwNcj8OpP4LJlhY6Va0kaxbeYoPAt FWKCzqCpnH9hXV/2N4m6CH5m+ts61kH6u2bmMTo2WjQoMdI9SItYISfrCWlHfqMEEp Rggw2mhfofg7T7YzSxPJayzpTisJEsiI+ytf/EUZpjGSY8kfWYFtcII3dWZLdg6ymr ERI0DBby+tgT3GVCXRKOOYW4OLA3xTXQFbLiF/O01tNUfvrjYYdQcyRabdE+G6jFjm cc90GqJUiNIeA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RVPG14vS7z6tw7 for ; Tue, 22 Aug 2023 11:30:17 +0200 (CEST) From: Ihor Radchenko Date: Tue, 22 Aug 2023 09:30:47 +0000 Message-ID: <871qfv2zlk.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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_H5=0.001, RCVD_IN_MSPIKE_WL=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.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: -0.0 (/) Consider the following reproducer: 1. Create /tmp/bug.el with the following contents (defun my/setup () (interactive) (defun my/before-change (beg end) (warn "Before: %d %d" beg end)) (add-hook 'before-change-functions #'my/before-change nil 'local) (defun my/after-change (beg end pre) (warn "After: %d %d delta: %d" beg end (- end beg pre))) (add-hook 'after-change-functions #'my/after-change nil 'local)) 2. Create /tmp/bug.org https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html -UUU: @**- F2 UTF-8-demo.txt Top (1,0) (Text s-/ WS Wrap) | string | meaning | note = | |--------+------------------------------------------+----------------------= ------------------------------------------------| | - | input method | = | | UUU | coding system (keyboard terminal buffer) | (U utf-8-unix) = | | : | end-of-line convention | (: LF) (/ CR) (\ CRLF= ) | | @ | emacsclient | = | | ** | buffer status | (-- unmodified) (** m= odified) (%% read-only) (%* read-only_modified) | | - | default-directory | (- local) (@ remote) = | | F2 | frame name | (F2 the-2nd-frame) = | | | | = | 3. emacs -Q -l /tmp/bug.el /tmp/bug.org 4. M-x my/setup 5. Move point to | F2 | frame name | (F2 the-2nd-frame) = | | | | = | 6. Insert "UTF" 7. M-x dabbrev-expand 8. Observe the following in the *Warnings* buffer =E2=9B=94 Warning (emacs): Before: 1278 1278 =E2=9B=94 Warning (emacs): After: 1278 1279 delta: 1 =E2=9B=94 Warning (emacs): Before: 1284 1285 =E2=9B=94 Warning (emacs): After: 1284 1284 delta: -1 =E2=9B=94 Warning (emacs): Before: 1279 1279 =E2=9B=94 Warning (emacs): After: 1279 1280 delta: 1 =E2=9B=94 Warning (emacs): Before: 1284 1285 =E2=9B=94 Warning (emacs): After: 1284 1284 delta: -1 =E2=9B=94 Warning (emacs): Before: 1280 1280 =E2=9B=94 Warning (emacs): After: 1280 1281 delta: 1 =E2=9B=94 Warning (emacs): Before: 1284 1285 =E2=9B=94 Warning (emacs): After: 1284 1284 delta: -1 =E2=9B=94 Warning (emacs): Before: 1278 1281 =E2=9B=94 Warning (emacs): Before: 1278 1288 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 0 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 The last bit of the messages corresponds to dabbrev expansion of "UTF" to "utf-8-unix": =E2=9B=94 Warning (emacs): Before: 1278 1281 =E2=9B=94 Warning (emacs): Before: 1278 1288 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 0 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 Note how "After: 1278 1288 delta: 0" reports a change of "utf-8-unix" that did not alter the buffer text size. It is trigerred _before_ "After: 1278 1288 delta: 7" that corresponds to replacing "UTF" with "utf-8-unix". The order of after-change notifications thus do not correspond to the order of buffer changes. Org mode is relying upon the correct change order to update parser cache with buffer modifications. The same recipe using Emacs 27 yields the correct order <...> Warning (emacs): Before: 1278 1281 Warning (emacs): After: 1278 1288 delta: 7 Warning (emacs): Before: 1278 1288 Warning (emacs): After: 1278 1288 delta: 0 In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-08-14 built on localhost Repository revision: d483b38070120f17b1d00975081d27191d1deacc Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 System Description: Gentoo Linux --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Aug 2023 12:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169270695021286 (code B ref 65451); Tue, 22 Aug 2023 12:23:02 +0000 Received: (at 65451) by debbugs.gnu.org; 22 Aug 2023 12:22:30 +0000 Received: from localhost ([127.0.0.1]:58684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYQP0-0005XG-Bl for submit@debbugs.gnu.org; Tue, 22 Aug 2023 08:22:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYQOy-0005X1-DX for 65451@debbugs.gnu.org; Tue, 22 Aug 2023 08:22: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 1qYQOq-0001Ue-0R; Tue, 22 Aug 2023 08:22:20 -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=B/zX5hQzTxDPiXft1nUmQCxejOPyfMfN5vKUCXqDFbQ=; b=Bec3XbNDTm9cZdedZras fdjT04rXHzPJbSZgfkvlWALk1da09cfOdPfrgpIpyhBL82eWUns7Rim3VWkAzFktpT6LSIHlScigk ZyD516yE2y6s/QOq5pz/6Kmx0Kp3e2q6pCkJEzMrZ430A8OFK5hjrlu8bY+xOP9Fmy8htm05+AUX3 ApS7ORRK1S+iHK/3/Mmnomxzl4rwY8MQYng65JRuZ6qCkuagEfXSJpa9ZXp1WcQ50kSmYqX+e4wzQ rAOO0+ZBOOMsW3fB1OHiPUT6AlDfSOLotQlUpZzdRFkhNjUk7sGXTj/OyyB+L6z0smNZejUWqFJoo EEws1gw92cldFQ==; Date: Tue, 22 Aug 2023 15:22:35 +0300 Message-Id: <83a5ujtgfo.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871qfv2zlk.fsf@localhost> (message from Ihor Radchenko on Tue, 22 Aug 2023 09:30:47 +0000) References: <871qfv2zlk.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 > Date: Tue, 22 Aug 2023 09:30:47 +0000 > > The last bit of the messages corresponds to dabbrev expansion of "UTF" > to "utf-8-unix": > > ⛔ Warning (emacs): Before: 1278 1281 > ⛔ Warning (emacs): Before: 1278 1288 > ⛔ Warning (emacs): After: 1278 1288 delta: 0 > ⛔ Warning (emacs): After: 1278 1288 delta: 7 > > Note how "After: 1278 1288 delta: 0" reports a change of "utf-8-unix" > that did not alter the buffer text size. It is trigerred _before_ > "After: 1278 1288 delta: 7" that corresponds to replacing "UTF" with > "utf-8-unix". The inner Before+After is because replace-match also changes the letter-case of the replaced text (to match the letter-case of the original). > The order of after-change notifications thus do not correspond to the > order of buffer changes. Org mode is relying upon the correct change > order to update parser cache with buffer modifications. I think Org mode is relying on something it should not. This particular use case aside, Emacs is allowed to call a function that changes the buffer from a function that itself changes the buffer, and it is allowed to call that inner function _before_ it did all the changes it intended to do. In such cases you will see Before+After pairs embedded inside an outer Before+After pair, because most functions which end up calling these hooks try not to call them too often, so they generally call the before-hook once at the beginning and the after-hook once near the end. IOW, we try to report all of the changes in one go, instead of reporting them one small chunk (perhaps even one character) at a time. And that inevitably leads to situations like this one. Which is perfectly normal, from my POV, and not a bug at all. I'd hate to make our code more complex, let alone slower, just to satisfy the reliance on the perfect pairing like you do. (We've been through this in other discussions: Org uses these hooks for purposes they were not designed for. The ELisp manual even warns about such assumptions.) > The same recipe using Emacs 27 yields the correct order AFAIR, Emacs 27 had quite a few bugs in this area, which were fixed in development since then. See bug#42424, for example. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Aug 2023 12:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169270812523182 (code B ref 65451); Tue, 22 Aug 2023 12:43:01 +0000 Received: (at 65451) by debbugs.gnu.org; 22 Aug 2023 12:42:05 +0000 Received: from localhost ([127.0.0.1]:58691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYQhw-00061p-DW for submit@debbugs.gnu.org; Tue, 22 Aug 2023 08:42:04 -0400 Received: from mout01.posteo.de ([185.67.36.65]:34675) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYQhr-00061B-Ev for 65451@debbugs.gnu.org; Tue, 22 Aug 2023 08:42:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2E67D240027 for <65451@debbugs.gnu.org>; Tue, 22 Aug 2023 14:41:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692708110; bh=Nc1erb2eNyMo8/JHNqiWJmHqKqddDM8TxFGvxkcAVAI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=AnE7qM5OWWGxn3pcAj4P+szehA5u9zZicbotXUj8Cs19GErefkaD3kEjO5GbGUkEZ iZRbeN2JoHbIg2LFzbFdM4jsiEdwwSbFtttzLyP1D8tFx3sAYDPU7DMVo8eA7DYCHp ZdFqQcuJIUH8iOGsyrfs4FulBV2csxLSQfrAMpP336CSRBfkqhn65eLyddGBPDRgQ+ R+PrBjs8sFIEpkbZ7J2vqtWD4kibj1Xny5GhUiXEnSIoSaRP8VPPVMaSG7xsbgBIcG Qs7UbahjTft/EO1HX3vhnZaBH+Lg8ChKy8YblsQOlVpw2xzkK76pnwc9+R5jby4q6I DVDMN6rnxuUeg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RVTW05TFPz9rxD; Tue, 22 Aug 2023 14:41:48 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83a5ujtgfo.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> Date: Tue, 22 Aug 2023 12:42:18 +0000 Message-ID: <87jztn1c5x.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: >> The order of after-change notifications thus do not correspond to the >> order of buffer changes. Org mode is relying upon the correct change >> order to update parser cache with buffer modifications. > > I think Org mode is relying on something it should not. Then, I'd like to point back to the previous discussion where I asked to expose to Elisp information about buffer changes available to tree-sitter. https://yhetil.org/emacs-devel/83tu8jq2vl.fsf@gnu.org/ If there is no guarantee that buffer modifications are not signaled in order, on-the-fly updates of the parsed AST will become impossible for Org, even if using markers (as you suggested in the linked thread). In fact, I am not sure if tree-sitter will behave correctly if it is signaled changes in incorrect order. https://tree-sitter.github.io/tree-sitter/using-parsers#advanced-parsing says In applications like text editors, you often need to re-parse a file after its source code has changed. Tree-sitter is designed to support this use case efficiently. There are two steps required. First, you must edit the syntax tree, which adjusts the ranges of its nodes so that they stay in sync with the code. =20=20=20=20 typedef struct { uint32_t start_byte; uint32_t old_end_byte; uint32_t new_end_byte; TSPoint start_point; TSPoint old_end_point; TSPoint new_end_point; } TSInputEdit; =20=20=20=20 void ts_tree_edit(TSTree *, const TSInputEdit *); Note how the API is similar to `after-change-functions' - it expects edited region boundaries before/after the edit. If Emacs feeds the following to tree-sitter =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 0 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 , the first "edit" query will apply to wrong range in the cached AST. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Aug 2023 12:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko , Yuan Fu Cc: 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169270911025046 (code B ref 65451); Tue, 22 Aug 2023 12:59:02 +0000 Received: (at 65451) by debbugs.gnu.org; 22 Aug 2023 12:58:30 +0000 Received: from localhost ([127.0.0.1]:58731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYQxp-0006Vt-Jm for submit@debbugs.gnu.org; Tue, 22 Aug 2023 08:58:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYQxo-0006Vg-8M for 65451@debbugs.gnu.org; Tue, 22 Aug 2023 08:58: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 1qYQxg-0003Ub-4L; Tue, 22 Aug 2023 08:58:20 -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=jtKuBnTiqmm/KuzD/SfB+7r+n+fZ8C8abeAWF37rcI8=; b=TcGPdCTRdegv wjEeUkcu3inx9zYn+Y/oMjQpWQCsC8G4LrkQozpRU9SkgxNxLpzJHfgPcr4t3NxicHLjrqm1ME1Gm BjWtqFmPl2hafHvP1/vT4CWpKqetv86xtR9zapqCYdrt69eHBgrS5GxO6k4VkBb0UwJ4pAl5lPy0Y xrEWMEuETHDfq9CubFxRXsjIdMN+f8fQTR8dG/ygJYeQ7V+TlxoanHAof6u6fuJ+VZ9/TaPgZCgyQ JTUGDJCUYKizrGsDoiOIreBR3pli7cnkwDeIb+fWiycGi2ExFSrBGn2h/J4SRLM2sdXpzEtG79OoK Azgq1U4Ij4JgqBqf1JKM7Q==; Date: Tue, 22 Aug 2023 15:58:31 +0300 Message-Id: <834jkrters.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87jztn1c5x.fsf@localhost> (message from Ihor Radchenko on Tue, 22 Aug 2023 12:42:18 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.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: 65451@debbugs.gnu.org > Date: Tue, 22 Aug 2023 12:42:18 +0000 > > Eli Zaretskii writes: > > >> The order of after-change notifications thus do not correspond to the > >> order of buffer changes. Org mode is relying upon the correct change > >> order to update parser cache with buffer modifications. > > > > I think Org mode is relying on something it should not. > > Then, I'd like to point back to the previous discussion where I asked to > expose to Elisp information about buffer changes available to > tree-sitter. > https://yhetil.org/emacs-devel/83tu8jq2vl.fsf@gnu.org/ I don't want to do that, sorry. Not without a good understanding of what exactly do you need from that and in what way. If we will expose anything, it will have to be the minimum possible exposure, not the maximum, so I would like to understand this very well before I agree to any change in this direction. > If there is no guarantee that buffer modifications are not signaled in > order, on-the-fly updates of the parsed AST will become impossible for > Org, even if using markers (as you suggested in the linked thread). > > In fact, I am not sure if tree-sitter will behave correctly if it is > signaled changes in incorrect order. I will defer to Yuan, but tree-sitter doesn't use these hooks, we call its functions directly from insdel.c where needed. This makes sense for a library to which we link and whose interface code we control, but giving such access to Lisp (and Org on top of that) is out of the question. We don't even give such access to modules. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Aug 2023 13:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Yuan Fu , 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169271166029087 (code B ref 65451); Tue, 22 Aug 2023 13:41:02 +0000 Received: (at 65451) by debbugs.gnu.org; 22 Aug 2023 13:41:00 +0000 Received: from localhost ([127.0.0.1]:58771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYRcx-0007Z4-Ms for submit@debbugs.gnu.org; Tue, 22 Aug 2023 09:41:00 -0400 Received: from mout02.posteo.de ([185.67.36.66]:45021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYRcu-0007Yq-NY for 65451@debbugs.gnu.org; Tue, 22 Aug 2023 09:40:57 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id EB658240101 for <65451@debbugs.gnu.org>; Tue, 22 Aug 2023 15:40:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692711648; bh=BURI7u/uy+X+xSSYTVB9f3QwLoyLrQcrWfLwsuVQNDc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=WxInbUb1IX5UeYhI5F3YtU2lU+mYelxZmkj78DFf77n2hj+aG3i/OWGERycVsdgbO 4YJgniFrDzatzLUb5Slp7WODOdNP5WHlq8SpAghbT/FriHZ1x2rwOi5/IPlVDcM56j rHsSmz5XgWy2QkhASH1nkfCegLVvvr3ZUb4wkOC1ztdDE/r3IcpJnTqUEnKPWhvGbq wHGiyeMZgdiBJUtek5zeWh8AZMGU3/oG2a6IA6v7vq0hMXVESErvZX67U9NLJ9NzZ1 dVtW/GD5W5hXbbXqkX1/v2L8KEUdbrReXIK81bgoJK0SfunR/ao145QRM7beg2eTfq uYRJ5IJk+2qkw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RVVq30l2zz6tm4; Tue, 22 Aug 2023 15:40:46 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <834jkrters.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> Date: Tue, 22 Aug 2023 13:41:17 +0000 Message-ID: <87v8d7i48y.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: >> Then, I'd like to point back to the previous discussion where I asked to >> expose to Elisp information about buffer changes available to >> tree-sitter. >> https://yhetil.org/emacs-devel/83tu8jq2vl.fsf@gnu.org/ > > I don't want to do that, sorry. Not without a good understanding of > what exactly do you need from that and in what way. If we will expose > anything, it will have to be the minimum possible exposure, not the > maximum, so I would like to understand this very well before I agree > to any change in this direction. Org wants to do the same thing tree-sitter does - keep parsed AST in sync with buffer modifications without having to re-parse the whole buffer. So, we basically need the same information tree-sitter needs - the sequence of buffer text changes, in their order. Note that the markers discussed in the thread I linked are not sufficient. When editing near AST node boundaries, even if the boundaries are represented by markers, we have to re-parse the AST around to account for the possible structural changes. So, information about buffer edits is still required. >> In fact, I am not sure if tree-sitter will behave correctly if it is >> signaled changes in incorrect order. > > I will defer to Yuan, but tree-sitter doesn't use these hooks, we call > its functions directly from insdel.c where needed. This makes sense > for a library to which we link and whose interface code we control, > but giving such access to Lisp (and Org on top of that) is out of the > question. We don't even give such access to modules. I hope that we can solve this issue one way or another. This currently breaks the very core functionality of Org. Every part of Org relies on it to obtain reasonable performance. Prior to using cache, we had orders of magnitude slowdowns. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Aug 2023 16:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169272014213987 (code B ref 65451); Tue, 22 Aug 2023 16:03:02 +0000 Received: (at 65451) by debbugs.gnu.org; 22 Aug 2023 16:02:22 +0000 Received: from localhost ([127.0.0.1]:60238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYTpm-0003dX-Cc for submit@debbugs.gnu.org; Tue, 22 Aug 2023 12:02:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYTpj-0003dK-Pj for 65451@debbugs.gnu.org; Tue, 22 Aug 2023 12:02: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 1qYTpb-0005he-KP; Tue, 22 Aug 2023 12:02:11 -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=2K/2TiaMWvdYUyvbioH9vx7EnJTgkxDBOaZR8PWhHLw=; b=Bd4yINZ5t9tf /DUO7L2Zoz9s/t0JwDMtWHQ3qmZE7K21JaxtJfc2NvJRRQnP/HsraRXadokrQJm2GVH7uzaJZ4A9K Z8gIc3tXueJQLTStVDJTsZVcbH1qKZ50YwFjFwyaUHDDtD3dnwuvBnAR2kCo6ZFlkN/eKWYn5vZWR 3O4xf/cauHMobgMfzjuJDJxHN2qaVFuZto17irKZJ5Ge8yCOqkqL0CKUomldZeViqm+T7VAXUX/m4 C1vasxZyAwal10XhWaGyn1J4YLHsZOM/mEEzbjzSi4cGV/NJm9gIbVuJKUHvC4u6llxacy4CEnxQT 7XVPk7LFgaH22of28M+jyg==; Date: Tue, 22 Aug 2023 19:02:31 +0300 Message-Id: <83ttsrrroo.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87v8d7i48y.fsf@localhost> (message from Ihor Radchenko on Tue, 22 Aug 2023 13:41:17 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.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: Yuan Fu , 65451@debbugs.gnu.org > Date: Tue, 22 Aug 2023 13:41:17 +0000 > > Eli Zaretskii writes: > > >> Then, I'd like to point back to the previous discussion where I asked to > >> expose to Elisp information about buffer changes available to > >> tree-sitter. > >> https://yhetil.org/emacs-devel/83tu8jq2vl.fsf@gnu.org/ > > > > I don't want to do that, sorry. Not without a good understanding of > > what exactly do you need from that and in what way. If we will expose > > anything, it will have to be the minimum possible exposure, not the > > maximum, so I would like to understand this very well before I agree > > to any change in this direction. > > Org wants to do the same thing tree-sitter does - keep parsed AST in > sync with buffer modifications without having to re-parse the whole > buffer. So, we basically need the same information tree-sitter needs - > the sequence of buffer text changes, in their order. We don't expose the data you want to tree-sitter in Lisp. What is exposed to Lisp are the parser and parse-tree objects that we build (in C) based on tree-sitter parsing results. When the buffer is modified, the information about the modifications is used internally by Emacs, in C code, to find and update the relevant parsers, and for that we call the tree-sitter functions involved in this process. See the function treesit_record_change which does that, and which is called from C when buffer text changes in a way relevant to treesit.el functionalities. (Note that some changes of buffer text are not visible even to tree-sitter, because we decided they are not relevant, for now.) > Note that the markers discussed in the thread I linked are not > sufficient. When editing near AST node boundaries, even if the > boundaries are represented by markers, we have to re-parse the AST > around to account for the possible structural changes. So, information > about buffer edits is still required. If tracking markers is not enough, then I wonder how the information from the lower levels, which is basically the same but noisier, will be able to help you. > >> In fact, I am not sure if tree-sitter will behave correctly if it is > >> signaled changes in incorrect order. > > > > I will defer to Yuan, but tree-sitter doesn't use these hooks, we call > > its functions directly from insdel.c where needed. This makes sense > > for a library to which we link and whose interface code we control, > > but giving such access to Lisp (and Org on top of that) is out of the > > question. We don't even give such access to modules. > > I hope that we can solve this issue one way or another. This currently > breaks the very core functionality of Org. Every part of Org relies on > it to obtain reasonable performance. Prior to using cache, we had orders > of magnitude slowdowns. If you can arrange your design such that Lisp sees only AST-specific objects affected by the modifications in buffer text, then I believe we will have a good chance of finding a satisfactory solution. If that requires to have some of your code in C (preferably, generalized to some extent), then so be it. You see, I think the buffer-change hooks we have are already too much: Lisp programs abuse them all the time (you can see a good example in the bug which I mentioned up-thread, and which led to the change you are now complaining about). Doing more of that is not very wise, to say the least. Moreover, I think the solution you think you want you actually _don't_ want, because it will overwhelm you with changes that are not relevant to your purposes. You can see a clear evidence to that in the fact that treesit_record_change is called only in several strategical places, not everywhere where we change buffer text, and not at the lowest level of such changes. There's a reason to that. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 08:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.16927807356516 (code B ref 65451); Wed, 23 Aug 2023 08:53:01 +0000 Received: (at 65451) by debbugs.gnu.org; 23 Aug 2023 08:52:15 +0000 Received: from localhost ([127.0.0.1]:32791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYjb4-0001h2-Nx for submit@debbugs.gnu.org; Wed, 23 Aug 2023 04:52:15 -0400 Received: from mout01.posteo.de ([185.67.36.65]:39245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYjb1-0001gk-Ow for 65451@debbugs.gnu.org; Wed, 23 Aug 2023 04:52:13 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 75AC124002A for <65451@debbugs.gnu.org>; Wed, 23 Aug 2023 10:52:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692780722; bh=SvN7BCt4RuFOItFbl44HxBrmYVsFJrcEP47qHxr4k94=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=BVviGfpdmNbUYKHSImIZoElf8kmmzi9iaVprI3dCUC12IGFvHfxIqIxwTT2VM2G7r WwQ00SNbLlylg2IwOy1gd23konJ2B1S/h25gJsbAipvSVz0Qxythveap0PlzKZ09zO aMo2TDGSYz5R2cndOLN92QLOgbtGmNQ9x69lc2gRLpcnQ9l+OJI01ssAfj1R4TMVx0 NuB3DG++r/T38oPch/fTZ0XmNlxyq+p7iGJl6vlOYQmPsJyzJcNagRyOxW9KY347/F 0ZxYson1Im4No51rBg9nsccsTtInQDU5qao+OF3eJ1Dz3ZrBwVxyLoPe63oLYi1sIR AVXWumvs/SxAA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RW0MN2KxSz6tsj; Wed, 23 Aug 2023 10:52:00 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83ttsrrroo.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> Date: Wed, 23 Aug 2023 08:52:30 +0000 Message-ID: <874jkq87jl.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: >> Org wants to do the same thing tree-sitter does - keep parsed AST in >> sync with buffer modifications without having to re-parse the whole >> buffer. So, we basically need the same information tree-sitter needs - >> the sequence of buffer text changes, in their order. > > We don't expose the data you want to tree-sitter in Lisp. What is > exposed to Lisp are the parser and parse-tree objects that we build > (in C) based on tree-sitter parsing results. I understand. The difference is that Org mode tries to implement the tree sitter algorithm (not exactly, but similar) in Elisp. > ... When the buffer is > modified, the information about the modifications is used internally > by Emacs, in C code, to find and update the relevant parsers, and for > that we call the tree-sitter functions involved in this process. See > the function treesit_record_change which does that, and which is > called from C when buffer text changes in a way relevant to treesit.el > functionalities. (Note that some changes of buffer text are not > visible even to tree-sitter, because we decided they are not relevant, > for now.) I understand. Org also does not need every single change. The changes that, when combined, do not affect the buffer text are not important to Org as well. In fact, Org even merge subsequent edits in the same, or intersecting region of text. For example, if no queries to Org AST are done between edits, Foo bar baz -> Foo bar|new text| baz -> Foo bar|new text| and more| baz is simply treated as a single edit Foo bar baz -> Foo bar|new text| and more| baz > If tracking markers is not enough, then I wonder how the information > from the lower levels, which is basically the same but noisier, will > be able to help you. We do not really need information from lower levels. At every moment of time, Org parser maintains a linkage between buffer text and its parsed AST. After a buffer edit, we need to know how to update the AST corresponding to the last known buffer text state to the new (current) text state. To update the old AST we need to know which regions in the old AST (and old buffer text) were edited and their change in length. Then, we (1) remove elements in AST that are structurally affected by the edit; (2) shift elements after the edit that are not structurally affected but whose boundaries must be adjusted to accommodate for the buffer length being changed; (3) re-parse buffer text (after the edit) and fill the gap in the AST. For step (1), it is critical to have information about changed regions in the same order the edits happen. And, in theory, we might utilize before-change-functions to obtain this information (assuming that before-change-functions are always called in the same order the edits happen). But, unfortunately, before-change-functions are too noisy for this purpose because, for example, simply altering text properties also triggers before-change-functions, while no actual change in buffer text occurs in such scenario and re-parsing AST is unnecessary. So, we instead have to use after-change-functions and work out the original changed region boundaties using beg_changed end_changed pre-change_lentgh -> beg_before_change = beg_changed; end_before_change = end_changed - pre-change_length This calculation of the original changed region becomes incorrect when the order of after-change-functions is not the same as the editing order - this bug report. Step (2) is technically not necessary if we use markers, but we cannot do it yet for performance reasons. And without markers, we again need to know the change in length of th edited region: end_changed - beg_changed - pre-change_lentgh. This calculation is also incorrect when after-change-function is not the same as the editing order. All the above information does not have to be granular. We are good as long as nothing queries the AST between the edits. For example, internal details of edit sequence done by replace-match are not important because Org AST will not be queried from Emacs C internals. >> I hope that we can solve this issue one way or another. This currently >> breaks the very core functionality of Org. Every part of Org relies on >> it to obtain reasonable performance. Prior to using cache, we had orders >> of magnitude slowdowns. > > If you can arrange your design such that Lisp sees only AST-specific > objects affected by the modifications in buffer text, then I believe > we will have a good chance of finding a satisfactory solution. If > that requires to have some of your code in C (preferably, generalized > to some extent), then so be it. The problem is that whether an edit requires re-parsing an AST object or not depends on the object type. For example, :DRAWER: Text inside drawer. :END: Corresponds to the following simplified AST: (drawer (:name "DRAWER") (paragraph)) Then, changing it to :DR: ... :END: will require updating 'drawer' AST node: (drawer (:name "DR") (paragraph)) while :DRAWER: Text inside drawer. :ND: will invalidate drawer and turn the whole thing into (paragraph) and :DRAWER: Text inside drawer. :END: will not affect the drawer, just inner paragraph. Further, :DRAWER: Text inside * Heading drawer. :END: will split the whole thing into (paragraph) (heading (paragraph)) Basically, I do not see an obvious way to abstract AST away into C without implementing Org parser in C as well. With an exception of exposing treesit_record_change to Elisp, so that we can get information about region before and after the edit when updating the AST - that's what I had in mind in https://yhetil.org/emacs-devel/83tu8jq2vl.fsf@gnu.org/ We would need something like after-change-text-functions that will only trigger after actual text edits and provide information about region boundaries before and after the edit. > Moreover, I think the solution you think you want you actually _don't_ > want, because it will overwhelm you with changes that are not relevant > to your purposes. You can see a clear evidence to that in the fact > that treesit_record_change is called only in several strategical > places, not everywhere where we change buffer text, and not at the > lowest level of such changes. There's a reason to that. Indeed. As I tried to explain, the problem for me is not the granularity of changes, but their ordering. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Aug 2023 17:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169281348712407 (code B ref 65451); Wed, 23 Aug 2023 17:59:01 +0000 Received: (at 65451) by debbugs.gnu.org; 23 Aug 2023 17:58:07 +0000 Received: from localhost ([127.0.0.1]:35127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYs7L-0003E3-Bw for submit@debbugs.gnu.org; Wed, 23 Aug 2023 13:58:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYs7F-0003DS-S6 for 65451@debbugs.gnu.org; Wed, 23 Aug 2023 13:58:05 -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 1qYs76-0002UQ-NC; Wed, 23 Aug 2023 13:57:52 -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=pyOmhdRnJqnDB0FrYgeN7nFgDGTd4/jGzZyms90+1y0=; b=WyZnMqrhqWsY TZYiCzPKnpmR0qOYZIpkXE3gR0EEy3ftymgCSzZIbO3nRLzoDosro5iGkRN1QI1Q1G6OSfxFLkwpR hLiKjb8L1RPd/u1tyQMxI/iiOY2x4OfVMHiqh5+tIZHh2HjwhuUPftDG3tcKTh/x8JZtC+IQ7kHeX KvKnkw225pLbX3XEeCeQbk1GgQSTWSwYmLz3O8NJko+x91ZEds5s6aAlkqempi/JuBFQVkBarbwOP LieZBfYpLCefjstcacLcE82GpdqFGTLddgwxyHLa3pfEwXb7SqVtv2rbFJDwFVeYzNMhk+L6kq3Ug 7nI9wKdiD/20QSOFZ23f1w==; Date: Wed, 23 Aug 2023 20:58:14 +0300 Message-Id: <83y1i1r689.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <874jkq87jl.fsf@localhost> (message from Ihor Radchenko on Wed, 23 Aug 2023 08:52:30 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.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: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Wed, 23 Aug 2023 08:52:30 +0000 > > To update the old AST we need to know which regions in the old AST (and > old buffer text) were edited and their change in length. Then, we (1) > remove elements in AST that are structurally affected by the edit; > (2) shift elements after the edit that are not structurally affected but > whose boundaries must be adjusted to accommodate for the buffer length > being changed; (3) re-parse buffer text (after the edit) and fill the > gap in the AST. > > For step (1), it is critical to have information about changed regions > in the same order the edits happen. And, in theory, we might utilize > before-change-functions to obtain this information (assuming that > before-change-functions are always called in the same order the edits > happen). But, unfortunately, before-change-functions are too noisy for > this purpose because, for example, simply altering text properties also > triggers before-change-functions, while no actual change in buffer text > occurs in such scenario and re-parsing AST is unnecessary. So, we > instead have to use after-change-functions and work out the original > changed region boundaties using > beg_changed end_changed pre-change_lentgh -> > beg_before_change = beg_changed; > end_before_change = end_changed - pre-change_length > This calculation of the original changed region becomes incorrect when > the order of after-change-functions is not the same as the editing order > - this bug report. If these measures still don't help you enough, perhaps the conclusion is that it isn't feasible to implement text parsers in Lisp, at least as long as you want all those micro-optimizations of knowing exactly which parts of the buffer text were modified (as opposed to only know how many characters at the beginning and at the end of the buffer remain unchanged, and reparse the rest). Maybe it must be done in C, if we want Emacs to remain a relatively safe environment. > Indeed. As I tried to explain, the problem for me is not the granularity > of changes, but their ordering. I still don't understand why the ordering matters, but I do know that you cannot rely on it, and I hope I explained why. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 07:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.16928631507886 (code B ref 65451); Thu, 24 Aug 2023 07:46:02 +0000 Received: (at 65451) by debbugs.gnu.org; 24 Aug 2023 07:45:50 +0000 Received: from localhost ([127.0.0.1]:36056 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ52M-000238-ES for submit@debbugs.gnu.org; Thu, 24 Aug 2023 03:45:50 -0400 Received: from mout01.posteo.de ([185.67.36.65]:49247) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ52J-00022t-MM for 65451@debbugs.gnu.org; Thu, 24 Aug 2023 03:45:49 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id DDEFE240027 for <65451@debbugs.gnu.org>; Thu, 24 Aug 2023 09:45:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692863137; bh=v6ysih1UFiGqQ33TgWNHhsES9Xvp9DqaQXWtaArG2yU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=k4aJn+W6fs4KJuOnJ05YAYo2EdkAtylyBKbiKDzb79b48jXi2twoRKC7e/63Ae2Ok nQz6RdF4QO83x1b/APqvvcD2dj1D15/B0yXkPXYUei7pAJkcbtVhJOc6WHujUjl0LY hl1nJP6St3FvnOLx396fI6UsUkR+jBXzVIE5lJXyQfO5ukTLCuRLH9rPseVSV2YV8C apLEpKUolAcADh+Vljc1zOAWxPoWyd1m54BImNzSUrrL/TOT2kZqFqLtuLalWWVkqn KU8Xhmg3EwTAEKcJR78fR9CsL8eJkb2zezuYZxwYWBl6h96Os10IbPuElCNglf9kzl PeIY9rDG5WRyA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RWZrJ7298z9rxF; Thu, 24 Aug 2023 09:45:36 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83y1i1r689.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> Date: Thu, 24 Aug 2023 07:46:06 +0000 Message-ID: <87fs487uip.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: > If these measures still don't help you enough, perhaps the conclusion > is that it isn't feasible to implement text parsers in Lisp, at least > as long as you want all those micro-optimizations of knowing exactly > which parts of the buffer text were modified (as opposed to only know > how many characters at the beginning and at the end of the buffer > remain unchanged, and reparse the rest). Maybe it must be done in C, > if we want Emacs to remain a relatively safe environment. Do I understand correctly that `treesit_record_change' is called __less frequently__ compared to before-change-functions and after-change-functions? If yes, I do not see how exposing it to Elisp will make things any worse than already available `before-change-functions'/`after-change-functions'. Elisp code that does not care about text property changes will not be forced to use `before/after-change-functions' (because no other option) and could be called less frequently. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 08:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169286448510254 (code B ref 65451); Thu, 24 Aug 2023 08:09:02 +0000 Received: (at 65451) by debbugs.gnu.org; 24 Aug 2023 08:08:05 +0000 Received: from localhost ([127.0.0.1]:36067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ5Ns-0002fK-Sb for submit@debbugs.gnu.org; Thu, 24 Aug 2023 04:08:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ5Nq-0002el-Fv for 65451@debbugs.gnu.org; Thu, 24 Aug 2023 04:08:03 -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 1qZ5Ng-0002rD-UN; Thu, 24 Aug 2023 04:07:52 -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=lBJw0q221Airh9YICpczvSgbTpqsbdGw/jenVhkNDdQ=; b=X/cjkLZ5lZ6Q VyQ6m4n8s1S5brgs5JXCFunFiYKshaa8Dl5eKXplQNJGhjkPCDHZrWLlt32PS1pNruH9R/PvEO6Pn Gl/wtGtJSGnuExH9FjhnerMhGsQMpVOiPv8XOKcK+pv0o9u4kmcyYopsrG4eGIapejgSyhUjf2w1g k2eISv8R77S7AEngZx5TTEp4tWKiEtqIHm7iRWVlnpAxKjMXBvDbt5lJMCu3i8YFROgyMzCyjjEq7 YmO1YlPRC9wFy8T4CyVQyLeRNtiGvpQAvtShSudokDo9arHmAZjQEB92ATa1DOGEQTOIRbvA1pqzi MMqev//oiTX+28sgEfqP1A==; Date: Thu, 24 Aug 2023 11:08:16 +0300 Message-Id: <83zg2gq2vj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87fs487uip.fsf@localhost> (message from Ihor Radchenko on Thu, 24 Aug 2023 07:46:06 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.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: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Thu, 24 Aug 2023 07:46:06 +0000 > > Eli Zaretskii writes: > > > If these measures still don't help you enough, perhaps the conclusion > > is that it isn't feasible to implement text parsers in Lisp, at least > > as long as you want all those micro-optimizations of knowing exactly > > which parts of the buffer text were modified (as opposed to only know > > how many characters at the beginning and at the end of the buffer > > remain unchanged, and reparse the rest). Maybe it must be done in C, > > if we want Emacs to remain a relatively safe environment. > > Do I understand correctly that `treesit_record_change' is called > __less frequently__ compared to before-change-functions and > after-change-functions? No, treesit_record_change is called at a lower level than buffer-change hooks are, and therefore in some cases the hooks will not be called, but treesit_record_change will be. The frequency might be lower, but only because treesit_record_change is called once per change; there's no separate "before" and "after" calls. In any case, the correspondence is not 1:1, because they are called on different levels. > If yes, I do not see how exposing it to Elisp will make things any > worse than already available > `before-change-functions'/`after-change-functions'. Exposing buffer text changes to Lisp is inherently dangerous, because Lisp code can do anything and everything in these hooks, and many packages already do. The fact that we allow this via those two hooks is unfortunate as it is, but adding more opportunities for Lisp to do potentially dangerous stuff, and doing that on a lower level, where the buffer object is sometimes in a state that is not 100% consistent, is unwise, to say the least. It will make Emacs much less stable. No, thanks. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 11:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169287626131761 (code B ref 65451); Thu, 24 Aug 2023 11:25:02 +0000 Received: (at 65451) by debbugs.gnu.org; 24 Aug 2023 11:24:21 +0000 Received: from localhost ([127.0.0.1]:36269 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ8Rp-0008GD-FL for submit@debbugs.gnu.org; Thu, 24 Aug 2023 07:24:21 -0400 Received: from mout02.posteo.de ([185.67.36.66]:40865) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ8Rn-0008Fx-1w for 65451@debbugs.gnu.org; Thu, 24 Aug 2023 07:24:19 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1AE3E240103 for <65451@debbugs.gnu.org>; Thu, 24 Aug 2023 13:24:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692876249; bh=m5Nea0jKwXcoXWX6r4XyFZ4lWiJHTB2vrUXEX7V8k7E=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=elAMqPvtUXG48Sg2swVdzqO4GGi/hLlkIPp3tf8ahG2gOqabWHYug7rDlR8+f/j/M QetSwSU1kzMClSHPRmFHcFnrOzdpLiDmuVZ+IhdRZrGqWfSYT+cvxMmv88SyXMMdk6 ZOxmcSFtwc+3j+WmnKdCOAuMUpiXGqod0h/6RVrNvVxPwoUSUjwSjHPFBviPChA5qW ehzq+lHmlxCBbLvl3esz7nMVqZdTWVVckhnOmq6tNXYjDzZ8Q2AVIQLgKuM33sW4yI O/bqqeiCB7hHVhdeg7A5j0BZ+i6mON/F19ugS4focr4FvN3kqECnukewHaCfOnpv8l Esf4UXlbbpy9w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RWghS2Fz5z6tvw; Thu, 24 Aug 2023 13:24:08 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83zg2gq2vj.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> Date: Thu, 24 Aug 2023 11:24:37 +0000 Message-ID: <871qfsel8q.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: > Exposing buffer text changes to Lisp is inherently dangerous, because > Lisp code can do anything and everything in these hooks, and many > packages already do. The fact that we allow this via those two hooks > is unfortunate as it is, but adding more opportunities for Lisp to do > potentially dangerous stuff, and doing that on a lower level, where > the buffer object is sometimes in a state that is not 100% consistent, > is unwise, to say the least. It will make Emacs much less stable. > No, thanks. I can see the danger running lisp code while buffer state is transient. Would it be acceptable to accumulate treesit_record_change transactions into a queue, combine them later, and run the Elisp hook only when it is safe (around the same place `after-change-functions' is called, but only when actual edit is made to the buffer text)? That way, we can have a hook that will run strictly less frequently compared to `after-change-functions'. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 12:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169287888313940 (code B ref 65451); Thu, 24 Aug 2023 12:09:02 +0000 Received: (at 65451) by debbugs.gnu.org; 24 Aug 2023 12:08:03 +0000 Received: from localhost ([127.0.0.1]:36302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ987-0003ck-EJ for submit@debbugs.gnu.org; Thu, 24 Aug 2023 08:08:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41772) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ984-0003cH-SA for 65451@debbugs.gnu.org; Thu, 24 Aug 2023 08:08: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 1qZ97v-0004d2-2z; Thu, 24 Aug 2023 08:07:51 -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=eTrDmLGP10kjtvPpCPGJSJXa1NsCrU4EkRbZUUtYlzY=; b=AgTzV5/V7YQa 39qzglV6+7AUcC0TcjgM3y0HE8kMIUIZjXcL036MhyTibro2ZbGE8iiaFhZ6lB36xpEuYfYLQGOJQ 4PzUZ1qKbqU8gIaoDaWQmnPWXsQzXNhx4GDIByL8uFkrDZ+rzduxVgBe+PSaR3Luf/9Ns0mvbeiHD F55qpdm/zipXx2HZhmYuWyhPgRk3mw7Y7O0RhveiqWyZZ0rGin6pwRz8EZF8x/INpoDsqsblTKh5G btPswb5EZlBJztbswrmCO6Nd2yZzjB6YTEQbllQbYhrYiFBBNi3aAOuRaTZA5ASW+u7wwe2ayUUcq o2pxbLuHG8tZ8e27bTirxg==; Date: Thu, 24 Aug 2023 15:08:15 +0300 Message-Id: <83r0nsprrk.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <871qfsel8q.fsf@localhost> (message from Ihor Radchenko on Thu, 24 Aug 2023 11:24:37 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.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: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Thu, 24 Aug 2023 11:24:37 +0000 > > Eli Zaretskii writes: > > > Exposing buffer text changes to Lisp is inherently dangerous, because > > Lisp code can do anything and everything in these hooks, and many > > packages already do. The fact that we allow this via those two hooks > > is unfortunate as it is, but adding more opportunities for Lisp to do > > potentially dangerous stuff, and doing that on a lower level, where > > the buffer object is sometimes in a state that is not 100% consistent, > > is unwise, to say the least. It will make Emacs much less stable. > > No, thanks. > > I can see the danger running lisp code while buffer state is transient. > > Would it be acceptable to accumulate treesit_record_change transactions > into a queue, combine them later, and run the Elisp hook only when it is > safe (around the same place `after-change-functions' is called, but only > when actual edit is made to the buffer text)? > > That way, we can have a hook that will run strictly less frequently > compared to `after-change-functions'. When exactly do you need this to run? At the same time as after-change-functions doesn't sound like a good idea to me, but I think you don't need to run it there. What about running just before redisplay kicks in? Or how about explaining how is the (updated) AST used, i.e. who are the clients of the AST updates, and what do they do when the AST changes? From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 13:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169288360722046 (code B ref 65451); Thu, 24 Aug 2023 13:27:01 +0000 Received: (at 65451) by debbugs.gnu.org; 24 Aug 2023 13:26:47 +0000 Received: from localhost ([127.0.0.1]:36375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZAMI-0005jW-KF for submit@debbugs.gnu.org; Thu, 24 Aug 2023 09:26:47 -0400 Received: from mout02.posteo.de ([185.67.36.66]:57239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZAMG-0005jJ-7D for 65451@debbugs.gnu.org; Thu, 24 Aug 2023 09:26:44 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 2B86D240103 for <65451@debbugs.gnu.org>; Thu, 24 Aug 2023 15:26:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692883594; bh=Exv7Ico7UfYg0MVfQqNHnPY3JtgyWbPTvcE+9KBOmZc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=G1IgEE+hPZIJ8kTpFcrtn8hCQE2sI3FKB5f9zxojKcx3mHgT0JbWgIp7Yq/zJ22Nn CSxgibCKSBsWo5isIpVq5+oGPtIVReCRin3rb+yidVA2SpQ3LSo1ffFuCd0S4lXogr B0wecKp7AJrwuqjU+2I4VZjwG9T9AwnoWiK6JAT8Qh/29e2N8pU7S/TMPho2i5eRUT khCIA9yR8hxU90vkuXU0cBsk9OMEHCiWyatMUYAllXt66xpbhRcIBRl/88iHRK+NV2 Z4Jt+b5pSNgDqA5G72ZIsfOyNsLAYUj9IyjTkrL+U2dvWn+QDZKO+9hp3en79QtbRC FHMBa2vWibl+w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RWkPj2SQ0z6tm4; Thu, 24 Aug 2023 15:26:33 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83r0nsprrk.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> Date: Thu, 24 Aug 2023 13:27:02 +0000 Message-ID: <87cyzck1uh.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: >> Would it be acceptable to accumulate treesit_record_change transactions >> into a queue, combine them later, and run the Elisp hook only when it is >> safe (around the same place `after-change-functions' is called, but only >> when actual edit is made to the buffer text)? >> >> That way, we can have a hook that will run strictly less frequently >> compared to `after-change-functions'. > > When exactly do you need this to run? At the same time as > after-change-functions doesn't sound like a good idea to me, but I > think you don't need to run it there. What about running just before > redisplay kicks in? Usually, we need to update AST when some other Elisp code needs Org element API. And we update AST on idle timer to speed things up. What if we use no hooks at all? Instead, the edit transactions are accumulated in a list that can be examined and processed by Elisp code as needed. Elements of the list will be like [:buffer-chars-modified-tick :region-beginning :region-end-before-edit :region-end-after-edit] -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Aug 2023 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.1692888795456 (code B ref 65451); Thu, 24 Aug 2023 14:54:02 +0000 Received: (at 65451) by debbugs.gnu.org; 24 Aug 2023 14:53:15 +0000 Received: from localhost ([127.0.0.1]:38390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZBhz-00007G-EI for submit@debbugs.gnu.org; Thu, 24 Aug 2023 10:53:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZBhx-00006n-GL for 65451@debbugs.gnu.org; Thu, 24 Aug 2023 10:53:14 -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 1qZBhn-0004ga-49; Thu, 24 Aug 2023 10:53:04 -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=kDbbLOsT5WDIh1UDWKoEYiZCctnViiMuOfnYIF7Umdg=; b=W+S6oma5uUe8 og9qRAkhkJ1EkRifV6eLJQnTS/331Crty0OcLqgYKPQBOa/7zmPVZY2qu+H7fYnvEy7p5x2QWPdWK PD1jUUbdMO/UtP3tmsu4l2XfUFEsX4lFK8qxD2VdrOLJ9H+/IlwCh+SrKx4xR4FaL/p0Jt2IOG2WZ +XJNcXR1aylOt+RxxRE2mULXIvzWsOaCGluDzOiYhQmQjaN8HOn9yKYMf5QWhyyy5gTX+OtsdiqI1 gTJgB2ABft/s5BJNZRWJeLRSwXQAqtDLLCq1kmWtSx1L68sZeNewkSgrEmAasyhkPKLAdkUQDrBAo lnYyJpaV5Rrj7zc8boByUA==; Date: Thu, 24 Aug 2023 17:53:26 +0300 Message-Id: <83il94pk49.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87cyzck1uh.fsf@localhost> (message from Ihor Radchenko on Thu, 24 Aug 2023 13:27:02 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.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: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Thu, 24 Aug 2023 13:27:02 +0000 > > Eli Zaretskii writes: > > > When exactly do you need this to run? At the same time as > > after-change-functions doesn't sound like a good idea to me, but I > > think you don't need to run it there. What about running just before > > redisplay kicks in? > > Usually, we need to update AST when some other Elisp code needs Org > element API. And we update AST on idle timer to speed things up. > > What if we use no hooks at all? Instead, the edit transactions are > accumulated in a list that can be examined and processed by Elisp code > as needed. If you need that from timers, then yes, all you need is access from the timer function to a data structure that holds the accumulated transactions. Timers run approximately at the same time and under the same conditions as redisplay, so this mechanism will indeed ensure this data is accessed when Emacs is in a consistent state, and it is safe to access and use this data. > Elements of the list will be like > [:buffer-chars-modified-tick :region-beginning :region-end-before-edit :region-end-after-edit] If you really need buffer-chars-modified-tick, you will have to verify that it is updated before calling the function which updates the "transactions list". From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Aug 2023 06:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: yantar92@posteo.net Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169294546213747 (code B ref 65451); Fri, 25 Aug 2023 06:38:02 +0000 Received: (at 65451) by debbugs.gnu.org; 25 Aug 2023 06:37:42 +0000 Received: from localhost ([127.0.0.1]:39057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZQRy-0003Zf-0N for submit@debbugs.gnu.org; Fri, 25 Aug 2023 02:37:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZQRw-0003ZT-NY for 65451@debbugs.gnu.org; Fri, 25 Aug 2023 02:37: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 1qZQRl-0003w9-In; Fri, 25 Aug 2023 02:37:30 -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=fazkZSeEk47Kefhampl1NFO/Tb9Ba3soVbflv7zveyE=; b=dn2CzPUsUCu5 zmEZvwT5iG1B4QaNnXuy4uIbKUB5QQ7MU2wNF3W+JgQCl7w1I6KxCNcQRd8G6aHQKONTk+OnZPepH sO5aATeGXopGh0R23riTR9RGQSD2of1NsAWElFKtdb9fU+WjXvu+inHgfW+C5FZ4TgCWEod6VMOvQ 6zhipCvbAl4eqnM19EqeG1ap85ow5kH8eoryya1EwkEXYZ2hYf6TPBSjlL+MQlpgq8Rfic7XjucF/ xwzetkqSbyT5y5+6KTQA+eld7WUPCr+Y0Dw8R7n8snCgYqcg/hRmsqVk19cPdH1UKiYzQk4vjBU9/ UdyOSWhUFRQW96r4HeT5SA==; Date: Fri, 25 Aug 2023 09:37:49 +0300 Message-Id: <83pm3bocea.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83il94pk49.fsf@gnu.org> (message from Eli Zaretskii on Thu, 24 Aug 2023 17:53:26 +0300) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.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: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Thu, 24 Aug 2023 17:53:26 +0300 > From: Eli Zaretskii > > If you need that from timers, then yes, all you need is access from > the timer function to a data structure that holds the accumulated > transactions. Timers run approximately at the same time and under the > same conditions as redisplay, so this mechanism will indeed ensure > this data is accessed when Emacs is in a consistent state, and it is > safe to access and use this data. > > > Elements of the list will be like > > [:buffer-chars-modified-tick :region-beginning :region-end-before-edit :region-end-after-edit] > > If you really need buffer-chars-modified-tick, you will have to verify > that it is updated before calling the function which updates the > "transactions list". Thinking about this some more, we will need to consider whether this list of accumulated transactions is ever compacted by deleting old transactions, or we let it grow indefinitely. If the former, we should consider the case where more than one feature wants to track buffer edits (so it is impossible to remove entries once they have been processed by a single consumer). From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Aug 2023 08:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.16929509651861 (code B ref 65451); Fri, 25 Aug 2023 08:10:01 +0000 Received: (at 65451) by debbugs.gnu.org; 25 Aug 2023 08:09:25 +0000 Received: from localhost ([127.0.0.1]:39200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZRsi-0000Tx-Tu for submit@debbugs.gnu.org; Fri, 25 Aug 2023 04:09:25 -0400 Received: from mout02.posteo.de ([185.67.36.66]:52427) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZRsh-0000Tj-2W for 65451@debbugs.gnu.org; Fri, 25 Aug 2023 04:09:24 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8E3C0240101 for <65451@debbugs.gnu.org>; Fri, 25 Aug 2023 10:09:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692950952; bh=pNRm68o4XmNGfw4B8uRPwkmesh7AvHuSALKv30VyUR8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=D/Zy2zWnfSyBMnCOTQCeqfuyASp7deZjO+YQETDfValkUNCynIJHX6PgXEVYjvXfF mhRYHBvQxeSJKOfUAsXZl27SQoG5HVQLKtY6AYjucjeNMgnnAA1zmuhnpees9MjhP1 q/gDVTuzGjGiC0LCePOr/jiToXM+8F4nyJqpgfTujfflaxy3eOsbmJ5iLuBUg21LFr Ikm5wh1/ObYmW0rukAbgBODho6rAZgvpidw7zEK9xgnv6+Bc3KE5g2bg++TM7s9cun YkLpDwb1uuj9TxBIFlEHNzv7ZY78cVe+zXKjBFG3FwEC84OxxVkqgc/uode3rfRIMC mXarodkDxsF2g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RXCK34BFnz9rxX; Fri, 25 Aug 2023 10:09:11 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83il94pk49.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.fsf@gnu.org> Date: Fri, 25 Aug 2023 08:09:41 +0000 Message-ID: <875y53ilve.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: >> Elements of the list will be like >> [:buffer-chars-modified-tick :region-beginning :region-end-before-edit :region-end-after-edit] > > If you really need buffer-chars-modified-tick, you will have to verify > that it is updated before calling the function which updates the > "transactions list". Do you mean that buffer-chars-modified-tick may not be yet updated at the time treesit_record_change is called? Then, treesit_record_change only uses byte positions. Will it be possible to record buffer point positions, or may it be problematic? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Aug 2023 09:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.16929545357974 (code B ref 65451); Fri, 25 Aug 2023 09:09:01 +0000 Received: (at 65451) by debbugs.gnu.org; 25 Aug 2023 09:08:55 +0000 Received: from localhost ([127.0.0.1]:39259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZSoI-00024Y-Ii for submit@debbugs.gnu.org; Fri, 25 Aug 2023 05:08:54 -0400 Received: from mout01.posteo.de ([185.67.36.65]:54907) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZSoG-00024J-Qt for 65451@debbugs.gnu.org; Fri, 25 Aug 2023 05:08:53 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4784F240028 for <65451@debbugs.gnu.org>; Fri, 25 Aug 2023 11:08:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692954522; bh=UEA4FbM4FDLrl6DndmMehYXjn9XODoCeHO6/F3l4OAo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=Q2j5GHhOZUG7n4IuYkP/+I8G4ei9dk3XUT/JkS1tsfQeqkOdmecbDjZXo0yHH00+8 LdxRxm48Vo2MM5IUk2CO6buTbuVnmfjDIHJxZV6lVh5POAYINM7Q0bUaK2umOwrC+5 1n/wSON2WkW9QSwg+T3JCZwSl00G0d+QXuE53jPl8HQPSntMSMjgX9R+yiMrXjaAL7 mwnyVkU+wBzk3Z5wwufhgofYq0akBfbSl5pxRRX4fPK5DqNq662sUJd3SRuLVJpLf9 B55zDeL6j/SmXr4Iq0sF1ALxHZkgvSOSUQ9H23ZC+jC5CCddasVfTQa9ubOlje90bk e6BrQ1LLPGBUw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RXDdj3NLvz9rxK; Fri, 25 Aug 2023 11:08:41 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83pm3bocea.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.fsf@gnu.org> <83pm3bocea.fsf@gnu.org> Date: Fri, 25 Aug 2023 09:09:11 +0000 Message-ID: <87o7ivh4js.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: > Thinking about this some more, we will need to consider whether this > list of accumulated transactions is ever compacted by deleting old > transactions, or we let it grow indefinitely. If the former, we > should consider the case where more than one feature wants to track > buffer edits (so it is impossible to remove entries once they have > been processed by a single consumer). What I propose is actually quite similar to `buffer-undo-list'. But a bit less generic - (apply FUN-NAME ARGS) entries cannot be handled outside the narrow scope of `undo'. Similar to `buffer-undo-list' it needs to be compacted. To not lose the information when the edit history is compacted, there may be a hook executed right before the compaction, so that all the users can update their state as needed. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Aug 2023 10:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169295912216050 (code B ref 65451); Fri, 25 Aug 2023 10:26:01 +0000 Received: (at 65451) by debbugs.gnu.org; 25 Aug 2023 10:25:22 +0000 Received: from localhost ([127.0.0.1]:39341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZU0H-0004An-Oi for submit@debbugs.gnu.org; Fri, 25 Aug 2023 06:25:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35446) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZU0F-000459-Bc for 65451@debbugs.gnu.org; Fri, 25 Aug 2023 06:25: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 1qZU05-0005Fi-7K; Fri, 25 Aug 2023 06:25:09 -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=RpqC3RywY/8uKtB2Wl+L8GgDskSTahya774dQgDxfCM=; b=Ove3nYxfAHBd 4OiJtMSuF/hCSPj/FvMKqmpLFfyvAmmOGJ10X/dK7zZUJ6K0Fw6wYsdSzcqe+Ka/mbC0j4nP0Ku3f TeNp0T31dSWuEqB2nE7KMYyRYjpMY2uo3xLozP3ozyAADBfV56hRnhFGyJR4cCDDgNcS5Bm+ZCQo0 E5+QW3cuj/QyDkYfKEzr0gbTTiT0PA4r316+HhCQT1tWKPflchWOnl/tQFqYfn4A9Bcb1/Rivt1DS xobv+bMoP5PjHQJectbwEU4L52VpEIBYB5RY4RHxmM6vsaCVvaQPhD5pK7tont5w8D8ifSZpcvGup dn3xvm1+4JD6E/bmpiFuWg==; Date: Fri, 25 Aug 2023 13:25:35 +0300 Message-Id: <83fs47o1uo.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <875y53ilve.fsf@localhost> (message from Ihor Radchenko on Fri, 25 Aug 2023 08:09:41 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.fsf@gnu.org> <875y53ilve.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: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Fri, 25 Aug 2023 08:09:41 +0000 > > Eli Zaretskii writes: > > >> Elements of the list will be like > >> [:buffer-chars-modified-tick :region-beginning :region-end-before-edit :region-end-after-edit] > > > > If you really need buffer-chars-modified-tick, you will have to verify > > that it is updated before calling the function which updates the > > "transactions list". > > Do you mean that buffer-chars-modified-tick may not be yet updated at > the time treesit_record_change is called? Yes. You can audit the code and see it for yourself. > Then, treesit_record_change only uses byte positions. Will it be > possible to record buffer point positions, or may it be problematic? Sorry, I don't understand what you are saying here and how this is relevant to the issue at hand and to my comment in particular. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Aug 2023 10:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169296054118364 (code B ref 65451); Fri, 25 Aug 2023 10:50:01 +0000 Received: (at 65451) by debbugs.gnu.org; 25 Aug 2023 10:49:01 +0000 Received: from localhost ([127.0.0.1]:39376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZUNB-0004m1-59 for submit@debbugs.gnu.org; Fri, 25 Aug 2023 06:49:01 -0400 Received: from mout01.posteo.de ([185.67.36.65]:54341) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZUN7-0004ln-SN for 65451@debbugs.gnu.org; Fri, 25 Aug 2023 06:48:59 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E3101240029 for <65451@debbugs.gnu.org>; Fri, 25 Aug 2023 12:48:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692960526; bh=NQg95MQGGF2fw9sdguf0AjhVcuXWizW5Z58LrvBCLbI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=bgLyzHtmAZ8dv85CINI9aRKcVLc4fe2kfvh6qUK7xvw+mGYZuXTWaSJq+ay8TCrO6 WKwyraRyrBYTPizS3FsY8ylQtxuY5WtGWIhNGcX4LueDZRAbX2dAd7BI5jNTBIepM+ yWC8BxUZ/5GucTefdVya6WEx1pWd5yRFfLvqR613b0wh70vjj4XImMv5QxW1vlIopf Uv+Qd5Gq0wjGFz/1kJQQdYYrcJyCrAABQFsTSEUto/nv1IyhQs5sDH/1aJChs53ys+ MXB7CC1+cGh4xtNxSPoDHPacQ4wxpbhR0764z5AYzsdUYTfLUBlLB8/ggtgvN1wKMZ lNPzPfUyfQoDw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RXGsB0fGsz6tvc; Fri, 25 Aug 2023 12:48:45 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83fs47o1uo.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.fsf@gnu.org> <875y53ilve.fsf@localhost> <83fs47o1uo.fsf@gnu.org> Date: Fri, 25 Aug 2023 10:49:16 +0000 Message-ID: <87o7ivbdn7.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: >> Then, treesit_record_change only uses byte positions. Will it be >> possible to record buffer point positions, or may it be problematic? > > Sorry, I don't understand what you are saying here and how this is > relevant to the issue at hand and to my comment in particular. Never mind. I am jumping ahead of the discussion. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 26 Aug 2023 07:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169303378910168 (code B ref 65451); Sat, 26 Aug 2023 07:10:02 +0000 Received: (at 65451) by debbugs.gnu.org; 26 Aug 2023 07:09:49 +0000 Received: from localhost ([127.0.0.1]:41612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZnQb-0002dt-2V for submit@debbugs.gnu.org; Sat, 26 Aug 2023 03:09:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZnQZ-0002df-5x for 65451@debbugs.gnu.org; Sat, 26 Aug 2023 03:09:48 -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 1qZnQM-0003qg-SQ; Sat, 26 Aug 2023 03:09:35 -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=FVhN+naUvo8lC1i6FwGAo4nZdy43xh7soxxc/pDvxrg=; b=Hw2rFLUJHZzt vhQD3wKIBgoW82wxjOMbV6VnV70L+jo2IxQFk0YP9Y2V0QP9lEiZTIXYv+b2zx/UZR5dszejAxQSJ N456Ksfm91F0EW+SGJek3uTtKgb9S1NwCbiLHtyNwyL9H1baPMLJ7Z/v4umwbQj1/gBG51tp4Voao 0A3qJWO3Zqyu4a2uCrlBmuTc58Ap/3OT8oPyDGiM44rT4wZ0ExoAW7TsYVK1Q/q7sQyPSxg10aWy7 4sVg+mD56KEfEzcrVIX0qqy8PdOupgbIdVXezTPgY+A3tE+flGB24Pr8gTMxKGStdSgYULhFyDcPs PnqkiuL1R0+6N2wsMRrd3g==; Date: Sat, 26 Aug 2023 10:10:02 +0300 Message-Id: <83cyzamg8l.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87o7ivh4js.fsf@localhost> (message from Ihor Radchenko on Fri, 25 Aug 2023 09:09:11 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.fsf@gnu.org> <83pm3bocea.fsf@gnu.org> <87o7ivh4js.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: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Fri, 25 Aug 2023 09:09:11 +0000 > > Eli Zaretskii writes: > > > Thinking about this some more, we will need to consider whether this > > list of accumulated transactions is ever compacted by deleting old > > transactions, or we let it grow indefinitely. If the former, we > > should consider the case where more than one feature wants to track > > buffer edits (so it is impossible to remove entries once they have > > been processed by a single consumer). > > What I propose is actually quite similar to `buffer-undo-list'. > But a bit less generic - (apply FUN-NAME ARGS) entries cannot be handled > outside the narrow scope of `undo'. > Similar to `buffer-undo-list' it needs to be compacted. Not sure what this means in practice. the entries in the list we are discussing will be very different from the entries in buffer-undo-list. > To not lose the information when the edit history is compacted, there > may be a hook executed right before the compaction, so that all the > users can update their state as needed. If the compaction will run from GC, then we cannot safely call Lisp hooks at that time. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Aug 2023 08:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169312401312601 (code B ref 65451); Sun, 27 Aug 2023 08:14:02 +0000 Received: (at 65451) by debbugs.gnu.org; 27 Aug 2023 08:13:33 +0000 Received: from localhost ([127.0.0.1]:44045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qaAto-0003HB-QH for submit@debbugs.gnu.org; Sun, 27 Aug 2023 04:13:33 -0400 Received: from mout02.posteo.de ([185.67.36.66]:55323) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qaAtj-0003Gt-Sd for 65451@debbugs.gnu.org; Sun, 27 Aug 2023 04:13:31 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 61D08240103 for <65451@debbugs.gnu.org>; Sun, 27 Aug 2023 10:13:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1693123996; bh=KMxcHyTQ1kCA4WLRTXrAE6X/LvkkG39qlruKtBUmI2A=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=WdDMFYQSCxYgbp+g3A7E8yiFN4OiIXiyM9f6LUZgjQXWOW628DUhqsJfkBo8I4z7E vW8JAiAghXgwx38jGuTApNMZNIE3YgdNNoLj/zolvfHgVuizqRb8LW6zSUeHENuyP5 EEe3urcsTqWWTN/cMqVgLgXGobXvzO++oPP0QJ+V+eBG05Sg688+jUITaenatS1gDI UmgEFmL8elaO8pscN7EliYAHcQu7/zW9rhZaM5jIVzApmVFdpvfGliQ4t9vLImRi6O xQlTgqmUgx0qRhIA11Ow8AArTChmymXYe4xYnRPNEthq8r6XOH3kERCE1m9Yx5TPM1 SO5OiHwXnY80A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RYRJq4Ky9z9rxL; Sun, 27 Aug 2023 10:13:15 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83cyzamg8l.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.fsf@gnu.org> <83pm3bocea.fsf@gnu.org> <87o7ivh4js.fsf@localhost> <83cyzamg8l.fsf@gnu.org> Date: Sun, 27 Aug 2023 08:13:38 +0000 Message-ID: <87pm38gax9.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: >> What I propose is actually quite similar to `buffer-undo-list'. >> But a bit less generic - (apply FUN-NAME ARGS) entries cannot be handled >> outside the narrow scope of `undo'. >> Similar to `buffer-undo-list' it needs to be compacted. > > Not sure what this means in practice. the entries in the list we are > discussing will be very different from the entries in > buffer-undo-list. What I meant is that similar principles with undo-limit-like variables may apply. >> To not lose the information when the edit history is compacted, there >> may be a hook executed right before the compaction, so that all the >> users can update their state as needed. > > If the compaction will run from GC, then we cannot safely call Lisp > hooks at that time. Fair point. Then, what about compacting the "edit list" more frequently, so that we do not need to worry about its size? But I am not sure what frequency will be safe. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Aug 2023 08:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169312502714361 (code B ref 65451); Sun, 27 Aug 2023 08:31:02 +0000 Received: (at 65451) by debbugs.gnu.org; 27 Aug 2023 08:30:27 +0000 Received: from localhost ([127.0.0.1]:44081 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qaBAA-0003jZ-PD for submit@debbugs.gnu.org; Sun, 27 Aug 2023 04:30:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qaBA8-0003jJ-1y for 65451@debbugs.gnu.org; Sun, 27 Aug 2023 04:30:26 -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 1qaB9w-0002jg-SP; Sun, 27 Aug 2023 04:30:12 -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=g4nCs3S4oFgR9kBL8M3xxx6Rm50cJyqQEFRamGsfHvA=; b=hVXhx5m3b5Cl QGm0G8emPxt6ufXz0ugyxZEJb8dLW4FZw/AlUJxRJ2YH5TxBPXUcpQQbe104FSqnvdd8L4DyzFwu2 bTpKzAV13uMfHRdEVFV9dX9eR3Rl3jMAuYT07UzJomOaGc3kroPB+WQX/AlmqTjh+HdAU2GpgLCJx DXn4C11x2avuN3HrelGWLjjDukD3MnITdwHli354Hx/wrxugOGqWb2zCfv09d7cC93mcrTTZ2nbSA 7GaYmyskmIGDj081FCla0IQJO6PxDPiH/QW8wCWUpynvVyW0lLct4iSIvOC4z0SXXnp9w6AnCEniQ pmeX1H752a1sQEqqbJk73w==; Date: Sun, 27 Aug 2023 11:29:44 +0300 Message-Id: <83v8d0khvr.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87pm38gax9.fsf@localhost> (message from Ihor Radchenko on Sun, 27 Aug 2023 08:13:38 +0000) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.fsf@gnu.org> <83pm3bocea.fsf@gnu.org> <87o7ivh4js.fsf@localhost> <83cyzamg8l.fsf@gnu.org> <87pm38gax9.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: casouri@gmail.com, 65451@debbugs.gnu.org > Date: Sun, 27 Aug 2023 08:13:38 +0000 > > Eli Zaretskii writes: > > >> What I propose is actually quite similar to `buffer-undo-list'. > >> But a bit less generic - (apply FUN-NAME ARGS) entries cannot be handled > >> outside the narrow scope of `undo'. > >> Similar to `buffer-undo-list' it needs to be compacted. > > > > Not sure what this means in practice. the entries in the list we are > > discussing will be very different from the entries in > > buffer-undo-list. > > What I meant is that similar principles with undo-limit-like variables > may apply. Well, the devil is in the details ;-) > >> To not lose the information when the edit history is compacted, there > >> may be a hook executed right before the compaction, so that all the > >> users can update their state as needed. > > > > If the compaction will run from GC, then we cannot safely call Lisp > > hooks at that time. > > Fair point. > Then, what about compacting the "edit list" more frequently, so that we > do not need to worry about its size? But I am not sure what frequency > will be safe. Something like that, yes. But we need to invent a protocol which would allow several clients to consume the list safely and without the risk of missing edits. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Aug 2023 07:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: casouri@gmail.com, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.169329475814343 (code B ref 65451); Tue, 29 Aug 2023 07:40:02 +0000 Received: (at 65451) by debbugs.gnu.org; 29 Aug 2023 07:39:18 +0000 Received: from localhost ([127.0.0.1]:49462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qatJl-0003jH-IU for submit@debbugs.gnu.org; Tue, 29 Aug 2023 03:39:17 -0400 Received: from mout02.posteo.de ([185.67.36.66]:48301) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qatJi-0003j0-Mc for 65451@debbugs.gnu.org; Tue, 29 Aug 2023 03:39:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 2AB49240106 for <65451@debbugs.gnu.org>; Tue, 29 Aug 2023 09:39:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1693294741; bh=54lU5jsNW8jbncxRPta+drUbfQJaGUUxrxjc+AWB2wg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=DcYA1WSqDWzoYQB8xkiBWWdZesepfWUaESx9YpLifNoPjcI6Q4E087aOqaOsk33M0 0QD0cgnNiz77fT6eXAKybuKO3/HcWvVED/9wS07gbmHUwfVU9YIfW4wVgVP30v4ak/ OSAl01IYyEm67NQ9epdt4kk/deRD5+DZg3nU4jlFBeE38Nvm9laygKBGdAZO737YRQ q8xFKcNyYncAC0xTaU8gvHxrQjqCeNmu/S+fAC2WpL2vhu7wr8XJrU40MwoOzshBy7 l0J54vLDmF7ft+25+yeLp7fC+TmCODjocmW1ZrC3brAgJ2UU0M6Mo3D839CgOg9lNj BbIW3GYyrm02g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RZfSN33bfz6txC; Tue, 29 Aug 2023 09:39:00 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <83v8d0khvr.fsf@gnu.org> References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <87jztn1c5x.fsf@localhost> <834jkrters.fsf@gnu.org> <87v8d7i48y.fsf@localhost> <83ttsrrroo.fsf@gnu.org> <874jkq87jl.fsf@localhost> <83y1i1r689.fsf@gnu.org> <87fs487uip.fsf@localhost> <83zg2gq2vj.fsf@gnu.org> <871qfsel8q.fsf@localhost> <83r0nsprrk.fsf@gnu.org> <87cyzck1uh.fsf@localhost> <83il94pk49.fsf@gnu.org> <83pm3bocea.fsf@gnu.org> <87o7ivh4js.fsf@localhost> <83cyzamg8l.fsf@gnu.org> <87pm38gax9.fsf@localhost> <83v8d0khvr.fsf@gnu.org> Date: Tue, 29 Aug 2023 07:39:27 +0000 Message-ID: <87o7iq1emo.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: >> Then, what about compacting the "edit list" more frequently, so that we >> do not need to worry about its size? But I am not sure what frequency >> will be safe. > > Something like that, yes. But we need to invent a protocol which > would allow several clients to consume the list safely and without the > risk of missing edits. I can think of two approaches: 1. There will be a new buffer-local variable - `buffer-edit-history' that will hold recent `buffer-edit-history-limit' edits. This way, Elisp functions will be able to examine it any time they need to. In addition, there will be `after-edit-functions' hook that will be called after `buffer-edit-history-limit' is exceeded. Before the hook is called, `buffer-edit-history' is truncated. The hook functions will be called with a single argument - list of edits that have been removed from the `buffer-undo-history'. That way, Elisp will be able to process edits that will disappear from the `buffer-edit-history'. Each entry in `buffer-edit-history' will be a list of (beg end_before end_after counter), describing region boundaries before and after the edit + a counter that can be used to keep track of processed positions. The counter will be useful for the code that processes `buffer-edit-history' independently, outside `after-edit-functions', and may need to skip already processed elements. (I initially though that we can simply hold `buffer-chars-modified-tick' here, but it is not necessary to hold `buffer-chars-modified-tick' specifically - just something to indicate "epoch" in the edit history). The downside of exposing `buffer-edit-history' is that some bad-written Elisp may be tempted to hold a pointer to a cons cell in `buffer-edit-history', thus preventing GC. 2. We can have `after-edit-functions' being called once for each edit event with (beg end_before end_after) arguments. To avoid skipping edits, in addition to Emacs sometimes calling the hook, we should allow Elisp to trigger the hook early, by calling `process-buffer-edits'. This way, synchronization can be ensured. The downside here is when multiple consumers are using `after-edit-functions' - synchronization (`process-buffer-edits') requested by one consumer will also trigger all other consumers, potentially creating extra overheads. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Mar 2024 13:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Alan Mackenzie , Ihor Radchenko , 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.17118067324554 (code B ref 65451); Sat, 30 Mar 2024 13:53:02 +0000 Received: (at 65451) by debbugs.gnu.org; 30 Mar 2024 13:52:12 +0000 Received: from localhost ([127.0.0.1]:44244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqZ80-0001BO-2Q for submit@debbugs.gnu.org; Sat, 30 Mar 2024 09:52:12 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqZ7y-0001Aq-BQ for 65451@debbugs.gnu.org; Sat, 30 Mar 2024 09:52:11 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B175D4413BA; Sat, 30 Mar 2024 09:52:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711806721; bh=CukHSMFKxw0XwVfaBKULkiKoHdf/WWf/uV7/3eawy8M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mvZ8Gy9p6UuOTKJho/pXfxOghE8JKhnkSN0UjVXt3emB/8MrHs6Veo1OhTjuOz0LV 5YQixGUpAaltBivk4+mY+bNZQeepXTc3FoC1KRqW2pYrV7Y15SVwd5Fzby6xJ16ZBv tk9SWZYLY2dvTIQ5ZJhXAn65lMQamHuIJA8fr0lMsaPnZx77ORe3cubSVaXsv6HiXF dH23ieKI3WSvIJjvRre6JTdNQZEqX9A2boMs0Jx8Y61aCXN8FyugTTGKSHY6wu4Ji7 A7w9il2WmRFGXhAPFmgGIZdMY7JCRKkgpeoJ9gp/h3MVPd64SqQgY13R1940A0/JTr owAzAuLenzurw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5DCBE441388; Sat, 30 Mar 2024 09:52:01 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2E87E120618; Sat, 30 Mar 2024 09:52:01 -0400 (EDT) From: Stefan Monnier In-Reply-To: <83a5ujtgfo.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 22 Aug 2023 15:22:35 +0300") Message-ID: References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> Date: Sat, 30 Mar 2024 09:51:59 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.192 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: 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 (---) >> =E2=9B=94 Warning (emacs): Before: 1278 1281 >> =E2=9B=94 Warning (emacs): Before: 1278 1288 >> =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 0 >> =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 >>=20 >> Note how "After: 1278 1288 delta: 0" reports a change of "utf-8-unix" >> that did not alter the buffer text size. It is trigerred _before_ >> "After: 1278 1288 delta: 7" that corresponds to replacing "UTF" with >> "utf-8-unix". Hmm... yes, that's bad. Alan, have you looked at this? I suspect the best option in the above case is to inhibit the inner calls to before/after (assuming we're sure they change only the "new text"), so we'd be down to: =E2=9B=94 Warning (emacs): Before: 1278 1281 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 > I think Org mode is relying on something it should not. This > particular use case aside, Emacs is allowed to call a function that > changes the buffer from a function that itself changes the buffer, and > it is allowed to call that inner function _before_ it did all the > changes it intended to do. AFAIK the above sequences breaks the promise we make about `before-change-functions` and `after-change-functions`. Almost all the non-trivial users of those hooks (i.e. basically those that need to use both hooks) have extra sanity and raise the heads up in despair when faced with things like the above (my `track-changes.el` lacks such sanity checks, but that's because it's a PoC). Stefan From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Mar 2024 14:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: acm@muc.de, yantar92@posteo.net, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.17118078809740 (code B ref 65451); Sat, 30 Mar 2024 14:12:02 +0000 Received: (at 65451) by debbugs.gnu.org; 30 Mar 2024 14:11:20 +0000 Received: from localhost ([127.0.0.1]:45926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqZQV-0002X2-GZ for submit@debbugs.gnu.org; Sat, 30 Mar 2024 10:11:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqZQS-0002Wm-OX for 65451@debbugs.gnu.org; Sat, 30 Mar 2024 10:11:17 -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 1rqZQK-0000pZ-4v; Sat, 30 Mar 2024 10:11:08 -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=wxMiB2NK6HWmQgrwQXEms5BLgkBaRAQN9+BTMOoeZ+U=; b=BdgU+y3qDU6O UXcFKcCIq+WF2ExH+cicmmzhnJjQkd0cBVHELrSpVe9dpyLdly4Mn32SMPVBaOzXtP5iOuLycSOGC 2Jp4OtmUD5NyR4+f18XdJj7nXttjw3b/YAtWFehwUEQZ4gIYH10Q8NWUQDzF1QhTobiGl3XxVjUqF wSpXdf+UgS0r1Co40H6ecBBuAt8W+TkU10hlUz9qDD0MyvVHUKhOViXEgDLPC8MwXyKX81218f29d D6EwLDwMbdW4VVrVoB0IVCeQUCButt1rWj4EVjq8mm90qciL13ioftbx1gcbK3IWES0bH6SGkxshu w4llKfvM7ACOT7QZ/NmQjg==; Date: Sat, 30 Mar 2024 17:11:02 +0300 Message-Id: <86frw7dd3d.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sat, 30 Mar 2024 09:51:59 -0400) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.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 (---) > From: Stefan Monnier > Cc: Ihor Radchenko , 65451@debbugs.gnu.org, Alan > Mackenzie > Date: Sat, 30 Mar 2024 09:51:59 -0400 > > > I think Org mode is relying on something it should not. This > > particular use case aside, Emacs is allowed to call a function that > > changes the buffer from a function that itself changes the buffer, and > > it is allowed to call that inner function _before_ it did all the > > changes it intended to do. > > AFAIK the above sequences breaks the promise we make about > `before-change-functions` and `after-change-functions`. > > Almost all the non-trivial users of those hooks (i.e. basically those > that need to use both hooks) have extra sanity and raise the heads up in > despair when faced with things like the above (my `track-changes.el` > lacks such sanity checks, but that's because it's a PoC). I still stand by my opinion: Org is relying on something it cannot rely upon, not as long as a function that changes a buffer can be called from another function which changes the same buffer. I don't see how we can avoid breaking code which relies on such assumptions, not in general anyway. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Mar 2024 15:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acm@muc.de, yantar92@posteo.net, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.171181312125951 (code B ref 65451); Sat, 30 Mar 2024 15:39:01 +0000 Received: (at 65451) by debbugs.gnu.org; 30 Mar 2024 15:38:41 +0000 Received: from localhost ([127.0.0.1]:46061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqan3-0006kV-4C for submit@debbugs.gnu.org; Sat, 30 Mar 2024 11:38:41 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46045) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqan1-0006jm-AN for 65451@debbugs.gnu.org; Sat, 30 Mar 2024 11:38:39 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E9972441058; Sat, 30 Mar 2024 11:38:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711813105; bh=1cik+zN37MvuPEZMg9V6TzlNwZt2CTjAjDIp/HpGC8k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iK4AOP0Is4XnqTrhdjODDzlNL3F1J31+39O4RbOdk8NqcRt5QFpujmuAJ03soA0Sd S9wAOXnx/zNE3YyREnuJSXBkJW1KAbs6LA5Vy75L9ER/SH72dMWmJZQSBGdNO7yvJV MwvKJTphBkMlNRXYgZbEfrBTdZOxux1oEc3VzlvN9pBfANEtc3PI+yKygzZiss6ier OsWvBZ28Tz+f25lrKXjfSZm4CeZ5YMuTk0ysj6S/WXjiORBEOLfL0Q0J80lX6b/dNE N5mtbqG1vg+3F9MLtsAfRqxGEE2Qk+DOWP1WfPu8+WvND2fuFeD5/bvks6KeOpeUoW R9PfiL471o2Nw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2BFE4441451; Sat, 30 Mar 2024 11:38:25 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EC0E312077F; Sat, 30 Mar 2024 11:38:24 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86frw7dd3d.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Mar 2024 17:11:02 +0300") Message-ID: References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <86frw7dd3d.fsf@gnu.org> Date: Sat, 30 Mar 2024 11:38:24 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.144 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: 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 (---) > I still stand by my opinion: Org is relying on something it cannot > rely upon, not as long as a function that changes a buffer can be > called from another function which changes the same buffer. `*-change-functions` should not modify the buffer (we could try and enforce this, tho in my experience those that do will get punished pretty quickly already), so the only cases I can think of where "a function that changes a buffer can be called from another function which changes the same buffer" is when both of those functions are in our C code and we should have enough control to fix those cases. > I don't see how we can avoid breaking code which relies on such > assumptions, not in general anyway. All sophisticated-enough users of `*-change-functions` rely on this (and come with sanity checks to detect the problem and fallback on an expensive recovery when needed, because indeed we tend to break our promises =F0=9F=99=81). So we really should try and fix those. Alan did convince me that we should treat them as bugs and that we should try and fix them. Stefan From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Mar 2024 16:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: acm@muc.de, yantar92@posteo.net, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.17118172736572 (code B ref 65451); Sat, 30 Mar 2024 16:48:02 +0000 Received: (at 65451) by debbugs.gnu.org; 30 Mar 2024 16:47:53 +0000 Received: from localhost ([127.0.0.1]:46109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqbs0-0001hv-QX for submit@debbugs.gnu.org; Sat, 30 Mar 2024 12:47:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqbrx-0001gv-Hr for 65451@debbugs.gnu.org; Sat, 30 Mar 2024 12:47:51 -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 1rqbrq-0002Dk-7s; Sat, 30 Mar 2024 12:47:42 -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=ZFH9wdQWjbpNyaORZHdx0qMaIQ88S+iR9Dp50rLWYwk=; b=DKj9kQhLq4NT NEC+JpIJTDrmiQaKgcj3vfFKioG7y3C9/HOuuFuzR40ghIw0Llw/+KcMHXh5ivQkkgEVRO1zns+1m +QbW+VzCsww6K0EH5+i2t9WgmqS551BFqlN62PB13U5k6O19uYvOXObdtNSAPkouNZgNxdK26lfFV rxjWzI5AFoLSKH0jg8qLbwpKnYZDYhkW+6BV/aGmhNpOgzLeA4tdMTA0EvyrLJsGKiYwHGPPk3uO0 WjPDX8e3vrhbBXPrpwv3g5bX8OQ78W2pf8VOlnb2/kX74sbN5ZvD3ADo1qdRa2hmbC8fpgQUeHqkw AY3vD8xqHngJprc/L2ePeA==; Date: Sat, 30 Mar 2024 19:47:38 +0300 Message-Id: <865xx3d5ud.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sat, 30 Mar 2024 11:38:24 -0400) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <86frw7dd3d.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 (---) > From: Stefan Monnier > Cc: yantar92@posteo.net, 65451@debbugs.gnu.org, acm@muc.de > Date: Sat, 30 Mar 2024 11:38:24 -0400 > > > I still stand by my opinion: Org is relying on something it cannot > > rely upon, not as long as a function that changes a buffer can be > > called from another function which changes the same buffer. > > `*-change-functions` should not modify the buffer That's not what happened in the case described in that bug, AFAIR. Simply a buffer change started, then, before it ended, another nested change was started. > so the only cases I can think of where "a function that changes a > buffer can be called from another function which changes the same > buffer" is when both of those functions are in our C code and we > should have enough control to fix those cases. You forget the various hooks, other than buffer modification hooks. > Alan did convince me that we should treat them as bugs and that we > should try and fix them. He didn't convince me. From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Mar 2024 03:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Alan Mackenzie , Ihor Radchenko , 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.171185414630208 (code B ref 65451); Sun, 31 Mar 2024 03:03:02 +0000 Received: (at 65451) by debbugs.gnu.org; 31 Mar 2024 03:02:26 +0000 Received: from localhost ([127.0.0.1]:46401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqlSj-0007rA-HH for submit@debbugs.gnu.org; Sat, 30 Mar 2024 23:02:25 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqlSi-0007qw-2o for 65451@debbugs.gnu.org; Sat, 30 Mar 2024 23:02:24 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 66DA180D32; Sat, 30 Mar 2024 23:02:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711854135; bh=tIlogMunJ5PLkGfurLQcu8OO8JuvJ3zXmkOkK1WFgT0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LkO14kspMsWefAku5qnmPaYUN1yRbJaM8dDCJufV+OWQXYDnL+0gKx5TGajhLBpJo HbnAxO04gMz1hCeQAUDiOocS3d1zGwPWACS3ZiVALPYAb0eIUNo6+ogaBhYoO6Apd0 JO91rH1K6oXrsHMnR7w+FCDhguNTtBh7xUk2Y2ada7Ku/+8ToNMInO6BnhuTfgnnKr T9s1Z8aGi37XsIoZm3E2NXs424ET4P5U0ee7Bc0DlUCLz6m5peLY1j9EMKEdPp4tlP APQr+hJa0khzkwMyqgFwG0861gtKVO9utpVOwYmcs3ykVkqE9VedX2r2DPlbpbDI5r hvje50CL+FwZw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6351780A6B; Sat, 30 Mar 2024 23:02:15 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3614312030A; Sat, 30 Mar 2024 23:02:15 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Sat, 30 Mar 2024 09:51:59 -0400") Message-ID: References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> Date: Sat, 30 Mar 2024 23:02:14 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.134 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: 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 (---) > I suspect the best option in the above case is to inhibit the inner > calls to before/after (assuming we're sure they change only the "new > text"), so we'd be down to: > > =E2=9B=94 Warning (emacs): Before: 1278 1281 > =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 A simpler option is the patch below. Stefan diff --git a/src/search.c b/src/search.c index 2ad565fadde..83ff7120e43 100644 --- a/src/search.c +++ b/src/search.c @@ -2769,6 +2769,8 @@ DEFUN ("replace-match", Freplace_match, Sreplace_matc= h, 1, 5, 0, /* Replace the old text with the new in the cleanest possible way. */ replace_range (sub_start, sub_end, newtext, 1, 0, 1, true, true); =20 + signal_after_change (sub_start, sub_end - sub_start, SCHARS (newtext)); + if (case_action =3D=3D all_caps) Fupcase_region (make_fixnum (search_regs.start[sub]), make_fixnum (newpoint), @@ -2792,7 +2794,6 @@ DEFUN ("replace-match", Freplace_match, Sreplace_matc= h, 1, 5, 0, /* Now move point "officially" to the end of the inserted replacement. = */ move_if_not_intangible (newpoint); =20 - signal_after_change (sub_start, sub_end - sub_start, SCHARS (newtext)); update_compositions (sub_start, newpoint, CHECK_BORDER); =20 return Qnil; From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Mar 2024 03:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acm@muc.de, yantar92@posteo.net, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.171185430530628 (code B ref 65451); Sun, 31 Mar 2024 03:06:01 +0000 Received: (at 65451) by debbugs.gnu.org; 31 Mar 2024 03:05:05 +0000 Received: from localhost ([127.0.0.1]:46406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqlVI-0007xl-40 for submit@debbugs.gnu.org; Sat, 30 Mar 2024 23:05:04 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqlVG-0007wv-1W for 65451@debbugs.gnu.org; Sat, 30 Mar 2024 23:05:02 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 211EF44230A; Sat, 30 Mar 2024 23:04:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711854292; bh=jxxzXM02kK/44GHOEwbVYuKZ0mJr9EetlubCp95+yIo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nlKsdfoqR9+cO9eqSQBtpFSv+RC8eGMRb4TTLBEeKyoihPEW142VYKGkmbiw3haL8 bjNRcyGI4UW39IOZ4bzAVHZpuJ2hbIyTseX/FTbAtXbE9QkllTVwCbZPkfCbv+xM6g Fj6xbQ+3nVkl7eqO0qfh8DWfpY8dnuc6tE59KAXY4oPjqacU6f0/SOe3EbUf9QRj4b MPSC8MU0X4Wb0+WLSmIAfTybLiaVxIvVS763FBEgWTeKlRLKa+8zLikoeMNzcZAkvj SmgVjQBup7C/v/fSrHxfQBlOsQKnmYgL4/7PW5BW2fVfsHtxTHuAP6qnS0w58iMr5I 8Uyy1lwugCL4A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DDFBD4422A2; Sat, 30 Mar 2024 23:04:52 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AD8A912067B; Sat, 30 Mar 2024 23:04:52 -0400 (EDT) From: Stefan Monnier In-Reply-To: <865xx3d5ud.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Mar 2024 19:47:38 +0300") Message-ID: References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <86frw7dd3d.fsf@gnu.org> <865xx3d5ud.fsf@gnu.org> Date: Sat, 30 Mar 2024 23:04:51 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.115 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: 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 (---) >> `*-change-functions` should not modify the buffer > That's not what happened in the case described in that bug, AFAIR. No, indeed. >> so the only cases I can think of where "a function that changes a >> buffer can be called from another function which changes the same >> buffer" is when both of those functions are in our C code and we >> should have enough control to fix those cases. > You forget the various hooks, other than buffer modification hooks. If we have to run them some time between `before-c-f` and `after-c-f`, then they should not modify the buffer, just like the `*-change-functions` hooks,=20 >> Alan did convince me that we should treat them as bugs and that we >> should try and fix them. > He didn't convince me. =F0=9F=99=82 Stefan From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Mar 2024 06:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: acm@muc.de, yantar92@posteo.net, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.17118652196089 (code B ref 65451); Sun, 31 Mar 2024 06:07:01 +0000 Received: (at 65451) by debbugs.gnu.org; 31 Mar 2024 06:06:59 +0000 Received: from localhost ([127.0.0.1]:46476 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqoLK-0001a8-JH for submit@debbugs.gnu.org; Sun, 31 Mar 2024 02:06:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqoLI-0001ZI-NT for 65451@debbugs.gnu.org; Sun, 31 Mar 2024 02:06:57 -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 1rqoL8-0003mS-6X; Sun, 31 Mar 2024 02:06:46 -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=SFzZTB4W3KGixFAlMFEK4XdT330w3EbXTSAj84uB19g=; b=gpR6dLS8tc3OJN96wfhj Tp6xhNW9qDn3JSW0+ur8VcYYnzfUjn1aGNKn9xlTmqLV3nBvLs7O6PLN/2x1hMQ3gZn/KVGucrwF2 /06ymSjS4rTMqyMlwAf+f9lwK0nCWdQ1gqV9ecGhr+rD/7cS/C+ZaY02bdjF2LmqktiDfUcQsxrrx cQtU/sLqGO2+aj/KErkxiK7FmElTn0vdI8dJ/HRtVHU/8+xQtlwDiYILX2aGtpcxvTGmeN8APj7k7 mYxJuwMWnvLTezWC/7bnlu85ivwq8CthLjf6NCSPWo9p0TxEFcy2EgIjFPL7G3KYjIbnssmguSgHP 9D2L7vze8PzUaQ==; Date: Sun, 31 Mar 2024 09:06:44 +0300 Message-Id: <86r0fraqa3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sat, 30 Mar 2024 23:02:14 -0400) References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> 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: Stefan Monnier > Cc: Ihor Radchenko , 65451@debbugs.gnu.org, Alan > Mackenzie > Date: Sat, 30 Mar 2024 23:02:14 -0400 > > > I suspect the best option in the above case is to inhibit the inner > > calls to before/after (assuming we're sure they change only the "new > > text"), so we'd be down to: > > > > ⛔ Warning (emacs): Before: 1278 1281 > > ⛔ Warning (emacs): After: 1278 1288 delta: 7 > > A simpler option is the patch below. Doesn't that miss the changes done by upcase-region? Also, what about point not being after the inserted replacement at that place? From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Mar 2024 13:59:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acm@muc.de, yantar92@posteo.net, 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.17118934862317 (code B ref 65451); Sun, 31 Mar 2024 13:59:03 +0000 Received: (at 65451) by debbugs.gnu.org; 31 Mar 2024 13:58:06 +0000 Received: from localhost ([127.0.0.1]:48153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqvhG-0000bJ-7c for submit@debbugs.gnu.org; Sun, 31 Mar 2024 09:58:06 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqvhF-0000ai-2f for 65451@debbugs.gnu.org; Sun, 31 Mar 2024 09:58:05 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A7E2010005D; Sun, 31 Mar 2024 09:57:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711893475; bh=PHaKGHcAaiSbpNhrnUAnvHnnPmHnD7L9JunYG+XXjb8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PWx3jC6ITYQFXm9o8EVfZ1i2Y2iKbEF3GKNLcvJxVeyY7SILmDd/5SNI1/YpJrqVP Zbm7j8ssUjbPsijfj6vphNa1x1Us6+nBGzMgUvbc0Zh60BRqbE66gD+n0DrgxpAKYw PRZ/B6hns/4gpJSl39zBeQ2MGFYjgmtSg7b1L5iNGlWSJY6PORLukrhnyIfQ9XiylV VBQjq93hkNIbfw6DspcGd0D4F1HB7M9iy4+wws4vBTGpoVizXJzMEMW8umQev2KwXm GYFPO1mxPo62TFtHBdJuVZS2ja5WpBvazFufKh5/77sTr81e73cL9fgg1ZN6j51tiv StqP3Z0hLLwrA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CE0CE100048; Sun, 31 Mar 2024 09:57:55 -0400 (EDT) Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9B3E1120642; Sun, 31 Mar 2024 09:57:55 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86r0fraqa3.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 31 Mar 2024 09:06:44 +0300") Message-ID: References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> <86r0fraqa3.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sun, 31 Mar 2024 09:57:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.046 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: 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 (---) >> > I suspect the best option in the above case is to inhibit the inner >> > calls to before/after (assuming we're sure they change only the "new >> > text"), so we'd be down to: >> > >> > =E2=9B=94 Warning (emacs): Before: 1278 1281 >> > =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 >>=20 >> A simpler option is the patch below. > > Doesn't that miss the changes done by upcase-region? No: `upcase-region` runs its own `before/after-change-functions` (indeed, these were the problematic nested ones which break the order). > Also, what about point not being after the inserted replacement at > that place? `*-change-functions` can't rely on the position of point so that's not an issue. Stefan From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Apr 2024 18:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Alan Mackenzie , Ihor Radchenko , 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.171251396022105 (code B ref 65451); Sun, 07 Apr 2024 18:20:01 +0000 Received: (at 65451) by debbugs.gnu.org; 7 Apr 2024 18:19:20 +0000 Received: from localhost ([127.0.0.1]:44553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtX6u-0005kS-58 for submit@debbugs.gnu.org; Sun, 07 Apr 2024 14:19:20 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41208) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtX6s-0005jh-5d for 65451@debbugs.gnu.org; Sun, 07 Apr 2024 14:19:18 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0F097441195; Sun, 7 Apr 2024 14:19:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1712513943; bh=cIFFf3JisuXcH8RU0G9gbrYcYwtBmpeXxMWJWpmFVZU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=IdbqGr/Aqo5115MueEud3IoQNsQN/AGKgVmi6mL8AwqXNRmmCpZuROiNFia13Q3XE eQzl2h294EvJKn1ymcKC9ABFWm09Fdn01zHql4NaNoqkmDv6IvHikLpoUiPBIXiZAt BDBDCb8OwY6GipoqbNixdqziaktNxGpvY05MPXtfhZX60Se4vp80M6sxm3sbK1n9HA Ct/rxHHEvBoWZThNnLosBs/DpoUaE83Ynzt/r4jl/38hKRKZCPbjciRWk5Le3/p3Xa uu5bZceZT6DuKNjm4nZxi1HqozBPutSEgTKep29FGd05RcYOEzqi4QtoA1ozhi7MLo lxBo5F4IHV3Tw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 027A24410EA; Sun, 7 Apr 2024 14:19:03 -0400 (EDT) Received: from alfajor (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BDF96120648; Sun, 7 Apr 2024 14:19:02 -0400 (EDT) From: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Sat, 30 Mar 2024 23:02:14 -0400") Message-ID: References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> Date: Sun, 07 Apr 2024 14:19:01 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.027 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: 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 (---) > A simpler option is the patch below. Pushed to `master` along with a corresponding test. The test uses a "sanity check" suite which encodes the promises we make after before/after-change-functions. [ My Emacs now runs those sanity checks in all non-temp buffers. =F0=9F=99= =82 ] Stefan From unknown Tue Aug 19 21:02:38 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Ihor Radchenko Subject: bug#65451: closed (Re: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made) Message-ID: References: <871qfv2zlk.fsf@localhost> X-Gnu-PR-Message: they-closed 65451 X-Gnu-PR-Package: emacs Reply-To: 65451@debbugs.gnu.org Date: Sun, 07 Apr 2024 18:20:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1712514002-22367-1" This is a multi-part message in MIME format... ------------=_1712514002-22367-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #65451: 30.0.50; `after-change-functions' are not triggered in the same ord= er the changes are made which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 65451@debbugs.gnu.org. --=20 65451: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D65451 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1712514002-22367-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 65451-done) by debbugs.gnu.org; 7 Apr 2024 18:19:53 +0000 Received: from localhost ([127.0.0.1]:44557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtX7Q-0005nm-FV for submit@debbugs.gnu.org; Sun, 07 Apr 2024 14:19:53 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtX7N-0005mo-4n for 65451-done@debbugs.gnu.org; Sun, 07 Apr 2024 14:19:50 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C724E1000FC; Sun, 7 Apr 2024 14:19:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1712513975; bh=de6TF6LvK9eQiSrm+yVFQydjbCQjEEOxzWBQXV60A3U=; h=From:To:Subject:In-Reply-To:References:Date:From; b=bmkj6cgIQNWVcJLj+pzzq/zVoTQimDU4mmV2x1EQx/3LL7L5N0ZsD/SqXmX3WLiRn eVHbsBOfsLwyn94U7WVwJ8CM4o1l9UUbF4zDTNPcO0mni/gLOEZX3Jk51/l1/1A80s W1W2yxnq8uN1xEHLzPcqdgjAZlsg5vzB5oM2yOzsE8wPRwn5yZN+YKbS8c0m1+TxLA GphzMWz6An90rDF6GGulfTW3g3Nr4HPjyHGJvHVGxpnrraGrKslV9wBK4OsFx32GBH IT4T07rTgMUUcjs/bsjqUhCpzq56mbR9QiR1fzrZdhMVvSnuU+d8xj7KKNXDq5nvTD z1UqbflPdLtyA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EA8E510004A; Sun, 7 Apr 2024 14:19:35 -0400 (EDT) Received: from alfajor (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CA5271202C4; Sun, 7 Apr 2024 14:19:35 -0400 (EDT) From: Stefan Monnier To: 65451-done@debbugs.gnu.org Subject: Re: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made In-Reply-To: (Stefan Monnier's message of "Sat, 30 Mar 2024 23:02:14 -0400") Message-ID: References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> Date: Sun, 07 Apr 2024 14:19:34 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.020 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65451-done 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 (---) Closing, Stefan ------------=_1712514002-22367-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 22 Aug 2023 09:30:35 +0000 Received: from localhost ([127.0.0.1]:58586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYNic-0006PN-TF for submit@debbugs.gnu.org; Tue, 22 Aug 2023 05:30:35 -0400 Received: from lists.gnu.org ([2001:470:142::17]:45354) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qYNia-0006P8-Fs for submit@debbugs.gnu.org; Tue, 22 Aug 2023 05:30:33 -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 1qYNiS-0007Wr-62 for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2023 05:30:24 -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 1qYNiO-0008Pw-VB for bug-gnu-emacs@gnu.org; Tue, 22 Aug 2023 05:30:23 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4DF16240101 for ; Tue, 22 Aug 2023 11:30:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692696618; bh=PK3Oda/wFPw5GWyEc+PUBvXRzmEm0++n+0AnyRAH5Wc=; h=From:To:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=XJ7sRH4fIHqcPw64YAnFVly5smAxm3n++Zkxb8x0Kk795hx4IUIF2bFqQsJU+O94L M50k6uBJeOVOAODkv15ObMIJSPue/wuavxd4HBwNcj8OpP4LJlhY6Va0kaxbeYoPAt FWKCzqCpnH9hXV/2N4m6CH5m+ts61kH6u2bmMTo2WjQoMdI9SItYISfrCWlHfqMEEp Rggw2mhfofg7T7YzSxPJayzpTisJEsiI+ytf/EUZpjGSY8kfWYFtcII3dWZLdg6ymr ERI0DBby+tgT3GVCXRKOOYW4OLA3xTXQFbLiF/O01tNUfvrjYYdQcyRabdE+G6jFjm cc90GqJUiNIeA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RVPG14vS7z6tw7 for ; Tue, 22 Aug 2023 11:30:17 +0200 (CEST) From: Ihor Radchenko To: bug-gnu-emacs@gnu.org Subject: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Date: Tue, 22 Aug 2023 09:30:47 +0000 Message-ID: <871qfv2zlk.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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_H5=0.001, RCVD_IN_MSPIKE_WL=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.0 (+) X-Debbugs-Envelope-To: submit 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: -0.0 (/) Consider the following reproducer: 1. Create /tmp/bug.el with the following contents (defun my/setup () (interactive) (defun my/before-change (beg end) (warn "Before: %d %d" beg end)) (add-hook 'before-change-functions #'my/before-change nil 'local) (defun my/after-change (beg end pre) (warn "After: %d %d delta: %d" beg end (- end beg pre))) (add-hook 'after-change-functions #'my/after-change nil 'local)) 2. Create /tmp/bug.org https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html -UUU: @**- F2 UTF-8-demo.txt Top (1,0) (Text s-/ WS Wrap) | string | meaning | note = | |--------+------------------------------------------+----------------------= ------------------------------------------------| | - | input method | = | | UUU | coding system (keyboard terminal buffer) | (U utf-8-unix) = | | : | end-of-line convention | (: LF) (/ CR) (\ CRLF= ) | | @ | emacsclient | = | | ** | buffer status | (-- unmodified) (** m= odified) (%% read-only) (%* read-only_modified) | | - | default-directory | (- local) (@ remote) = | | F2 | frame name | (F2 the-2nd-frame) = | | | | = | 3. emacs -Q -l /tmp/bug.el /tmp/bug.org 4. M-x my/setup 5. Move point to | F2 | frame name | (F2 the-2nd-frame) = | | | | = | 6. Insert "UTF" 7. M-x dabbrev-expand 8. Observe the following in the *Warnings* buffer =E2=9B=94 Warning (emacs): Before: 1278 1278 =E2=9B=94 Warning (emacs): After: 1278 1279 delta: 1 =E2=9B=94 Warning (emacs): Before: 1284 1285 =E2=9B=94 Warning (emacs): After: 1284 1284 delta: -1 =E2=9B=94 Warning (emacs): Before: 1279 1279 =E2=9B=94 Warning (emacs): After: 1279 1280 delta: 1 =E2=9B=94 Warning (emacs): Before: 1284 1285 =E2=9B=94 Warning (emacs): After: 1284 1284 delta: -1 =E2=9B=94 Warning (emacs): Before: 1280 1280 =E2=9B=94 Warning (emacs): After: 1280 1281 delta: 1 =E2=9B=94 Warning (emacs): Before: 1284 1285 =E2=9B=94 Warning (emacs): After: 1284 1284 delta: -1 =E2=9B=94 Warning (emacs): Before: 1278 1281 =E2=9B=94 Warning (emacs): Before: 1278 1288 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 0 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 The last bit of the messages corresponds to dabbrev expansion of "UTF" to "utf-8-unix": =E2=9B=94 Warning (emacs): Before: 1278 1281 =E2=9B=94 Warning (emacs): Before: 1278 1288 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 0 =E2=9B=94 Warning (emacs): After: 1278 1288 delta: 7 Note how "After: 1278 1288 delta: 0" reports a change of "utf-8-unix" that did not alter the buffer text size. It is trigerred _before_ "After: 1278 1288 delta: 7" that corresponds to replacing "UTF" with "utf-8-unix". The order of after-change notifications thus do not correspond to the order of buffer changes. Org mode is relying upon the correct change order to update parser cache with buffer modifications. The same recipe using Emacs 27 yields the correct order <...> Warning (emacs): Before: 1278 1281 Warning (emacs): After: 1278 1288 delta: 7 Warning (emacs): Before: 1278 1288 Warning (emacs): After: 1278 1288 delta: 0 In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-08-14 built on localhost Repository revision: d483b38070120f17b1d00975081d27191d1deacc Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 System Description: Gentoo Linux --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at ------------=_1712514002-22367-1-- From unknown Tue Aug 19 21:02:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Apr 2024 19:11:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65451 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: Alan Mackenzie , Eli Zaretskii , 65451@debbugs.gnu.org Received: via spool by 65451-submit@debbugs.gnu.org id=B65451.171260343729058 (code B ref 65451); Mon, 08 Apr 2024 19:11:04 +0000 Received: (at 65451) by debbugs.gnu.org; 8 Apr 2024 19:10:37 +0000 Received: from localhost ([127.0.0.1]:47705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtuO3-0007YR-W2 for submit@debbugs.gnu.org; Mon, 08 Apr 2024 15:10:37 -0400 Received: from mout01.posteo.de ([185.67.36.65]:60325) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtuNy-0007Wp-D0 for 65451@debbugs.gnu.org; Mon, 08 Apr 2024 15:10:34 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A4DAB240028 for <65451@debbugs.gnu.org>; Mon, 8 Apr 2024 21:10:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1712603416; bh=gNAnOx75iaVJ5kxyB6LjJDGjhuTXa6tTNqMmUHBrYRc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=pszQYRf8MX3gO/oAr/gw7btNuF8qcBZZFPWVL/4WWa8XZWDFIon6gLIOsTPkkSnJM UsgGDJOjyRtRwfokdV13LK8rePJbp+mDfrhZyIwkFNGzD0KZAxuFw6d/+uuXcgxgTY 131Vf3NVNFkYgp5ouRL8uQoyWX5nbRNM2raw1Oni+Wz123VMQcBYTx1q1XLE29EpZ/ pJ5PDp+A3VryCyQrm/xLylAqLXJn74lAcwIaUqpn2fsEeyhLjVPm+0uKSvi6l2+/EF dLkhCqecrDN7WR6pJPhavsYaTqHgIbkwUUA1cI1ffFckL8GZguMkSws744l2sWcUd6 VXlUa9DknPBLQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VCzF32D56z9rxD; Mon, 8 Apr 2024 21:10:14 +0200 (CEST) From: Ihor Radchenko In-Reply-To: References: <871qfv2zlk.fsf@localhost> <83a5ujtgfo.fsf@gnu.org> Date: Mon, 08 Apr 2024 19:10:36 +0000 Message-ID: <87v84r3c2b.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 (---) Stefan Monnier writes: >> A simpler option is the patch below. > > Pushed to `master` along with a corresponding test. > The test uses a "sanity check" suite which encodes the promises we make > after before/after-change-functions. I confirm the fix on the latest master. Thanks! -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at