From debbugs-submit-bounces@debbugs.gnu.org Fri May 02 17:48:27 2025 Received: (at submit) by debbugs.gnu.org; 2 May 2025 21:48:27 +0000 Received: from localhost ([127.0.0.1]:34204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uAyF9-00056v-7q for submit@debbugs.gnu.org; Fri, 02 May 2025 17:48:27 -0400 Received: from lists.gnu.org ([2001:470:142::17]:60824) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uAyF5-00056Y-3u for submit@debbugs.gnu.org; Fri, 02 May 2025 17:48:25 -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 1uAyEz-0005tm-HN for bug-gnu-emacs@gnu.org; Fri, 02 May 2025 17:48:17 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uAyEx-0003tz-GE for bug-gnu-emacs@gnu.org; Fri, 02 May 2025 17:48:17 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 43FBC10006B for ; Fri, 2 May 2025 17:48:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746222492; bh=EmeXWFRuCruGEVweEqEsgsfDWM6RY7nA/U6OfLsEip4=; h=From:To:Subject:Date:From; b=Mml5mLpL7frxqJWGnO3R+wI6wZTkyviBcovuDt8hv8pHupYtrHeV+twECu8BkwOUC 76aweLqn53yYMiSt2YFIzRT9wrq58dcbnIQtLWLwlFNw4FJvD8D0xLBjzORUtXwisN 4EBVO+srSig+r5l2QpgqK2mMzMhNpPFXJMianc975vVjVTyQOC/BNgmERXtsNuGf1a q1N57VhnxdWd+rBe1CLGBvyuAWI/Wq8G41mZEURu9ILy5C6pK+86mq4+7uBqR10rEg JobL3gztl44vez47W+9fIIP0UIampMWxb/YeQT0wCUC7eO2i8v53Smg76pnaP3AJdL EsfrJj0bZ9/wQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2F8EF10002E for ; Fri, 2 May 2025 17:48:12 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 123101203B5 for ; Fri, 2 May 2025 17:48:12 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 31.0.50; Improving *-change-functions notifications Message-ID: X-Debbugs-Cc: monnier@iro.umontreal.ca, Alan Mackenzie Date: Fri, 02 May 2025 17:48:11 -0400 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.226 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: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.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: -1.0 (-) Package: Emacs Version: 31.0.50 After a long discussion with Eli over bug#78042, we agreed there's a need to improve the C side handling of *-change-functions notifications. Alan McKenzie made significant improvements in the past to the C code that runs these hooks, so that we now rarely break our promises in terms of how/when those notifications are sent, but there are still cases lurking. The main problem is that it's very hard to find the places where this occurs and it's not always obvious that the corresponding fix is harmless. A fix is likely to involve changes visible to the Elisp side, such as new hooks, so it seemed out of scope for bug#78042. Some of the possible avenues that came up or that I have considered and not yet discarded (and they're not mutually exclusive either): - Don't notify changes to text-properties. Currently, things like `put-text-property` run the *-change-functions like any other buffer modification. In practice this is of dubious value: - It's already the case that most calls to `put-text-property` and friends don't cause any notification because they are wrapped within a `with-silent-modifications` or otherwise take place from code which always runs with `inhibit-modification-hooks` set (e.g. because it's run from a *-change-function). So *-change-functions can't reliably track changes to text-properties. - Most *-change-functions are *not* interested in text-property changes anyway. The above two points suggest maybe we could just refrain from running *-change-functions when changing the text-properties (just like we do for changes to overlay properties). Then again, this would be a backward-incompatible change, so there's a chance some packages out there would be negatively affected. Another option would be to allow packages to choose whether to receive notifications like now or only for changes to the text. E.g. just like we have `buffer-modified-tick` and `buffer-chars-modified-tick`, we could have `*-change-functions` and `*-chars-change-functions` (with some questions remaining about `first-change-hook` and the `modification-hooks` property). Or we could rely on a (symbol) property being set on the functions added to `*-change-functions` to tell whether they want to know about changes to text-properties or not. Or maybe a more crude way would be a buffer-local variable controlling whether `*-change-functions` are called for text-property changes. - Allow *-change-functions notifications to be nested. E.g. allow a C function to call BEFORE 10 100 BEFORE 20 30 AFTER 20 25 10 AFTER 10 90 90 AFTER 10 60 80 or something like that. This would require some way for the C code to indicate which BEGIN corresponds to which AFTER. This could happen for example by adding a "change-ID" to every notification, so we'd get: BEFORE nnn 10 100 BEFORE mmm 20 30 AFTER mmm 20 25 10 AFTER nnn 10 90 90 AFTER nnn 10 60 80 I don't know how we could do that in a backward compatible way, and I can't think of any `*-change-functions` which would benefit from this nesting (all the ones I can think of would either ignore the extra info or use the change-ID to distinguish inner notifications from outer ones and then ignore the inner ones). - Maybe the last point can be turned into an internal change with no ELisp-side changes: use an approach like the one above but filter out the inner changes directly in the C code. This would provide to ELisp the same behavior that was brought by the fix to bug#78042, but without resorting to the "hammer" of `inhibit-modification-hooks` which risks silencing legitimate notifications. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 02:54:47 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 06:54:47 +0000 Received: from localhost ([127.0.0.1]:37542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uB6lq-0000Tk-Kq for submit@debbugs.gnu.org; Sat, 03 May 2025 02:54:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47802) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uB6ln-0000TU-Qb for 78221@debbugs.gnu.org; Sat, 03 May 2025 02:54:44 -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 1uB6lg-0006mZ-Lm; Sat, 03 May 2025 02:54:36 -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=zlAqvGHmtJAyWuU9zqKMvaqqMT9PsVKLxSbW2k70m3o=; b=lH21Oy2hcqlxymNBg+4E nmCw1eKzrxsVlTluaPV0ZofU0GI8HirdTkaIZ7w2pNdi6hnj6Vjrpx2CKeJSDCYOKCX52LK+CZ+bg 1ZPue/zUYzH/55yMfHdKnAg3f2N8mD5VRY9gfUnWzq4mhn+k0YkXPCu5vDi7tRulCchbSBK3495qF 6Ou1yExcOjjwf6KiGayQVwvuqDoBcMR3LV9sVwhhJw3NSkByKivSQja9PRT3YifwZ79lshcyqWWJz 9UYCK7xg9KhDmi6+bcWVH7i0A/ZHpfh5HlULIFjFzxVrmi04aK8KxQPhMfZa4AKMoZYplTHPO7Ijy 87E+HQgJtEbm1Q==; Date: Sat, 03 May 2025 09:54:33 +0300 Message-Id: <86cycqkwuu.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier , =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Ihor Radchenko , acm@muc.de In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org 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: monnier@iro.umontreal.ca, Alan Mackenzie > Date: Fri, 02 May 2025 17:48:11 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > - Allow *-change-functions notifications to be nested. > E.g. allow a C function to call > > BEFORE 10 100 > BEFORE 20 30 > AFTER 20 25 10 > AFTER 10 90 90 > AFTER 10 60 80 > > or something like that. This would require some way for the C code to > indicate which BEGIN corresponds to which AFTER. This could happen > for example by adding a "change-ID" to every notification, so we'd > get: > > BEFORE nnn 10 100 > BEFORE mmm 20 30 > AFTER mmm 20 25 10 > AFTER nnn 10 90 90 > AFTER nnn 10 60 80 > > I don't know how we could do that in a backward compatible way, and > I can't think of any `*-change-functions` which would benefit from > this nesting (all the ones I can think of would either ignore the > extra info or use the change-ID to distinguish inner notifications > from outer ones and then ignore the inner ones). > > - Maybe the last point can be turned into an internal change with no > ELisp-side changes: use an approach like the one above but filter out > the inner changes directly in the C code. This would provide > to ELisp the same behavior that was brought by the fix to bug#78042, > but without resorting to the "hammer" of `inhibit-modification-hooks` > which risks silencing legitimate notifications. On the "nested notifications" part of this, I'd like to hear specific problems with them. (I've added to the discussion people who might have real-life examples of the problems.) Specifically, I'm not sure I have a good understanding of why they are a problem in the first place. Is it only because of the difficulty to pair BEFORE and AFTER notifications? or is there something else? Due to the Emacs's highly-recursive workings and the various hooks we have, which are ever-expanding, there's a virtually infinite number of situations where some code, called while a buffer-change operation is under way, itself calls a buffer-changing primitive, thus generating nested notifications. Finding and fixing all of theses situations one by one will take us infinite time, so I would like to consider more practical alternatives. And for that, IMO we need a very good understanding of the problems they cause. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 10:13:55 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 14:13:55 +0000 Received: from localhost ([127.0.0.1]:41921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBDco-0001I2-FQ for submit@debbugs.gnu.org; Sat, 03 May 2025 10:13:55 -0400 Received: from mail.muc.de ([193.149.48.3]:12875) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBDci-0001Ha-Cq for 78221@debbugs.gnu.org; Sat, 03 May 2025 10:13:52 -0400 Received: (qmail 40411 invoked by uid 3782); 3 May 2025 16:13:41 +0200 Received: from muc.de (p4fe15fdb.dip0.t-ipconnect.de [79.225.95.219]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 03 May 2025 16:13:41 +0200 Received: (qmail 21084 invoked by uid 1000); 3 May 2025 14:13:40 -0000 Date: Sat, 3 May 2025 14:13:40 +0000 To: Stefan Monnier Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , Ihor Radchenko , =?iso-8859-1?Q?Jo=E3o_T=E1vora?= , acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Fri, May 02, 2025 at 17:48:11 -0400, Stefan Monnier wrote: > Package: Emacs > Version: 31.0.50 > After a long discussion with Eli over bug#78042, we agreed there's > a need to improve the C side handling of > *-change-functions notifications. I've glanced at bug#78042, but haven't (as yet) followed the discussions in detail. > Alan Mackenzie made significant improvements in the past to the C code > that runs these hooks, so that we now rarely break our promises in terms > of how/when those notifications are sent, but there are still > cases lurking. By "those promises", I think you mean being that we invoke before-change-functions and after-change-functions strictly in matched pairs. We only actually do this most of the time. On 2018-01-06, we formally agreed that these hooks will be invoked as follows: o - Every buffer changing primitive starts off with exactly one call to b-c-f, o - after which there will be zero, one, or several calls to a-c-f. o - The b-c-f's region will enclose those of all the a-c-f regions, but need not be the minimal such region. I actually think a good strategy would be to invoke these hooks strictly in matching pairs in all cases, but I'm sure I said that back in 2018 too. > The main problem is that it's very hard to find the places where this > occurs and it's not always obvious that the corresponding fix is > harmless. A fix is likely to involve changes visible to the Elisp side, > such as new hooks, so it seemed out of scope for bug#78042. I don't think it's all that hard. In 2020, I made a list of which non-static functions in insdel.c call before/after-change-functions. The list, which is likely still valid, or very nearly so, looked like this: insert B/A insert_and_inherit B/A insert_char B/A insert_string B/A insert_before_markers B/A insert_before_markers_and_inherit B/A insert_1_both ?/- insert_from_string B/A insert_from_string_before_markers B/A insert_from_gap_1 -/- insert_from_gap -/- insert_from_buffer B/A del_range B/A del_range_1 ?/A del_range_byte B/A del_range_both ?/A del_range_2 -/- replace_range ?/A replace_range_2 -/- modify_text B/- (where B/A means both before- and after-change-functions are called, etc.). It would be comparatively easy to modify insdel.c so that _all_ buffer changing functions invoked the two hooks in matched pairs. That would require a willingness to make substantial changes in insdel.c, something that hasn't been forthcoming in years gone bye. But if an alternative is to allow nested calls to the hooks (something we don't allow at the moment, even though the rule isn't explicitly formulated anywhere), this is going to involve modifying insdel.c anyway. > Some of the possible avenues that came up or that I have considered and > not yet discarded (and they're not mutually exclusive either): > - Don't notify changes to text-properties. > Currently, things like `put-text-property` run the *-change-functions > like any other buffer modification. In practice this is of dubious value: > - It's already the case that most calls to `put-text-property` and > friends don't cause any notification because they are wrapped within > a `with-silent-modifications` or otherwise take place from code > which always runs with `inhibit-modification-hooks` set > (e.g. because it's run from a *-change-function). > So *-change-functions can't reliably track changes to text-properties. > - Most *-change-functions are *not* interested in text-property > changes anyway. > The above two points suggest maybe we could just refrain from > running *-change-functions when changing the text-properties (just > like we do for changes to overlay properties). > Then again, this would be a backward-incompatible change, so there's > a chance some packages out there would be negatively affected. > Another option would be to allow packages to choose whether to receive > notifications like now or only for changes to the text. > E.g. just like we have `buffer-modified-tick` and > `buffer-chars-modified-tick`, we could have `*-change-functions` > and `*-chars-change-functions` (with some questions remaining about > `first-change-hook` and the `modification-hooks` property). > Or we could rely on a (symbol) property being set on the functions > added to `*-change-functions` to tell whether they want to know about > changes to text-properties or not. > Or maybe a more crude way would be a buffer-local variable controlling > whether `*-change-functions` are called for text-property changes. I think it was a mistake in the beginning to have text property modifications trigger before/after-c-f. But seeing it's been that way for so long, I don't think it would be a good idea to change it now. > - Allow *-change-functions notifications to be nested. > E.g. allow a C function to call > BEFORE 10 100 > BEFORE 20 30 > AFTER 20 25 10 > AFTER 10 90 90 > AFTER 10 60 80 > or something like that. This would require some way for the C code to > indicate which BEGIN corresponds to which AFTER. This could happen > for example by adding a "change-ID" to every notification, so we'd > get: > BEFORE nnn 10 100 > BEFORE mmm 20 30 > AFTER mmm 20 25 10 > AFTER nnn 10 90 90 > AFTER nnn 10 60 80 > I don't know how we could do that in a backward compatible way, and > I can't think of any `*-change-functions` which would benefit from > this nesting (all the ones I can think of would either ignore the > extra info or use the change-ID to distinguish inner notifications > from outer ones and then ignore the inner ones). > - Maybe the last point can be turned into an internal change with no > ELisp-side changes: use an approach like the one above but filter out > the inner changes directly in the C code. This would provide > to ELisp the same behavior that was brought by the fix to bug#78042, > but without resorting to the "hammer" of `inhibit-modification-hooks` > which risks silencing legitimate notifications. I don't think nested b/a-c-f are a good idea at all. It's one of these ideas that would introduce a very great deal of complexity for rather limited benefit. We would be paying a penalty in increased bug complexity for the forseeable future. before/after-change-functions functions SHOULDN'T themselves make changes to the buffer text (apart from text properties). I don't think it would be all that hard to instrument insdel.c to signal an error when such changes do get made, just tedious. Running such an instrumented Emacs on the test suite would catch a very great number of violations. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 10:46:13 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 14:46:13 +0000 Received: from localhost ([127.0.0.1]:42207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBE84-0003Ft-SE for submit@debbugs.gnu.org; Sat, 03 May 2025 10:46:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36050) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBE81-0003FT-8g for 78221@debbugs.gnu.org; Sat, 03 May 2025 10:46:10 -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 1uBE7u-0007EF-Mj; Sat, 03 May 2025 10:46:02 -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=YwSRiwueqOLu5XDF84d275XBH9XH3SkC70M+MEn27TE=; b=pIA2/cZC5nuOPF4daAaf N2Lg5X7+AO94Wc6mvh3wGs9I7ePS4BNJMp699c7qBUo8MXTCxSOQBi6WpPuNngJVm+3muypmhHpIM NIkuVghs+wd09y9XJqjy/HSg4Us7qSU0tbvjq7Yr++0yhwC4mOm+bTZqkJS0PPq5jsL39447qJ2zV bp6S3Wi0UFE+EdUalOkeek1Uai0Fsnz2vZKRHB3Tby8zkZlwcKYWFPm4SQ/0e5b9ySYGQOeTCpcD8 72Pg1Ot5Bfe56eFk2Pvk/vro6cjJGa1DT+KXf58AB8DQhEBSiQeRB/Sucv0/ax2P8rG3QKI2hqpwJ 3iWP9qv+P5zhxA==; Date: Sat, 03 May 2025 17:45:22 +0300 Message-Id: <86o6w9iwhp.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 3 May 2025 14:13:40 +0000) Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications References: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, yantar92@posteo.net, acm@muc.de, monnier@iro.umontreal.ca, joaotavora@gmail.com 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 (---) > Date: Sat, 3 May 2025 14:13:40 +0000 > Cc: 78221@debbugs.gnu.org, Eli Zaretskii , > João Távora , > Ihor Radchenko , acm@muc.de > From: Alan Mackenzie > > before/after-change-functions functions SHOULDN'T themselves make > changes to the buffer text (apart from text properties). That's not how nested notifications happen in most, if not all, the cases. They happen because a function that calls the before-change at the beginning and an after-change at the end calls, as part of its processing, some other function, which itself modifies buffer text or the text properties, and thus emits its own "nested" notifications. From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 10:46:56 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 14:46:56 +0000 Received: from localhost ([127.0.0.1]:42213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBE8l-0003HX-Pn for submit@debbugs.gnu.org; Sat, 03 May 2025 10:46:56 -0400 Received: from mail.muc.de ([193.149.48.3]:25295) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBE8i-0003HA-Ja for 78221@debbugs.gnu.org; Sat, 03 May 2025 10:46:53 -0400 Received: (qmail 78954 invoked by uid 3782); 3 May 2025 16:46:46 +0200 Received: from muc.de (p4fe15fdb.dip0.t-ipconnect.de [79.225.95.219]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 03 May 2025 16:46:45 +0200 Received: (qmail 21581 invoked by uid 1000); 3 May 2025 14:46:45 -0000 Date: Sat, 3 May 2025 14:46:45 +0000 To: Eli Zaretskii Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications Message-ID: References: <86cycqkwuu.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86cycqkwuu.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Ihor Radchenko , acm@muc.de, Stefan Monnier , =?iso-8859-1?Q?Jo=E3o_T=E1vora?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. Thanks for including me on the Cc: list. On Sat, May 03, 2025 at 09:54:33 +0300, Eli Zaretskii wrote: > > Cc: monnier@iro.umontreal.ca, Alan Mackenzie > > Date: Fri, 02 May 2025 17:48:11 -0400 > > From: Stefan Monnier via "Bug reports for GNU Emacs, > > the Swiss army knife of text editors" > > - Allow *-change-functions notifications to be nested. > > E.g. allow a C function to call > > BEFORE 10 100 > > BEFORE 20 30 > > AFTER 20 25 10 > > AFTER 10 90 90 > > AFTER 10 60 80 > > or something like that. This would require some way for the C code to > > indicate which BEGIN corresponds to which AFTER. This could happen > > for example by adding a "change-ID" to every notification, so we'd > > get: > > BEFORE nnn 10 100 > > BEFORE mmm 20 30 > > AFTER mmm 20 25 10 > > AFTER nnn 10 90 90 > > AFTER nnn 10 60 80 > > I don't know how we could do that in a backward compatible way, and > > I can't think of any `*-change-functions` which would benefit from > > this nesting (all the ones I can think of would either ignore the > > extra info or use the change-ID to distinguish inner notifications > > from outer ones and then ignore the inner ones). > > - Maybe the last point can be turned into an internal change with no > > ELisp-side changes: use an approach like the one above but filter out > > the inner changes directly in the C code. This would provide > > to ELisp the same behavior that was brought by the fix to bug#78042, > > but without resorting to the "hammer" of `inhibit-modification-hooks` > > which risks silencing legitimate notifications. > On the "nested notifications" part of this, I'd like to hear specific > problems with them. (I've added to the discussion people who might > have real-life examples of the problems.) Specifically, I'm not sure > I have a good understanding of why they are a problem in the first > place. Is it only because of the difficulty to pair BEFORE and AFTER > notifications? or is there something else? I think nested invocations of before/after-change functions would be a bad idea. It would be bound to increase complexity of bugs in this area in the future. It reminds me of one of my proposals from some years ago, to have a hook called when buffer narrowing changes. Richard advised me in no uncertain terms that this would have been just _too_ powerful, and would have enabled people to do things difficult to debug. I think nested b/a-c-functions would be similarly unwise. Yes, I've had specific problems in this area, in CC Mode. One difficult to solve bug involved the setting of font text properties triggering the change hooks spuriously (and slowing things down a lot). I can't remember it all that clearly. But solving it involved ensuring inhibit-modification-hooks was correctly set. > Due to the Emacs's highly-recursive workings and the various hooks we > have, which are ever-expanding, there's a virtually infinite number of > situations where some code, called while a buffer-change operation is > under way, itself calls a buffer-changing primitive, thus generating > nested notifications. Finding and fixing all of theses situations one > by one will take us infinite time, so I would like to consider more > practical alternatives. And for that, IMO we need a very good > understanding of the problems they cause. As I proposed in my reply to Stefan M., I don't think finding most/all of these situations need be too difficult. insdel.c could be temporarily instrumented to signal an error on detecting an illegitimate buffer change. The difficulty here might be false positives, when a program intends to make buffer changes from inside a change hook function. I don't think these are common, though. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 11:14:40 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 15:14:40 +0000 Received: from localhost ([127.0.0.1]:42360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBEZc-0004jM-1A for submit@debbugs.gnu.org; Sat, 03 May 2025 11:14:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9519) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBEZY-0004j6-TU for 78221@debbugs.gnu.org; Sat, 03 May 2025 11:14:38 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 031A780964; Sat, 3 May 2025 11:14:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746285269; bh=uB9H6rAJoC6wHTBYDa+FcO5YhJTxfKkpYggU9bT2490=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CXaKj5wKIkwOzNskgr/eGDwNRbSEgxe7xKcWafs9GLQJkgCDYc8xOyrHUZ5oD/5F/ z/E3cZhJPN9Ri249SDwR/TqdsdnsZuvTAJVUX149OjViEbvwFRSTq4e7w4mqYoxGG8 7/PHSkJ+XNH0GVBRdwk8M4ttUcot4i5gZvFWibbZ5M1N9RFUjc92TUuGxcjmMYPYft Mc7gY5F8glmG+g6ao2jTbOsfcQElpoXHhWWI2/aPgRhGHBKyGdQ06Zg7P9UTWYtoDY 2eZbX19JQjjCzlNQSgot93Fl+kRR4bZJYefOYu0PprEHXjC9WFtEFBS/ho+Wh4yDK/ aQGi7aa36Ra2g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BD01D80822; Sat, 3 May 2025 11:14:29 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 73A3E12039E; Sat, 3 May 2025 11:14:29 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: Message-ID: References: Date: Sat, 03 May 2025 11:14:28 -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.057 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: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , Ihor Radchenko , =?windows-1252?B?Sm/jbyBU4XZvcmE=?= 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 (---) >> Alan Mackenzie made significant improvements in the past to the C code >> that runs these hooks, so that we now rarely break our promises in terms >> of how/when those notifications are sent, but there are still >> cases lurking. > By "those promises", I think you mean being that we invoke > before-change-functions and after-change-functions strictly in matched > pairs. No, I mean the looser promise that AFTERs are allowed to touch only text within the region described by the last BEFORE. > On 2018-01-06, we formally agreed that these hooks will be invoked as > follows: > o - Every buffer changing primitive starts off with exactly one call > to b-c-f, > o - after which there will be zero, one, or several calls to a-c-f. > o - The b-c-f's region will enclose those of all the a-c-f regions, > but need not be the minimal such region. Exactly. And it's now documented in the manual. > I actually think a good strategy would be to invoke these hooks > strictly in matching pairs in all cases, but I'm sure I said that back > in 2018 too. =F0=9F=99=82 >> The main problem is that it's very hard to find the places where this >> occurs and it's not always obvious that the corresponding fix is >> harmless. A fix is likely to involve changes visible to the Elisp side, >> such as new hooks, so it seemed out of scope for bug#78042. > > I don't think it's all that hard. In 2020, I made a list of which > non-static functions in insdel.c call before/after-change-functions. > The list, which is likely still valid, or very nearly so, looked like > this: > > insert B/A > insert_and_inherit B/A > insert_char B/A > insert_string B/A > insert_before_markers B/A > > insert_before_markers_and_inherit B/A > insert_1_both ?/- > insert_from_string B/A > insert_from_string_before_markers B/A > insert_from_gap_1 -/- > > insert_from_gap -/- > insert_from_buffer B/A > del_range B/A > del_range_1 ?/A > del_range_byte B/A > > del_range_both ?/A > del_range_2 -/- > replace_range ?/A > replace_range_2 -/- > modify_text B/- Thanks, that's very helpful. [ It lacks the ones coming from text-property modifications. ] The ones above that are neither B/A nor -/- are the reason why making changes in this area is ... delicate. > But if an alternative is to allow nested calls to the hooks (something > we don't allow at the moment, even though the rule isn't explicitly > formulated anywhere), The rule is implicitly formulated where we document that AFTERs can't touch text outside of the last BEFORE. > I think it was a mistake in the beginning to have text property > modifications trigger before/after-c-f. Agreed. > But seeing it's been that way for so long, I don't think it would be > a good idea to change it now. FWIW, I'm now running my Emacs with such a change to see if the ELisp code I use cares. But yeah, it seems too risky to do it without providing some backward compatibility. > before/after-change-functions functions SHOULDN'T themselves make > changes to the buffer text (apart from text properties). +1 > I don't think it would be all that hard to instrument insdel.c to > signal an error when such changes do get made, just tedious. > Running such an instrumented Emacs on the test suite would catch > a very great number of violations. It might be worthwhile adding such runtime tests and emit warnings when before/after-change-functions make changes the buffer text, tho it's orthogonal to what we're discussing here (where the nesting is not due to ill-behaved before/after-change-functions but come straight from the C code). > As I proposed in my reply to Stefan M., I don't think finding most/all of > these situations need be too difficult. insdel.c could be temporarily > instrumented to signal an error on detecting an illegitimate buffer > change. The difficulty here might be false positives, when a program > intends to make buffer changes from inside a change hook function. I > don't think these are common, though. I'm running my Emacs sessions with a function added globally to before/after-change-functions, which checks that we stick to our promises (basically the `sanity-check-change-functions-*` code in `test/src/editfns-tests.el`). But that catches only those occurrences that are triggered by my usage patterns. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 11:15:36 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 15:15:36 +0000 Received: from localhost ([127.0.0.1]:42368 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBEaW-0004rE-AG for submit@debbugs.gnu.org; Sat, 03 May 2025 11:15:36 -0400 Received: from mail.muc.de ([193.149.48.3]:25083) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBEaS-0004qr-Mo for 78221@debbugs.gnu.org; Sat, 03 May 2025 11:15:33 -0400 Received: (qmail 13571 invoked by uid 3782); 3 May 2025 17:15:25 +0200 Received: from muc.de (p4fe15fdb.dip0.t-ipconnect.de [79.225.95.219]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 03 May 2025 17:15:25 +0200 Received: (qmail 22188 invoked by uid 1000); 3 May 2025 15:15:24 -0000 Date: Sat, 3 May 2025 15:15:24 +0000 To: Eli Zaretskii Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications Message-ID: References: <86o6w9iwhp.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86o6w9iwhp.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, yantar92@posteo.net, monnier@iro.umontreal.ca, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Sat, May 03, 2025 at 17:45:22 +0300, Eli Zaretskii wrote: > > Date: Sat, 3 May 2025 14:13:40 +0000 > > Cc: 78221@debbugs.gnu.org, Eli Zaretskii , > > João Távora , > > Ihor Radchenko , acm@muc.de > > From: Alan Mackenzie > > before/after-change-functions functions SHOULDN'T themselves make > > changes to the buffer text (apart from text properties). > That's not how nested notifications happen in most, if not all, the > cases. They happen because a function that calls the before-change at > the beginning and an after-change at the end calls, as part of its > processing, some other function, which itself modifies buffer text or > the text properties, and thus emits its own "nested" notifications. OK. Most Lisp code shouldn't be running the hook explicitly, though. I think the Elisp manual might even say this. But such calls are rare. On running $ find . -name '*.el' | xargs grep -n '\(before\|after\)-change-functions' | grep run-hook on master, I only got the following matches: ../lisp/progmodes/verilog-mode.el:3558: (run-hook-with-args 'before-change-functions (point-min) (point-max)) ../lisp/progmodes/verilog-mode.el:3570: (run-hook-with-args 'after-change-functions (point-min) (point-max) ../lisp/cedet/srecode/insert.el:132: (run-hook-with-args 'after-change-functions ../lisp/subr.el:5414: (run-hook-with-args 'before-change-functions beg end)) ../lisp/subr.el:5471: (run-hook-with-args 'after-change-functions ../lisp/emulation/viper-cmd.el:139: (run-hook-with-args 'viper-after-change-functions beg end len)) ../lisp/emulation/viper-cmd.el:143: (run-hook-with-args 'viper-before-change-functions beg end)) ../lisp/format.el:472: (run-hook-with-args 'after-change-functions (point) (+ (point) size) 0)) ../test/lisp/emacs-lisp/track-changes-tests.el:141: (run-hook-with-args 'after-change-functions ../test/lisp/emacs-lisp/track-changes-tests.el:143: (run-hook-with-args 'before-change-functions beg end)))) (plus one wrong match). The invocations in subr.el are legitimate. The others are few enough to be examined and fixed. Of course there may be such occurrences in users' code. Maybe we could emit a compile time warning for such things. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 11:52:24 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 15:52:24 +0000 Received: from localhost ([127.0.0.1]:42589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBFA7-0006sZ-UJ for submit@debbugs.gnu.org; Sat, 03 May 2025 11:52:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44716) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBFA3-0006s9-Us for 78221@debbugs.gnu.org; Sat, 03 May 2025 11:52: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 1uBF9x-0004ZM-OD; Sat, 03 May 2025 11:52:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qzoSBNWTXXAlDztuw7qcZ9az9OiRnJDbRXmxilEWEHA=; b=HxvoAKfvfjUn ylckKZI9JSFdCDRYF2Feyi3QVYeyMnQ3zosHWy8694pgGCQFoWLTW43cdI0laH77itXaL/7YcUzTQ NLaoOBlShyozWbBtblowHzdyCF7h+Yv1qlgjs3MSP3C7XsIK8axHfNs6rfnxTMrpTOOhOe9qT05FE xbgWYvCKG001T6FbG1tNOBQnH6lSjF2HOFkQ40H3BGpR+kFDZdXFNr/HYTk8Z1NwArSe+E/rnPnP/ Tyf58C3Q2KEgBoQKTlE6aKemy73iNCZttJaqZDeDzx2LK+zHW1qevww3QIJFdnc5CBheku5LeaBQn kM1oSkLOkV6VZ/TFXoKVGA==; Date: Sat, 03 May 2025 18:52:11 +0300 Message-Id: <86ldrditec.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 3 May 2025 15:15:24 +0000) Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications References: <86o6w9iwhp.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, yantar92@posteo.net, monnier@iro.umontreal.ca, joaotavora@gmail.com 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 (---) > Date: Sat, 3 May 2025 15:15:24 +0000 > Cc: monnier@iro.umontreal.ca, 78221@debbugs.gnu.org, joaotavora@gmail.com, > yantar92@posteo.net > From: Alan Mackenzie > > > That's not how nested notifications happen in most, if not all, the > > cases. They happen because a function that calls the before-change at > > the beginning and an after-change at the end calls, as part of its > > processing, some other function, which itself modifies buffer text or > > the text properties, and thus emits its own "nested" notifications. > > OK. Most Lisp code shouldn't be running the hook explicitly, > though. No, but the C code does. And it's very easy to imagine a situation where one such primitive is invoked in the middle of another. A case in point is coding.c, where Stefan eliminated such a "nesting" just a few hours ago (by a change that we have yet to see if it's safe). With all the hooks we provide, such situations can emerge very easily. From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 12:35:29 2025 Received: (at submit) by debbugs.gnu.org; 3 May 2025 16:35:29 +0000 Received: from localhost ([127.0.0.1]:42855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBFpo-0000vF-NH for submit@debbugs.gnu.org; Sat, 03 May 2025 12:35:29 -0400 Received: from lists.gnu.org ([2001:470:142::17]:33214) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBFpl-0000ur-CF for submit@debbugs.gnu.org; Sat, 03 May 2025 12:35:25 -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 1uBFpf-0003Fq-7Y for bug-gnu-emacs@gnu.org; Sat, 03 May 2025 12:35:20 -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 1uBFpa-00085W-NC for bug-gnu-emacs@gnu.org; Sat, 03 May 2025 12:35:18 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D7B9F240101 for ; Sat, 3 May 2025 18:35:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1746290111; bh=wVuZLnGAPtnEC4ghYRRdsfZgInj99VNHkscVsYs35VY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=TZwfRKaYjsxNuCUWPNhnhx8TdWyf23GoQpZRTZBpoxczhkRzGg1fCD00fDqurjj7a PsgREJicW50As54IUB7BVgew/neT6fOtqqh4OKsezSi+bb+0kSwXdzjQJSQ8efjNTl YZ6QHm7oRX2hknje3vpPFFrCW9fV6EbSe0OiA4/M5y3AWy0X1x/tXvLUjux1AsZTUD y29qDKLuC2lNdTPzF9mx9OCPiFpz5BFtFRSx2sOvwoz55vCSC6RKq+CrL8RXM6jSM6 KRPuBCC/dzTITwKbIcjnlhXg7PA6prHVX7SKQaw1IW0W6CCpdQp6Oo8Y5U24exjikA lvE1aTmddW2Xg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZqYL70Lwnz9rxD; Sat, 3 May 2025 18:35:10 +0200 (CEST) From: Ihor Radchenko To: "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: References: Date: Sat, 03 May 2025 16:34:12 +0000 Message-ID: <87h621fybf.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=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 Cc: 78221@debbugs.gnu.org, monnier@iro.umontreal.ca, Alan Mackenzie 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 (/) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Or we could rely on a (symbol) property being set on the functions > added to `*-change-functions` to tell whether they want to know about > changes to text-properties or not. > Or maybe a more crude way would be a buffer-local variable controlling > whether `*-change-functions` are called for text-property changes. Or pass a 4th parameter to *-change-functions indicating whether the change involved actual text edits or it only touched text-properties. Org mode currently has to resort to (eq org-fold-core--last-buffer-chars-modified-tick (buffer-chars-modified-tick)) checks to filter out changes in text properties. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 12:45:31 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 16:45:31 +0000 Received: from localhost ([127.0.0.1]:42904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBFzW-0001Rj-P1 for submit@debbugs.gnu.org; Sat, 03 May 2025 12:45:31 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58305) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBFzS-0001RO-5c for 78221@debbugs.gnu.org; Sat, 03 May 2025 12:45:27 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0193E80964; Sat, 3 May 2025 12:45:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746290719; bh=5l+1tHO6cNPt+JWUUoBEkHiBmDN+QY8lMmEuV4quqcQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lmytEQKDmJQ3ndxzNmSNIX247sAus5JkEemHAwwfGDfGS48QyAsUGrmmGDAh3ycot Vm05ieBCnvmh8VsWIbxbh/YJ8MvHHXyiN4wpw7pICi+MtX7H0f7jTWnNggsHbbnbwA FkQsyM4vPYsklsMQp50Y97ivV0yrVE2dyIHZ6ANxZOuIJwmkfbj4Oiyp1uCMTuxjAj aYnQ6m7zezfv4Nir7O6Nn8gmGPE4OMrc7gknqbh44w4umygIVFlMG/iOK260WUjh8H v1YjSE5TK1EZn3dAzuUV4qqxobTS4Km+7f0sUuOWhUlsslvEpEJuJs71JliKW8kpZ5 KjnuzMMyjASbA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1316580822; Sat, 3 May 2025 12:45:19 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C6417120497; Sat, 3 May 2025 12:45:18 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: Message-ID: References: <86o6w9iwhp.fsf@gnu.org> Date: Sat, 03 May 2025 12:45:18 -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.057 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: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , yantar92@posteo.net, joaotavora@gmail.com 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 (---) > ../lisp/progmodes/verilog-mode.el:3558: (run-hook-with-args > 'before-change-functions (point-min) (point-max)) > ../lisp/progmodes/verilog-mode.el:3570: (run-hook-with-args > 'after-change-functions (point-min) (point-max) I think these are OK. It's doing something similar to `combine*change-functions`. > ../lisp/cedet/srecode/insert.el:132: (run-hook-with-args 'after-change-functions This one looks quite wrong. > ../lisp/subr.el:5414: (run-hook-with-args 'before-change-functions beg end)) > ../lisp/subr.el:5471: (run-hook-with-args 'after-change-functions These are for `combine*change-functions`. > ../lisp/emulation/viper-cmd.el:139: (run-hook-with-args 'viper-after-change-functions beg end len)) > ../lisp/emulation/viper-cmd.el:143: (run-hook-with-args 'viper-before-change-functions beg end)) False positives. > ../lisp/format.el:472: (run-hook-with-args 'after-change-functions (point) (+ (point) size) 0)) Looks wrong as well. > ../test/lisp/emacs-lisp/track-changes-tests.el:141: > (run-hook-with-args 'after-change-functions > ../test/lisp/emacs-lisp/track-changes-tests.el:143: > (run-hook-with-args 'before-change-functions beg end)))) These are purposefully wrong (to check that `track-changes` is able to withstand such occurrences). Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 13:04:05 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 17:04:05 +0000 Received: from localhost ([127.0.0.1]:42971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBGHR-0002Nl-K2 for submit@debbugs.gnu.org; Sat, 03 May 2025 13:04:05 -0400 Received: from mail.muc.de ([193.149.48.3]:47705) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBGHN-0002NF-TL for 78221@debbugs.gnu.org; Sat, 03 May 2025 13:03:59 -0400 Received: (qmail 42703 invoked by uid 3782); 3 May 2025 19:03:51 +0200 Received: from muc.de (p4fe15fdb.dip0.t-ipconnect.de [79.225.95.219]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 03 May 2025 19:03:51 +0200 Received: (qmail 23810 invoked by uid 1000); 3 May 2025 17:03:49 -0000 Date: Sat, 3 May 2025 17:03:49 +0000 To: Eli Zaretskii Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications Message-ID: References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ldrditec.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, yantar92@posteo.net, acm@muc.de, monnier@iro.umontreal.ca, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Sat, May 03, 2025 at 18:52:11 +0300, Eli Zaretskii wrote: > > Date: Sat, 3 May 2025 15:15:24 +0000 > > Cc: monnier@iro.umontreal.ca, 78221@debbugs.gnu.org, joaotavora@gmail.com, > > yantar92@posteo.net > > From: Alan Mackenzie > > > That's not how nested notifications happen in most, if not all, the > > > cases. They happen because a function that calls the before-change at > > > the beginning and an after-change at the end calls, as part of its > > > processing, some other function, which itself modifies buffer text or > > > the text properties, and thus emits its own "nested" notifications. > > OK. Most Lisp code shouldn't be running the hook explicitly, > > though. > No, but the C code does. And it's very easy to imagine a situation > where one such primitive is invoked in the middle of another. A case > in point is coding.c, where Stefan eliminated such a "nesting" just a > few hours ago (by a change that we have yet to see if it's safe). > With all the hooks we provide, such situations can emerge very easily. The right tool to find these is cflow, combined with grep and awk (or python or perl or whatever) to search and filter cflow's output. I've used these before. As you say, checking fixes to these bugs are safe is less mechanical. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 15:23:12 2025 Received: (at 78221) by debbugs.gnu.org; 3 May 2025 19:23:12 +0000 Received: from localhost ([127.0.0.1]:43521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBIS8-0001J4-7v for submit@debbugs.gnu.org; Sat, 03 May 2025 15:23:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38654) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBIS4-0001Ig-6N for 78221@debbugs.gnu.org; Sat, 03 May 2025 15:23:09 -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 1uBIRv-0004Oe-F6; Sat, 03 May 2025 15:22:59 -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=X1os8tGqwK0wIVowNDKcsoR68M3T3vq0+6kQRO9F6fU=; b=qsn0WXiZ7OzY SwOi3IRSbFfMVSrAPKUzcpl95ad3YbAHxBAJBjNLbUxA4POBea3WsS/Z3tmjX/C9G6l7DPt+BXIVZ 4OkYcEb5fWmum1RVKv+oCeb9o5U8JpYuSOV9DaXLcYLn9UijfrFy3pSEGiHmxaT4B+Bs2R4O1I3a0 hiJMznxG1KDNl55lr/8IQNLbmkrQ0O+LqDIfMtrvE9eOGtrMsChSXPheCyRFDREpY9XFWAseXn+xV c+bHnU+/kiQi+iU89eTAFmf7K7Kjxp1ldku+Nu4BE52g5OaZezA0rWr6cfkjE4CQhbvP89vlKhRsb qWDwBGkjTtzfXaMOhZYRRg==; Date: Sat, 03 May 2025 22:22:56 +0300 Message-Id: <86jz6xijn3.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 3 May 2025 17:03:49 +0000) Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, yantar92@posteo.net, acm@muc.de, monnier@iro.umontreal.ca, joaotavora@gmail.com 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 (---) > Date: Sat, 3 May 2025 17:03:49 +0000 > Cc: monnier@iro.umontreal.ca, 78221@debbugs.gnu.org, joaotavora@gmail.com, > yantar92@posteo.net, acm@muc.de > From: Alan Mackenzie > > Hello, Eli. > > On Sat, May 03, 2025 at 18:52:11 +0300, Eli Zaretskii wrote: > > > Date: Sat, 3 May 2025 15:15:24 +0000 > > > Cc: monnier@iro.umontreal.ca, 78221@debbugs.gnu.org, joaotavora@gmail.com, > > > yantar92@posteo.net > > > From: Alan Mackenzie > > > > > That's not how nested notifications happen in most, if not all, the > > > > cases. They happen because a function that calls the before-change at > > > > the beginning and an after-change at the end calls, as part of its > > > > processing, some other function, which itself modifies buffer text or > > > > the text properties, and thus emits its own "nested" notifications. > > > > OK. Most Lisp code shouldn't be running the hook explicitly, > > > though. > > > No, but the C code does. And it's very easy to imagine a situation > > where one such primitive is invoked in the middle of another. A case > > in point is coding.c, where Stefan eliminated such a "nesting" just a > > few hours ago (by a change that we have yet to see if it's safe). > > With all the hooks we provide, such situations can emerge very easily. > > The right tool to find these is cflow, combined with grep and awk (or > python or perl or whatever) to search and filter cflow's output. I've > used these before. > > As you say, checking fixes to these bugs are safe is less mechanical. I'm not sure I even have a good idea regarding what are the safe fixes for those cases. From debbugs-submit-bounces@debbugs.gnu.org Sat May 03 22:48:25 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 02:48:26 +0000 Received: from localhost ([127.0.0.1]:46878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBPOz-00013K-BA for submit@debbugs.gnu.org; Sat, 03 May 2025 22:48:25 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32553) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBPOt-00011V-91 for 78221@debbugs.gnu.org; Sat, 03 May 2025 22:48:22 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 948D680822; Sat, 3 May 2025 22:48:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746326891; bh=P1gA5RpXeoYcHPYi9qQ8Sdfb62gKDR1+qU8tP3PFPPg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=b+SESGF5je9erzTC6WDbA2c2dBxunopZtrTLlB88c9OP3S02u5eNDs2UhR3dXkqcB c2WQvdlSe5GiOD1mo17p528hjmN3K1N/IYz1kuRNYfFmF9dP+EWYCwBAV4pfrSjKON BqDIrm2kNqW6bPNH6M9kKxWrkpTcocfn1Qi6wRoHDAUzPCsIOBU9/cwL16KUsrv04g 4XK4CJp1vHWMvlqjTnFDwcGJ9aaUChzUZAWdK1AnxJMS109eYJDh/1reLbrvqrw2HF wOFHHRqb/e9oo2uUT5nxsZnBu1ClxA7Co+mMvgMhpvEwPAYMvYwF0vUxoDhdHhylYP gJxNzUjMcW1Og== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AA7BF8034A; Sat, 3 May 2025 22:48:11 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6A6EA12033B; Sat, 3 May 2025 22:48:11 -0400 (EDT) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: <87h621fybf.fsf@localhost> Message-ID: References: <87h621fybf.fsf@localhost> Date: Sat, 03 May 2025 22:48:10 -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.057 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: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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 (---) >> Or we could rely on a (symbol) property being set on the functions >> added to `*-change-functions` to tell whether they want to know about >> changes to text-properties or not. >> Or maybe a more crude way would be a buffer-local variable controlling >> whether `*-change-functions` are called for text-property changes. > Or pass a 4th parameter to *-change-functions indicating whether the > change involved actual text edits or it only touched text-properties. But many functions used on this hook don't accept 4 parameters, so that's not backward compatible. [ FWIW: In my local Emacs, I used another incompatible approach which is to pass `t` for the `oldlen` argument, since text-property changes don't change the length. It seems not to cause too much trouble: most hooks don't pay attention to `oldlen` and most text-property changes are wrapped in `inhibit-modification-hooks`, but I did have to tweak the code at a few spots. ] > Org mode currently has to resort to (eq > org-fold-core--last-buffer-chars-modified-tick > (buffer-chars-modified-tick)) checks to filter out changes in > text properties. Interesting. What made you do that? IME, it's fairly rare for text-property changes to trigger such notifications. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 01:31:30 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 05:31:30 +0000 Received: from localhost ([127.0.0.1]:48885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBRwn-000672-QN for submit@debbugs.gnu.org; Sun, 04 May 2025 01:31:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44416) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBRwj-00066R-GX for 78221@debbugs.gnu.org; Sun, 04 May 2025 01:31: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 1uBRwd-0004ue-BM; Sun, 04 May 2025 01:31:19 -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=m3TI6DIZIx4l6BHo1/g2XYwLOc/CjN58OSyqMwC6MCI=; b=fXbm7yE9qrlO hE4Ulx495G7OAs7cxbXQvwy9JhCzgGRqeljkbFT8EU2BlEiQesK6gmkK3VNpjheywiaurxGMLbKQR qu8b0aqjdDRt49cfaZ9iVlKpeUCja0KAiCIVGLP5JHJepCjuzF1rG/xqS24eICoekVoP3Ei8CT01M cuBdpxtvsJaCL8JUSBEiEJwhMLL6Jd9Py8MXqdE3Xs0SHvCpGzJ61NTCS48EW/8T1+/PhbnllfZQm nCt7Re208kUU0hXjFrnlU2mtSS7TriLqAohnt+/8KC7UNFFG2apR+EoJPD8DIXIy2kxdJO1DCxOg/ dhruDGCDcbwY6SpMQK1bZQ==; Date: Sun, 04 May 2025 08:31:15 +0300 Message-Id: <86bjs9hrh8.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications References: <87h621fybf.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, yantar92@posteo.net, acm@muc.de 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: 78221@debbugs.gnu.org, Alan Mackenzie > Date: Sat, 03 May 2025 22:48:10 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > >> Or we could rely on a (symbol) property being set on the functions > >> added to `*-change-functions` to tell whether they want to know about > >> changes to text-properties or not. > >> Or maybe a more crude way would be a buffer-local variable controlling > >> whether `*-change-functions` are called for text-property changes. > > Or pass a 4th parameter to *-change-functions indicating whether the > > change involved actual text edits or it only touched text-properties. > > But many functions used on this hook don't accept 4 parameters, so > that's not backward compatible. We could use func-arity, couldn't we? From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 02:16:21 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 06:16:22 +0000 Received: from localhost ([127.0.0.1]:49527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBSeB-0003n3-88 for submit@debbugs.gnu.org; Sun, 04 May 2025 02:16:21 -0400 Received: from mout01.posteo.de ([185.67.36.65]:42489) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBSe3-0003l2-96 for 78221@debbugs.gnu.org; Sun, 04 May 2025 02:16:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id BDC03240027 for <78221@debbugs.gnu.org>; Sun, 4 May 2025 08:16:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1746339362; bh=AXTwfjQ3GxyDsoRxkFRZ++P9q3Q9XYn1VBS2nCDehGs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=fGI8iASYBoV5fIZCIh8Lx9vKtNSdgJ1jYyOntSrq/EhAuYaZcWXaenQraQNo44XyB FL+QxeAyYusQbhFaHdy53AUNZUD1aP0Z+jFVxeIeu2qEg3Wpm8lpYTJbuvN/lRnL/0 Del01G19m089BD8mszDVQ+4ADJiF2dZoVB064rrRYzcV4XoEzw9Iuv7C3v4Rb5H8BK 4AM39w75FNOD8Rnm3z+XUVOegZNbirmnYjBA7IAy65V4sIomYSU2t/hitfJA4oyajN s+x/OL01nbvXDdPn9xUSee2cykjfQSmi/vmIcP2e1Qy6f1Gru3KdkYLndBPmGRknEr YgyutB6Nod6yQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZqvYF6ssnz9rxD; Sun, 4 May 2025 08:16:01 +0200 (CEST) From: Ihor Radchenko To: Stefan Monnier Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: References: <87h621fybf.fsf@localhost> Date: Sun, 04 May 2025 06:15:03 +0000 Message-ID: <87o6w8j40o.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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: >> Org mode currently has to resort to (eq >> org-fold-core--last-buffer-chars-modified-tick >> (buffer-chars-modified-tick)) checks to filter out changes in >> text properties. > > Interesting. What made you do that? IME, it's fairly rare for > text-property changes to trigger such notifications. Some parts of Org mode (org-agenda, org-sparse-tree) use text properties and trigger the notifications; usually that happens across the whole buffer. And when that does happen, expensive processing of buffer changes makes things very slow. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 09:01:52 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 13:01:52 +0000 Received: from localhost ([127.0.0.1]:54465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBYye-000811-0q for submit@debbugs.gnu.org; Sun, 04 May 2025 09:01:52 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14447) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBYya-0007zr-LS for 78221@debbugs.gnu.org; Sun, 04 May 2025 09:01:49 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D13CA10006B; Sun, 4 May 2025 09:01:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746363697; bh=vpi5ou5xxwtJvt8XviXB1YkgTmgalVjOgSa8T782ono=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fxESMzl3spAqvB0dUbXNKMyajxDs57GJrzSuhO/XdZhrWxMgoNL9h/D9Hmm2yaWTl xBDE8GIoNGJKosC4C7PIsWwpsWuFleVrggKGCVJkPt3D3fmLdOT+EMrrRB0O73XUW4 WhwGeI/JDG+9a+cVrJ3x6KH6RA22WiTFDijE71GoaLdPSHrN0F54g0NaM7mQ15yKKK /2uxV65BiDvPIaXeszprjFZQFWufjDQQmj83Dob0MG2JQl8rM9GHub5oDQ+TstB+T6 YdjRhuAxuANzueBnFCIigfVDpO+d+D64AF3oS9HnrYnMKXv8DYC1g4pYg7sSLZeFlT lq34ERdY08DYw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C543710002E; Sun, 4 May 2025 09:01:37 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 58C511200BA; Sun, 4 May 2025 09:01:37 -0400 (EDT) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: <87o6w8j40o.fsf@localhost> Message-ID: References: <87h621fybf.fsf@localhost> <87o6w8j40o.fsf@localhost> Date: Sun, 04 May 2025 09:01:35 -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.232 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: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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 (---) >>> Org mode currently has to resort to (eq >>> org-fold-core--last-buffer-chars-modified-tick >>> (buffer-chars-modified-tick)) checks to filter out changes in >>> text properties. >> Interesting. What made you do that? IME, it's fairly rare for >> text-property changes to trigger such notifications. > Some parts of Org mode (org-agenda, org-sparse-tree) use text properties > and trigger the notifications; usually that happens across the whole > buffer. And when that does happen, expensive processing of buffer > changes makes things very slow. I see. But then, why fix it on the side of your `*-change-functions` rather than on using `inhibit-modification-hooks` (so it benefits all the `*-change-functions`)? IME, most ELisp code which calls things like `put-text-property` usually does so within a `with-silent-modifications` wrapper, and not only to avoid running `*-change-functions`: also to avoid setting the `buffer-modified-p` flag or getting prompted if some other session is modifying the same file at the same time, etc... Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 09:09:21 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 13:09:21 +0000 Received: from localhost ([127.0.0.1]:54577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBZ5r-0000YX-O0 for submit@debbugs.gnu.org; Sun, 04 May 2025 09:09:21 -0400 Received: from mout01.posteo.de ([185.67.36.65]:49335) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBZ5k-0000Wd-UD for 78221@debbugs.gnu.org; Sun, 04 May 2025 09:09:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id D2828240027 for <78221@debbugs.gnu.org>; Sun, 4 May 2025 15:09:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1746364144; bh=RbTf0QsOg/ndjlWJSPJj60au3Kg4tPd5EfEQJT33NA0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=X8bbXeYGJ3st+7C8RDd5CB9bQu0I/jNasOWbhegNGccnNDC058fChLvlDP4erndEX cNH2dQ79QseG23pooX4WKBN8nYBmdz9lqRko/VrZ1ZX+z23xzMAaz2CwInm/0Nv/Rx 21DZDTq/hO/7XXHEooMDoGn370av+rKCgsn/KHD5ejJEUW1BXDDlpqCKK4wga8HWYj MX5vaodtbqtn8dKQ/Ay5G80CIEvWS9Y5w7ReRabvKofVssuD3sr1uOevjHytOmSxfY 7Atvx4ATxxSZgiwybLrtc8QGohiLNr8H2IQrD5uBc8kGTGoRMTKltOCnRfFqpkrkf+ pHngiYp5n/4BQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Zr4jr1g2Wz6tvm; Sun, 4 May 2025 15:09:03 +0200 (CEST) From: Ihor Radchenko To: Stefan Monnier Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: References: <87h621fybf.fsf@localhost> <87o6w8j40o.fsf@localhost> Date: Sun, 04 May 2025 13:08:05 +0000 Message-ID: <874iy0h6bu.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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: > I see. But then, why fix it on the side of your `*-change-functions` > rather than on using `inhibit-modification-hooks` (so it benefits all > the `*-change-functions`)? Because I cannot ignore possibility that some third-party config is making use of *-change-functions to detect Org putting properties. Also, I cannot guarantee that all third-party packages do not use put-text-property outside inhibit-modification-hooks. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 09:43:38 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 13:43:38 +0000 Received: from localhost ([127.0.0.1]:54962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBZd3-0005EH-2U for submit@debbugs.gnu.org; Sun, 04 May 2025 09:43:37 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8103) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBZcy-0005Dj-42 for 78221@debbugs.gnu.org; Sun, 04 May 2025 09:43:34 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5EEE4440A0E; Sun, 4 May 2025 09:43:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746366204; bh=5cswEVhwHU975z7YEooDkUHVKbIix2Knn9RisgjTmT8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OGZpoITBoVJy3OUzqBsRvwUZGT0aCKIXh/C7afCPrJk3aM1YcNUq2o0uL8KLz6I+e Hlw3Ttw/wUBnvJHd009+jG2bAtPIVboNo42wLSx9vfSKybCF7Y7ejnbD3tjGsdfEuE yyoJBI8vC4HQ3oVuqWYxPH6S83bpbYkubtkiEbliUy+GL5/B+g+TlzTADOwWjT2loM KyndSW484XKL8MR0pA1sjs/vctbyxJK2PTVE50e6ZgbOdEo+b2GBD2SkRjwaJyD0TQ MQuad9Udfww285shV/YIbG2y3l9zqBfxDSWZVcNz03Q/vPbODs92VngM0GUlfbZHpC uUoh1m2k2Os8g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2701E440689; Sun, 4 May 2025 09:43:24 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E1C44120484; Sun, 4 May 2025 09:43:23 -0400 (EDT) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: <874iy0h6bu.fsf@localhost> Message-ID: References: <87h621fybf.fsf@localhost> <87o6w8j40o.fsf@localhost> <874iy0h6bu.fsf@localhost> Date: Sun, 04 May 2025 09:43:18 -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.045 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: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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 (---) Ihor Radchenko [2025-05-04 13:08:05] wrote: > Stefan Monnier writes: >> I see. But then, why fix it on the side of your `*-change-functions` >> rather than on using `inhibit-modification-hooks` (so it benefits all >> the `*-change-functions`)? > Because I cannot ignore possibility that some third-party config is > making use of *-change-functions to detect Org putting properties. Ah, so the same reason why we're also resisting the urge to just just stop running those hooks for changes to text-properties. I wonder if someone actually knows of a `*-change-function` which wants to be triggered when text-properties are modified. I'm not 100% sure that I've never seen such a thing, but at least I can't remember seeing (nor writing) such a thing. Are these property-modifications spread all over the place or can you point us to a few important places where they happen? I'm curious to know as well how those deal with other related "usually undesired" effects, such as modifying the `buffer-modified-p` flag, stashing the property modifications into the `buffer-undo-list`, or signaling errors when the buffer is read-only. > Also, I cannot guarantee that all third-party packages do not use > put-text-property outside inhibit-modification-hooks. =F0=9F=99=82 Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 11:27:39 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 15:27:39 +0000 Received: from localhost ([127.0.0.1]:57504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBbFi-00026t-Kc for submit@debbugs.gnu.org; Sun, 04 May 2025 11:27:38 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63946) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBbFf-00026a-03 for 78221@debbugs.gnu.org; Sun, 04 May 2025 11:27:35 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5454B801CC; Sun, 4 May 2025 11:27:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746372444; bh=WNYju44LijPtArRe+7yIUXCIIXhtA8HJZHrh1LUEUyc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mQDw+cB8PhjXjYZEinh/CrHq+wIrPjFIL2tYu9trf1sa3jhal7sDJwGmmLy0AmOeh ZUZpjtUzM8ojyNf2Gc3vR8lwG+nsAxVSy+7rMXx752hDjaD7JuoCbs89o9M0AJYBj9 v6LZ3aXkA4Q0Y4RYcssRGO4321uKn2l4AlDQ8fKCz9TRAVeEDLyOO1AhcvPz5XIX4R jk3r3soqNCA7ccfGnraaLqgBIfHs/++DDMHvcZNdA0+CY2M0WPa0UZZqSUCfDqij2N BjfpYdOmmQxZ2urV45XlHvfcIQmUR27J6JaVvVoLy2+4YwhU5wuF+BmJ5gVfNzoa2k prra1xhw5dBQQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2734580891; Sun, 4 May 2025 11:27:24 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CC1B0120262; Sun, 4 May 2025 11:27:23 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: Message-ID: References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> Date: Sun, 04 May 2025 11:27:23 -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.064 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: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , yantar92@posteo.net, joaotavora@gmail.com 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 (---) > The right tool to find these is cflow, combined with grep and awk (or > python or perl or whatever) to search and filter cflow's output. I've > used these before. Do you happen to remember the magic incantation to let `cflow` process our sources correctly? I tried the rule below and the errors file suggests that the preprocessing is done correctly (it's full of complaints but only about redefinitions), yet the result doesn't include any info about the functions called by `insert_1_both` or `Fput_text_property` (to take two randomly sampled cases of interest). Stefan diff --git a/src/Makefile.in b/src/Makefile.in index e4fc2fef711..2c7aa92f9b9 100644 --- a/src/Makefile.in +++ b/src/Makefile.in @@ -699,6 +699,18 @@ MAKE_PDUMPER_FINGERPRINT = MAKE_PDUMPER_FINGERPRINT = endif +cgraph.cflow: + cflow --all --brief --cpp='$(CC) -E $(ALL_CFLAGS)' \ + $(ALLOBJS:.o=.c) \ + >$@ 2>$@.errors + +cgraph-rev.cflow: + cflow --reverse --all --brief --cpp='$(CC) -E $(ALL_CFLAGS)' \ + $(ALLOBJS:.o=.c) \ + >$@ 2>$@.errors + +flowcharts: cgraph-rev.cflow cgraph.cflow + ## We have to create $(etc) here because init_cmdargs tests its ## existence when setting Vinstallation_directory (FIXME?). ## This goes on to affect various things, and the emacs binary fails From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 13:05:41 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 17:05:41 +0000 Received: from localhost ([127.0.0.1]:58654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBcmb-0006zQ-AC for submit@debbugs.gnu.org; Sun, 04 May 2025 13:05:41 -0400 Received: from mail.muc.de ([193.149.48.3]:18611) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBcmW-0006xf-SY for 78221@debbugs.gnu.org; Sun, 04 May 2025 13:05:39 -0400 Received: (qmail 83567 invoked by uid 3782); 4 May 2025 19:05:30 +0200 Received: from muc.de (p4fe1596e.dip0.t-ipconnect.de [79.225.89.110]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 04 May 2025 19:05:30 +0200 Received: (qmail 31640 invoked by uid 1000); 4 May 2025 17:05:29 -0000 Date: Sun, 4 May 2025 17:05:29 +0000 To: Stefan Monnier Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications Message-ID: References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , yantar92@posteo.net, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Sun, May 04, 2025 at 11:27:23 -0400, Stefan Monnier wrote: > > The right tool to find these is cflow, combined with grep and awk (or > > python or perl or whatever) to search and filter cflow's output. I've > > used these before. > Do you happen to remember the magic incantation to let `cflow` process > our sources correctly? I tried the rule below and the errors file > suggests that the preprocessing is done correctly (it's full of > complaints but only about redefinitions), yet the result doesn't include > any info about the functions called by `insert_1_both` or > `Fput_text_property` (to take two randomly sampled cases of interest). >From my notes from 2018, the command I used on cflow was: $ cflow --reverse -b -i +s --cpp -I. -I../lib -I/usr/include/glib-2.0 \ -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 buffer.c \ callproc.c \ casefiddle.c cmds.c coding.c decompress.c editfns.c emacs.c \ fileio.c fns.c \ indent.c insdel.c print.c process.c search.c textprop.c \ xdisp.c xml.c 2> /dev/null > ~/cflow.20180102b.txt. I no longer remember what the options mean, but the files I scanned were those containing calls to insdel.c's externally visible functions. I later analysed cflow.20180102b.txt with an elisp script, which I still have, and could send to you if you're interested. (It's 125 lines long, but poorly commented.) This script scanned the cflow output, recursively finding callers (direct and indirect) of signal_\(before\|after\)_change. > Stefan > diff --git a/src/Makefile.in b/src/Makefile.in > index e4fc2fef711..2c7aa92f9b9 100644 > --- a/src/Makefile.in > +++ b/src/Makefile.in > @@ -699,6 +699,18 @@ MAKE_PDUMPER_FINGERPRINT = > MAKE_PDUMPER_FINGERPRINT = > endif > +cgraph.cflow: > + cflow --all --brief --cpp='$(CC) -E $(ALL_CFLAGS)' \ > + $(ALLOBJS:.o=.c) \ > + >$@ 2>$@.errors > + > +cgraph-rev.cflow: > + cflow --reverse --all --brief --cpp='$(CC) -E $(ALL_CFLAGS)' \ > + $(ALLOBJS:.o=.c) \ > + >$@ 2>$@.errors > + > +flowcharts: cgraph-rev.cflow cgraph.cflow > + > ## We have to create $(etc) here because init_cmdargs tests its > ## existence when setting Vinstallation_directory (FIXME?). > ## This goes on to affect various things, and the emacs binary fails -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 13:25:17 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 17:25:17 +0000 Received: from localhost ([127.0.0.1]:58924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBd5U-0001Cv-US for submit@debbugs.gnu.org; Sun, 04 May 2025 13:25:17 -0400 Received: from mout01.posteo.de ([185.67.36.65]:49113) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBd5N-00016R-S4 for 78221@debbugs.gnu.org; Sun, 04 May 2025 13:25:09 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9A43B240027 for <78221@debbugs.gnu.org>; Sun, 4 May 2025 19:24:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1746379499; bh=r/p6z74CQV2YXsqvBskp+XjiKvSVWwopr9k6yHBNkTY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=STxd4i5azHJ6KBtpRHdV5PFCxthfB6olrFloD6MfIbAnvsmjhMSXiyYA88c+0ljsv wmCYGKf7MLKcHg8+8n6m7y03Nn2xSBX79ktc8Suv7Xqe5TgJuJn2/pXPdQJlMTv2ju z5XTU96LBGes+9nl5nM67ngCPzwIJB+0fzi6dJvuy1n8SrTnyNIOlXEJ7pxcRtZ0Yy 643hWGdocnG4R612IuHzLU2rVzyyHkVJXQbXFNjwD/JttuVh14Y/zAtpkujEkiz76R 9OuQfR/qqlayXw/ggkes2qgShsvcXHl7zmzjIz1B2DVZQGV0FXWI9nNKaGl4ZbopXV tDKTXvpi/V4UA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZrBP64YFFz9rxB; Sun, 4 May 2025 19:24:58 +0200 (CEST) From: Ihor Radchenko To: Stefan Monnier Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: References: <87h621fybf.fsf@localhost> <87o6w8j40o.fsf@localhost> <874iy0h6bu.fsf@localhost> Date: Sun, 04 May 2025 17:23:59 +0000 Message-ID: <87msbsffww.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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: > I wonder if someone actually knows of a `*-change-function` which wants > to be triggered when text-properties are modified. I'm not 100% sure > that I've never seen such a thing, but at least I can't remember seeing > (nor writing) such a thing. Me neither. Asking LLMs will just make them hallucinate :) > Are these property-modifications spread all over the place or can you > point us to a few important places where they happen? - org-edit-latex-fragment - org-display-custom-time - org-agenda (in special org-agenda buffers). not relevant to *-change-functions Org mode uses though > I'm curious to know as well how those deal with other related "usually > undesired" effects, such as modifying the `buffer-modified-p` flag, > stashing the property modifications into the `buffer-undo-list`, or > signaling errors when the buffer is read-only. Not very well usually, until someone files a bug report. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 14:12:51 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 18:12:51 +0000 Received: from localhost ([127.0.0.1]:59581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBdpa-0007VN-Dn for submit@debbugs.gnu.org; Sun, 04 May 2025 14:12:51 -0400 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:57635) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uBdpT-0007TW-K9 for 78221@debbugs.gnu.org; Sun, 04 May 2025 14:12:48 -0400 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-43d04dc73b7so30635935e9.3 for <78221@debbugs.gnu.org>; Sun, 04 May 2025 11:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746382357; x=1746987157; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zEpcqPD80KZeBFPcIeBi9sVdYg6ghAbCGklW3Cefs8I=; b=jmiW9uV/w7PbG6Nd6gavfeeQkDlfxwekAHuREtvZL9s+gIE9d1CGcQonlYwgS1y75T C2GFCnTpAmay5OdmbHzXeL8wE5rRZDT9fsVTFawPG9+zHks6a3GBn/s+QBavUjny1BZL Fnxz6aUZ++mCQ3SZMsZVcpRsdqntnxwMwE/4XRJiqaugXRLJhY2TVm4HWl0CYgSR3Pkw 4UB5Gv9hoX0t260sTPIABKeNBAV9+xG6x+CPK2Gwe5kqteS12Lwg5VR08QvmQ6gFnGLO YPDgRrRTh/w0QMaAWEPvkXU74c7h4j2isYq2Lk/RBp8J5M6m7Ozf21dKBv3eINK77nxp Ow3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746382357; x=1746987157; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zEpcqPD80KZeBFPcIeBi9sVdYg6ghAbCGklW3Cefs8I=; b=HrjXfFtpw57urrCVBIkJX7/idnyVeOlqg20eunwR/h+1zI7xR2yCNHOWcsUI48LvZa IUVCFZhhkusKmwBmjGRbUe2YS6zBmBsXpAybPLJIN1yMv0lkn/ISxAM+mRsStg0TTba7 20IutUCzscnv9QeR2hvX0MxRXgznhNTGCmhts85aMAWoF5bE7YJ5nzmJtA+oxqHNWq5c Ksf6isueDkaetJmqNdW1w/r8JexChhW6KpqHPv3/cnWZNGUvn1htGdq8qVwiJVhXXbrD /cN0Qfznv7j7Q2trrlTwNOtw78JydXtUt36am2eNECEhXoYOuoRPWiRUx8dS9Rrvbu1E kxEQ== X-Forwarded-Encrypted: i=1; AJvYcCXZDj4emjgQPAH/9dMCYAfL0pa/v6xbtSARDfqxZg3P83Tu1YzMJkszmOdH6AenmtJlDMlevA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyIJumVirwooi7V5thIQO/lC1UfocpRlCij7R4X5D3hkyFezZeh 0UqWkvDEgjRCXMuW5J7pdYqCL/7o1YmuoLT8Nk203MT/ocGC/86tyvN4K8cF X-Gm-Gg: ASbGncsxx6mNceH3kF5Mg6sPq98h6opt1ZDv5h+Q57c17aauaUZt14vWmIvUolNu+dI XQ79u03DEdtbhUzTqKKpUqetdilnYPwT7rTnawKhkrO3mIJ9p9w0sWjI7XA5j8rjvV1Zm61qPV/ PFhebPoJeQf9vB/idImIYyz9WLlUbWQJLaKH1Behs92UcVxJLRO4iGzHFzS/ecQc/QYYAvuUqFv IClmxPCTUahWVghQen/j/SklWPyjbfdUiq8wN6WE4tmD6JV2+Uyiy7NplrYCOgM0qpPECEJL7G5 uzVmQxfllQtEkgZQYH4F4rxFv4ckWv53BDgxPMQyTqf4B89IxqPDoYZYvNdCR6rBntzGtMN7t9C J1TKbI+txGKoD5Zt6g6veasb3tCE2Ea8xjC/owLUbAjAWpmEEY5qEKV93FKo= X-Google-Smtp-Source: AGHT+IF5O4CWJ4WAg9NoCgZnVgyOE+1bgig/kpJqZPOo0TMbQV/yEwZt+2CEgW5a25fOe2ofGet3IA== X-Received: by 2002:a05:600c:5111:b0:43c:fb95:c76f with SMTP id 5b1f17b1804b1-441c96a2795mr19579145e9.9.1746382357143; Sun, 04 May 2025 11:12:37 -0700 (PDT) Received: from pro2 (p200300e0b72a08009157338c42d2beef.dip0.t-ipconnect.de. [2003:e0:b72a:800:9157:338c:42d2:beef]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-441b8a315d3sm109079475e9.36.2025.05.04.11.12.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 May 2025 11:12:36 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Monnier Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> Date: Sun, 04 May 2025 20:12:35 +0200 Message-ID: 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-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: joaotavora@gmail.com, Alan Mackenzie , Eli Zaretskii , yantar92@posteo.net, 78221@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> The right tool to find these is cflow, combined with grep and awk (or >> python or perl or whatever) to search and filter cflow's output. I've >> used these before. > > Do you happen to remember the magic incantation to let `cflow` process > our sources correctly? I tried the rule below and the errors file > suggests that the preprocessing is done correctly (it's full of > complaints but only about redefinitions), yet the result doesn't include > any info about the functions called by `insert_1_both` or > `Fput_text_property` (to take two randomly sampled cases of interest). I use Clangd + Eglot + eglot-supplements if I have questions about who call whom. With clangd 20 one can display incoming and outgoing call trees. Only inconvenience is that one has to expand nodes in the tree manually because nodes are created on demand via LSP. And this of course only sees what's compiled in. Anyway, random example for add_text_properties_1, incoming call trees: - add_text_properties_1 textprop.c:1170 - add_text_properties_1 add_text_properties_1:1182 =E2=80=A2 =E2=AC=81add_text_properties_1 add_text_properties_1:1182 - Fadd_text_properties Fadd_text_properties:1308 + Fpropertize Fpropertize:3297 + echo_add_key echo_add_key:548 + echo_add_key echo_add_key:549 + describe_key_maybe_fontify describe_key_maybe_fontify:3092 + Sadd_text_properties Sadd_text_properties:1296 + Fput_text_property Fput_text_property:1326 + copy_text_properties copy_text_properties:2026 + add_text_properties_from_list add_text_properties_from_list:2111 =E2=80=A2 tty_handle_tab_bar_click tty_handle_tab_bar_click:15384 + store_mode_line_string store_mode_line_string:28515 + store_mode_line_string store_mode_line_string:28542 + store_mode_line_string store_mode_line_string:28558 + Fadd_face_text_property Fadd_face_text_property:1368 - Fadd_text_properties Fadd_text_properties:1308 + Fpropertize Fpropertize:3297 + echo_add_key echo_add_key:548 + echo_add_key echo_add_key:549 + describe_key_maybe_fontify describe_key_maybe_fontify:3092 + Sadd_text_properties Sadd_text_properties:1296 - Fput_text_property Fput_text_property:1326 + Fcall_interactively Fcall_interactively:484 + Fcall_interactively Fcall_interactively:536 + Fcall_interactively Fcall_interactively:567 + produce_charset produce_charset:7277 + update_compositions update_compositions:530 - update_compositions update_compositions:571 + casify_region casify_region:565 + decode_coding_object decode_coding_object:8191 + encode_coding_object encode_coding_object:8483 + unwind_decompress unwind_decompress:190 + Fzlib_decompress_region Fzlib_decompress_region:333 - Freplace_region_contents Freplace_region_contents:2190 + Sreplace_region_contents Sreplace_region_contents:1923 + Fsubst_char_in_region Fsubst_char_in_region:2412 + Ftranslate_region_internal Ftranslate_region_internal:2599 + Ftranspose_regions Ftranspose_regions:4666 + Ftranspose_regions Ftranspose_regions:4667 + Finsert_file_contents Finsert_file_contents:5008 - insert_from_buffer insert_from_buffer:1086 + encode_coding_object encode_coding_object:8360 + Finsert_buffer_substring Finsert_buffer_substring:1743 + Finsert_file_contents Finsert_file_contents:4744 + replace_range replace_range:1543 + del_range_1 del_range_1:1743 + del_range_byte del_range_byte:1785 + del_range_both del_range_both:1829 + Fcombine_after_change_execute Fcombine_after_change_execute:2392 + insert insert:575 + insert_and_inherit insert_and_inherit:590 + insert_before_markers insert_before_markers:635 + insert_before_markers_and_inherit insert_before_markers_and_inher= it:651 + insert_from_string insert_from_string:870 + insert_from_string_before_markers insert_from_string_before_marke= rs:890 + Fjson_insert Fjson_insert:685 + Freplace_match Freplace_match:2784 + compose_text compose_text:638 + read_minibuf read_minibuf:849 + read_minibuf read_minibuf:851 + read_minibuf read_minibuf:853 + read_minibuf read_minibuf:875 + Sput_text_property Sput_text_property:1314 + copy_text_properties copy_text_properties:2026 + add_text_properties_from_list add_text_properties_from_list:2111 =E2=80=A2 tty_handle_tab_bar_click tty_handle_tab_bar_click:15384 + store_mode_line_string store_mode_line_string:28515 + store_mode_line_string store_mode_line_string:28542 + store_mode_line_string store_mode_line_string:28558 + Fadd_face_text_property Fadd_face_text_property:1368 From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 14:18:46 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 18:18:46 +0000 Received: from localhost ([127.0.0.1]:59672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBdvJ-0008Hq-MF for submit@debbugs.gnu.org; Sun, 04 May 2025 14:18:46 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27611) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBdvH-0008HU-Nb for 78221@debbugs.gnu.org; Sun, 04 May 2025 14:18:44 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C0D41808C2; Sun, 4 May 2025 14:18:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746382716; bh=/MmGpjFajouL/c4IAjyILmTOdtkSgbFC/yf6bm2a6cQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cnIQzMg5DFvIOTGgJh4lafsO17YThgwoXXI9NpDswUklKbtPkOZ2m5XvgM+MaN7P7 2kH6/m7twC6g6eQykMyE5znNe+wmZ9ZDvqhcApga8vntnglIn2mHW2+fsG10xkL1LI Ukz1WYJyZIVuhuQqxLbOAIiDUYCQwZmqK6ebzJ5ydk1RNDde8wvPI7Ivzord6aAnP/ saa7jyvOYn6BXiAjjbXzbxExWa80YaWfdWtAXESXtiHSe03foXDrmYsyRlMdVvrRmg RaGYzu9ccbNmERcHNIjEIGLNusNreBYnFfbhJsrkUJPgHLM+/HRO66Os5ZHR3+JpBD Fc45TkCzW2xRQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5AD6A8089D; Sun, 4 May 2025 14:18:36 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 17B0112041D; Sun, 4 May 2025 14:18:36 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: Message-ID: References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> Date: Sun, 04 May 2025 14:18:35 -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.064 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: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , yantar92@posteo.net, joaotavora@gmail.com 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 my notes from 2018, the command I used on cflow was: > > $ cflow --reverse -b -i +s --cpp -I. -I../lib -I/usr/include/glib-2.0 \ > -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 buffer.c \ > callproc.c \ > casefiddle.c cmds.c coding.c decompress.c editfns.c emacs.c \ > fileio.c fns.c \ > indent.c insdel.c print.c process.c search.c textprop.c \ > xdisp.c xml.c 2> /dev/null > ~/cflow.20180102b.txt. > > I no longer remember what the options mean, but the files I scanned were > those containing calls to insdel.c's externally visible functions. Thanks. That gives me the same problems. =F0=9F=99=81 > I later analysed cflow.20180102b.txt with an elisp script, which I still > have, and could send to you if you're interested. (It's 125 lines long, > but poorly commented.) This script scanned the cflow output, > recursively finding callers (direct and indirect) of > signal_\(before\|after\)_change. Can't hurt, thanks. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 14:38:16 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 18:38:16 +0000 Received: from localhost ([127.0.0.1]:59973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBeEC-0002bM-4n for submit@debbugs.gnu.org; Sun, 04 May 2025 14:38:16 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50959) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBeE9-0002ae-Hr for 78221@debbugs.gnu.org; Sun, 04 May 2025 14:38:14 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9BDAA441187; Sun, 4 May 2025 14:38:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746383886; bh=bjxa9ajLi0GRXqLcm0octdR8fe5dH+G225ugVqbwygM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=R21pQx5AJHsrLnAT8dkCC9lD9bubqjuyVk9IsTtv1iL8nlhV3e+JzHikRgiJ/iKsB Go7OCnFJZjqH7AjlZmSbbEgi8kEjkZzDWnep9aGYLrmFOooFp8qBAnrnrqoSNWfZaD OAgK2V8Kl5mVVMHmxMzkivqSzKDQfUqeHb0lbLWNj3wSQNM4XqgldXs8PdfJPw9xZ2 sSULCA8abowQseYRIqFzkuH9Q4r6B4URWLgHdVK6yMaYOE2jrjiKwFdLYsMkd5D10B ODrJ5eccEqRPGdBa4s537IttA/MMeGnYCUIk02CaYcKmEJMqLvCy8LnJxdhU2OHy3b ktigbwNzF3kHA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8993944102D; Sun, 4 May 2025 14:38:06 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5345B120185; Sun, 4 May 2025 14:38:06 -0400 (EDT) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: <87msbsffww.fsf@localhost> Message-ID: References: <87h621fybf.fsf@localhost> <87o6w8j40o.fsf@localhost> <874iy0h6bu.fsf@localhost> <87msbsffww.fsf@localhost> Date: Sun, 04 May 2025 14:38:05 -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.045 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: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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 wonder if someone actually knows of a `*-change-function` which wants >> to be triggered when text-properties are modified. I'm not 100% sure >> that I've never seen such a thing, but at least I can't remember seeing >> (nor writing) such a thing. > Me neither. =F0=9F=99=81 >> Are these property-modifications spread all over the place or can you >> point us to a few important places where they happen? > > - org-edit-latex-fragment Hmm... AFAICT it adds text properties to a string, not to a buffer. > - org-display-custom-time AFAICT this is called exclusively from font-lock, so `inhibit-modifications-hooks` should always be set already. > - org-agenda (in special org-agenda buffers). not relevant to > *-change-functions Org mode uses though `org-agenda.el` didn't quite fit on my screen (=F0=9F=99=82), so I didn't investigate, especially since you say it's not directly relevant. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 14:40:55 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 18:40:55 +0000 Received: from localhost ([127.0.0.1]:60020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBeGk-000319-Cw for submit@debbugs.gnu.org; Sun, 04 May 2025 14:40:54 -0400 Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]:50271) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uBeGe-0002zP-2O for 78221@debbugs.gnu.org; Sun, 04 May 2025 14:40:51 -0400 Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-72ec926e828so1027763a34.0 for <78221@debbugs.gnu.org>; Sun, 04 May 2025 11:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746384042; x=1746988842; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=exEaR4lRElPTvhFY4MMFdLEpsrnzCjYaPwYHAQ5vJ7Q=; b=nN5OvMFev6RmcXPr40DlLGMrBfxmRNUklx4iZbufSg8T/ZVniCSq5/eBfZbAYhrykQ T0PyPY/VB4XKwu7OY8nR6PtZByTswNNE2Jx/9OJgmPnboHZpDV4jRc64XuCEP07rpyR/ X2ZxFBZi8tefyNGyHXCL/5KbxV2b/PAfOx7aDNKidDKWwqM19K57ktMzM7rtYIDtNuMY qqd5MqPFkyWJr5+rwe73kLrY15/LStX3EmkHYq5Tw2GoahV7d3Zx+zpSVTKlruDyHKKN 2HpNNpnk9ndgEkiYNtAJi4MNSZUS/jHCAwM1H3BNxxS1ZDEo92oIIDRDuRmW3UsAz3W+ gtRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746384042; x=1746988842; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=exEaR4lRElPTvhFY4MMFdLEpsrnzCjYaPwYHAQ5vJ7Q=; b=Q7Ky6mSuI2DD8tDnLu0lJZq6110mKkgpZBueXfdqReUil47Vcg2h58BsHL//+V+1dW KGQSJXmNywzkSh+Stg6ykWPA3QIKMJewfqeO9Gl7Eiaj1QGX1VwEmbhZf+qnfzht1M63 fmMGQcpm9hk739MM6xKFyni1sSf1PFQA0Ug4buaBL5nL9GNKS3kWL6PnyhDtNN8TDFvT Gl/DGtY2gUwNk0pBJ+Xs056DuuSvxHsZiRP0Lx8s2+i+QuL5aSAG56DWembFagIREaNy V2Ukyv9+9B8dZVMEnvZ6aMubnaUjxrWvm5RjiozeaV2CfWmw3imucTlpSr+gpQZ6Xa9s m/Ag== X-Forwarded-Encrypted: i=1; AJvYcCW1pVf5cdaHQkwyaj0L+ERd+SGUcG2JTPVY411JroXT1Z2m/gGvmn4zG2I+HadEZqJAnq36JA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwnBkMIoCuYH27kWV4wHE5TtRH3+r18ooBAVo0wyNwIbvMWT/fJ +ncOLPTw+qqXRglSphhpAxCRILvDpXa85GXn9xYd9Hj0aDWMaA5AvKG+MraHU+y+pg0dDIGFX+D PkXjkPV8fjK3kTJKp/M1q7PcPa6Q= X-Gm-Gg: ASbGncsatESwmbfQrf8w6qjYZULl0H63jiYQQggQfaF9x0i51gDxrf1jfEdEUmeys2A y32Wf01IOJaDh+T1gXhi1DN27pVeD1BMO91+Dk2FtVk2HguyOLrt6jMXFEBiEFlcz2/a2ltQTfA 6gZnoJSL0frFIonLjtY/uI0g== X-Google-Smtp-Source: AGHT+IH2yY/xbBPjh+LoBRjDAgBcyg4iBz012FHlBqeLC/JmOW2I5o8f3KfcMzseZPGTr4e3OfnSVjQjlCF7QBNIsQA= X-Received: by 2002:a05:6870:d0c9:b0:2c6:72d3:fc93 with SMTP id 586e51a60fabf-2dae82d7e68mr2562644fac.12.1746384041886; Sun, 04 May 2025 11:40:41 -0700 (PDT) MIME-Version: 1.0 References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sun, 4 May 2025 19:40:31 +0100 X-Gm-Features: ATxdqUG_BAGmZBQZdXWEU-_485AOk_7HbYKKiMbJFRKJZNHh6W4fc-cW7I3PMT4 Message-ID: Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications To: =?UTF-8?Q?Gerd_M=C3=B6llmann?= Content-Type: multipart/alternative; boundary="000000000000754823063453b826" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: Alan Mackenzie , Eli Zaretskii , Ihor Radchenko , Stefan Monnier , 78221@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000754823063453b826 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 4, 2025, 19:12 Gerd M=C3=B6llmann wr= ote: > Stefan Monnier writes: > > >> The right tool to find these is cflow, combined with grep and awk (or > >> python or perl or whatever) to search and filter cflow's output. I've > >> used these before. > > > > Do you happen to remember the magic incantation to let `cflow` process > > our sources correctly? I tried the rule below and the errors file > > suggests that the preprocessing is done correctly (it's full of > > complaints but only about redefinitions), yet the result doesn't includ= e > > any info about the functions called by `insert_1_both` or > > `Fput_text_property` (to take two randomly sampled cases of interest). > > I use Clangd + Eglot + eglot-supplements if I have questions about who > call whom. > > With clangd 20 one can display incoming and outgoing call trees. Only > inconvenience is that one has to expand nodes in the tree manually > because nodes are created on demand via LSP. And this of course only > sees what's compiled in. > I was going to suggest mostly the and, except you don't need "eglot supplements" since call hierarchies (and type, too) are blue in Eglot for some months. See the manual of you're interested. I clangd sees anything that compile_commands.json mentions, it doesn't actually need to be or have been compiled. Expanding node by node makes sense to me, as huge swaths of the graph (which is sometimes cyclic) are uninteresting. Jo=C3=A3o > --000000000000754823063453b826 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Ma= y 4, 2025, 19:12 Gerd M=C3=B6llmann <gerd.moellmann@gmail.com> wrote:
Stefan Monnier <monnier@iro.umont= real.ca> writes:

>> The right tool to find these is cflow, combined with grep and awk = (or
>> python or perl or whatever) to search and filter cflow's outpu= t.=C2=A0 I've
>> used these before.
>
> Do you happen to remember the magic incantation to let `cflow` process=
> our sources correctly?=C2=A0 I tried the rule below and the errors fil= e
> suggests that the preprocessing is done correctly (it's full of > complaints but only about redefinitions), yet the result doesn't i= nclude
> any info about the functions called by `insert_1_both` or
> `Fput_text_property` (to take two randomly sampled cases of interest).=

I use Clangd + Eglot + eglot-supplements if I have questions about who
call whom.

With clangd 20 one can display incoming and outgoing call trees. Only
inconvenience is that one has to expand nodes in the tree manually
because nodes are created on demand via LSP. And this of course only
sees what's compiled in.
=
I was going to suggest mostly the and, except y= ou don't need "eglot supplements" since call hierarchies (and= type, too) are blue in Eglot for some months. See the manual of you're= interested.

I clangd se= es anything that compile_commands.json mentions, it doesn't actually ne= ed to be or have been compiled.

Expanding node by node makes sense to me, as huge swaths of the g= raph (which is sometimes cyclic) are uninteresting.=C2=A0

Jo=C3=A3o
--000000000000754823063453b826-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 14:41:17 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 18:41:17 +0000 Received: from localhost ([127.0.0.1]:60030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBeH7-000340-5E for submit@debbugs.gnu.org; Sun, 04 May 2025 14:41:17 -0400 Received: from mail.muc.de ([193.149.48.3]:29982) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBeH4-00033I-M6 for 78221@debbugs.gnu.org; Sun, 04 May 2025 14:41:15 -0400 Received: (qmail 14042 invoked by uid 3782); 4 May 2025 20:41:07 +0200 Received: from muc.de (p4fe1596e.dip0.t-ipconnect.de [79.225.89.110]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 04 May 2025 20:41:07 +0200 Received: (qmail 606 invoked by uid 1000); 4 May 2025 18:41:06 -0000 Date: Sun, 4 May 2025 18:41:06 +0000 To: Stefan Monnier Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications Message-ID: References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="xpfv3Dfby2t0ZjsN" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , yantar92@posteo.net, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --xpfv3Dfby2t0ZjsN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, Stefan. On Sun, May 04, 2025 at 14:18:35 -0400, Stefan Monnier wrote: > > From my notes from 2018, the command I used on cflow was: > > $ cflow --reverse -b -i +s --cpp -I. -I../lib -I/usr/include/glib-2.0 \ > > -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 buffer.c \ > > callproc.c \ > > casefiddle.c cmds.c coding.c decompress.c editfns.c emacs.c \ > > fileio.c fns.c \ > > indent.c insdel.c print.c process.c search.c textprop.c \ > > xdisp.c xml.c 2> /dev/null > ~/cflow.20180102b.txt. > > I no longer remember what the options mean, but the files I scanned were > > those containing calls to insdel.c's externally visible functions. > Thanks. That gives me the same problems. 🙠Sorry about that. > > I later analysed cflow.20180102b.txt with an elisp script, which I still > > have, and could send to you if you're interested. (It's 125 lines long, > > but poorly commented.) This script scanned the cflow output, > > recursively finding callers (direct and indirect) of > > signal_\(before\|after\)_change. > Can't hurt, thanks. OK, it's attached. To run it, use M-: (find-change-functions), M-: (find-primitives), or M-: (make-primitive-calls) (not very useful). For these, the current buffers needs to be the cflow output. > Stefan -- Alan Mackenzie (Nuremberg, Germany). --xpfv3Dfby2t0ZjsN Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="get-signal-change.el" ;; Go through the output of ;; ;; $ cflow --reverse -b -i +s --cpp -I. -I../lib -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 \ ;; buffer.c coding.c decompress.c editfns.c emacs.c fileio.c fns.c insdel.c process.c search.c xml.c 2> /dev/null ;; ;; , noting every function which calls signal_\(before\|after\)_change, both directly and indirectly. ;; Filter out the Emacs primitives (functions beginning "F") and convert their names to the lisp names. (defvar functions nil "An alist of ( )") (defvar processed-functions nil "A list of processed functions") (defvar primitives nil) (defun our-goto-line (n) (forward-line (- n (line-number-at-pos)))) (defun current-margin () (save-excursion (back-to-indentation) (current-column))) (defun read-number () (let ((tot 0) ch) (while (progn (setq ch (char-after)) (and (>= ch ?0) (<= ch ?9))) (setq tot (+ (* 10 tot) (- ch ?0))) (forward-char)) tot)) (defun get-limit () "With point at some entry, determine the buffer offset of the next entry with the same number of spaces, or fewer, than the current entry." (save-excursion (let ((indentation (current-margin)) ) (while (and (eq (forward-line) 0) (> (current-margin) indentation))) (point)))) (defun get-function-name () "Get the name of the function from the start of the current line." (save-excursion (back-to-indentation) (buffer-substring-no-properties (point) (progn (search-forward "(") (1- (point)))))) (defun get-direct-callers () "Doc string." (let* ((limit (get-limit)) (margin (save-excursion (back-to-indentation) (current-column))) (margin+4 (+ margin 4)) our-functions ) (while (and (eq (forward-line) 0) (< (point) limit)) (when (eq (current-margin) margin+4) (end-of-line) (cond ((eq (char-before) ?\]) (backward-char) (skip-chars-backward "0-9") (push (cons (get-function-name) (read-number)) our-functions)) (t ;(eq (char-before) ?:) (push (cons (get-function-name) (line-number-at-pos)) our-functions)) ;; (t ;; (error "process-one-entry: invalid line at %s" ;; (line-number-at-pos))) ))) our-functions)) (defun get-all-callers () "Doc string." (let ((direct-callers (get-direct-callers)) ) (dolist (elt direct-callers) (let ((f (car elt))) (when (not (member f processed-functions)) (our-goto-line (cdr elt)) (push f processed-functions) (get-all-callers)))))) (defun find-change-functions () (let ( ) (setq processed-functions nil) (goto-char (point-min)) (search-forward "signal_after_change") (push "signal_after_change" processed-functions) (get-all-callers) (goto-char (point-min)) (search-forward "signal_before_change") (push "signal_before_change" processed-functions) (get-all-callers))) (defun find-primitives () (setq primitives nil) (let ((sorted-primitives nil) ) (dolist (f processed-functions) (when (string-match "^F" f) (push (substring (replace-regexp-in-string "_" "-" f) 1) primitives))) (setq sorted-primitives (sort primitives 'string-lessp)) (setq primitives sorted-primitives))) (defun make-primitive-calls () (with-current-buffer "change-primitive-calls.el" (kill-region (point-min) (point-max)) (dolist (p primitives) (insert ?\( p ?\) ?\n)))) --xpfv3Dfby2t0ZjsN-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 14:42:38 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 18:42:39 +0000 Received: from localhost ([127.0.0.1]:60051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBeIM-0003AV-3d for submit@debbugs.gnu.org; Sun, 04 May 2025 14:42:38 -0400 Received: from mail-oo1-xc30.google.com ([2607:f8b0:4864:20::c30]:54712) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uBeIJ-00039q-Mu for 78221@debbugs.gnu.org; Sun, 04 May 2025 14:42:32 -0400 Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-60634f82c77so1015796eaf.1 for <78221@debbugs.gnu.org>; Sun, 04 May 2025 11:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746384146; x=1746988946; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ncDhhJsOkz5spbt6vcAQHsnJyXcGXoEQfZjpa+O2egw=; b=d/JLWuEWqGn1V9NkuX5Mwqv55pEAfUnkR1rACqzCOv9QMGm0NGfCg03T0IkzEYtXhg Fh7FBUKgIP+8mE2EPmIi2Ekwi61ygS6emLmy80M43bAdH2HE1dsDOHJUEToC2Rw42Bie PmPXkGCmHCGNapZ2d7ZxFPmiQM/LocsF7SjkM7zHgJojFqhSwZF4mw5CULGFEJbc/67F 71aoin5GctSSVlBlsonjx81wT7fqcvqnVceeYdgT2AJCk2jw0HhrVj0t//LyHC84ZiPj cqSbcRdDV9sREb9FE8dIuXSYCL0FfB18s97gNnpPZ168hECiXnlhN+AYuzBOyq17Garp reoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746384146; x=1746988946; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ncDhhJsOkz5spbt6vcAQHsnJyXcGXoEQfZjpa+O2egw=; b=lah9AauVcWQMOMojPG8EKpWsHV2y9PT33CLLP/570sXzOqXlxgh3Idy4zFe4LkXSnO 3aiK0Lyxf8+rbXYEpooP3g/r+mI3xqYuQHQPRMSGLbaLyXWzDnYXyTOl1SwID9e6DMfU DB+eIy7g4TDfuO9GUKXSzLorhukvm1n/zHjk9ydbDq/S2C9uIWCyMJZr5u+dFmvrHdQH jVl0flPn365rlrxcCZjjGDFTZQk5nQQTixQ/ylDu/C1266t3rWVzhCgRGE1UJKebx3CR QA5nSpiw4qXT8OO4FtRXjy1ovdpaz9wY4aHvvZXqdaK9tvqBxv0J/HNGYMbQieZqkWef /ioQ== X-Forwarded-Encrypted: i=1; AJvYcCX7T93KvarG25/0Qc2PIO7L7IfDSaqsGg6Xw3HKSgniZVB+8xhhvhrcEaW+KpyZ9vbDyWtkCg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyGsYJr8oPQSjhJWEYZ+MidewGXSExQqmFoRqHaoK22DuIbk9rP XWCX7qhevGKKfkkbl3fpr2Bh5GXf8aV+a736y77eVJtCEv3mKgJ6/6gtq3qejIc06MM+V7JFDHY MrVAGa1xCoAnB/pLiodCLXU5Y4vw= X-Gm-Gg: ASbGnctICUgk7d+EWxlD9k0LjUgW+/jSTI9OXLWGYCkGzyy4HdetnHHJ8Tc6EKXlVyG TwGH75+tXsBQL/bwp+1lP+gsjpDpOfEGwPKJ31IDa4bBD6WCGcc8U2+UkyPSYofYmwr/XpfT6Du XL2X6T3j0Do89k36KVpA8zxA== X-Google-Smtp-Source: AGHT+IFRYFlS7nF1m9nEkTQW6VsGAMQo0078dbrfojE90mTtV0MIdpm+NP963AuUS7c7hTYYuWIOWBy2T/3ig+CrTnk= X-Received: by 2002:a54:4586:0:b0:400:fa6a:d9f6 with SMTP id 5614622812f47-4035a5c89f3mr2327494b6e.25.1746384145824; Sun, 04 May 2025 11:42:25 -0700 (PDT) MIME-Version: 1.0 References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sun, 4 May 2025 19:42:15 +0100 X-Gm-Features: ATxdqUHTtk4IFlTcp-5MYWyr1KsLwVxbR2ZsotBH4hfBUVcnUYxvmxbuSN9Tw2c Message-ID: Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications To: =?UTF-8?Q?Gerd_M=C3=B6llmann?= Content-Type: multipart/alternative; boundary="000000000000a74111063453bedf" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: Alan Mackenzie , Eli Zaretskii , Ihor Radchenko , Stefan Monnier , 78221@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000a74111063453bedf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stupid auto-correct: and -> same blue -> built-in Jo=C3=A3o T=C3=A1vora On Sun, May 4, 2025, 19:40 Jo=C3=A3o T=C3=A1vora wro= te: > > > On Sun, May 4, 2025, 19:12 Gerd M=C3=B6llmann = wrote: > >> Stefan Monnier writes: >> >> >> The right tool to find these is cflow, combined with grep and awk (or >> >> python or perl or whatever) to search and filter cflow's output. I'v= e >> >> used these before. >> > >> > Do you happen to remember the magic incantation to let `cflow` process >> > our sources correctly? I tried the rule below and the errors file >> > suggests that the preprocessing is done correctly (it's full of >> > complaints but only about redefinitions), yet the result doesn't inclu= de >> > any info about the functions called by `insert_1_both` or >> > `Fput_text_property` (to take two randomly sampled cases of interest). >> >> I use Clangd + Eglot + eglot-supplements if I have questions about who >> call whom. >> >> With clangd 20 one can display incoming and outgoing call trees. Only >> inconvenience is that one has to expand nodes in the tree manually >> because nodes are created on demand via LSP. And this of course only >> sees what's compiled in. >> > > I was going to suggest mostly the and, except you don't need "eglot > supplements" since call hierarchies (and type, too) are blue in Eglot for > some months. See the manual of you're interested. > > I clangd sees anything that compile_commands.json mentions, it doesn't > actually need to be or have been compiled. > > Expanding node by node makes sense to me, as huge swaths of the graph > (which is sometimes cyclic) are uninteresting. > > Jo=C3=A3o > >> --000000000000a74111063453bedf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stupid auto-correct:
=C2=A0and -> same
=C2=A0= blue -> built-in

Jo=C3=A3o T=C3=A1vora

On Sun, May 4, 2025, 19:40 = Jo=C3=A3o T=C3=A1vora <joaotavor= a@gmail.com> wrote:


On Sun, May 4, 2025,= 19:12 Gerd M=C3=B6llmann <gerd.moellmann@gmail.com> wrote:=
Stefan Monnier = <monnier@iro.umontreal.ca> writes:

>> The right tool to find these is cflow, combined with grep and awk = (or
>> python or perl or whatever) to search and filter cflow's outpu= t.=C2=A0 I've
>> used these before.
>
> Do you happen to remember the magic incantation to let `cflow` process=
> our sources correctly?=C2=A0 I tried the rule below and the errors fil= e
> suggests that the preprocessing is done correctly (it's full of > complaints but only about redefinitions), yet the result doesn't i= nclude
> any info about the functions called by `insert_1_both` or
> `Fput_text_property` (to take two randomly sampled cases of interest).=

I use Clangd + Eglot + eglot-supplements if I have questions about who
call whom.

With clangd 20 one can display incoming and outgoing call trees. Only
inconvenience is that one has to expand nodes in the tree manually
because nodes are created on demand via LSP. And this of course only
sees what's compiled in.
=
I was going to suggest mostly the and, except y= ou don't need "eglot supplements" since call hierarchies (and= type, too) are blue in Eglot for some months. See the manual of you're= interested.

I clangd se= es anything that compile_commands.json mentions, it doesn't actually ne= ed to be or have been compiled.

Expanding node by node makes sense to me, as huge swaths of the g= raph (which is sometimes cyclic) are uninteresting.=C2=A0

Jo=C3=A3o
--000000000000a74111063453bedf-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 14:45:51 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 18:45:52 +0000 Received: from localhost ([127.0.0.1]:60106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBeLU-0003fU-4P for submit@debbugs.gnu.org; Sun, 04 May 2025 14:45:51 -0400 Received: from mout02.posteo.de ([185.67.36.66]:54511) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBeLQ-0003eb-1t for 78221@debbugs.gnu.org; Sun, 04 May 2025 14:45:45 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7BB66240101 for <78221@debbugs.gnu.org>; Sun, 4 May 2025 20:45:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1746384336; bh=DHRI4DBhCy98i128MWYZFCd2JNcMLjyd1HGmYkfjg/I=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=kmiYhR+PmqQQrR/PGkIFqvxQb2UPNXLspcbh7jtoBs/yW9UD+JuizjVgXkAC8/5CC QaqLOrka/jSzXWyRFMkbDY9Gg3O9Sj5jDPcY/gKEi9O5Z0wDWsQne1H5UgLb2zDerS FECL/j33P8ob0qdirUog7hS79rqrdKyFgDWVfD1Ko6Zfq2Uhq15H/UDC/DgGdaq54W hB4alGH9LFZwmAx/jVfU5nxbuExcK5cbJzD0nJKBKvB/ApzIYbbtAOeey7Z7sQZ1fZ ZmJMScsnK6lLPcQSLGbng3c/YsX05q4S/VyatebgUo3OgPoDVTh4tf+kyCB0R4ptnX flihhex+rlD7g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4ZrDB74Vrvz9rxB; Sun, 4 May 2025 20:45:35 +0200 (CEST) From: Ihor Radchenko To: Stefan Monnier Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: References: <87h621fybf.fsf@localhost> <87o6w8j40o.fsf@localhost> <874iy0h6bu.fsf@localhost> <87msbsffww.fsf@localhost> Date: Sun, 04 May 2025 18:44:36 +0000 Message-ID: <874iy0cj1n.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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: >> - org-edit-latex-fragment > > Hmm... AFAICT it adds text properties to a string, not to a buffer. Right. I was thinking about read-only state we put during the edit, but that's an overlay. >> - org-display-custom-time > > AFAICT this is called exclusively from font-lock, so > `inhibit-modifications-hooks` should always be set already. I was close. `org-toggle-timestamp-overlays' (just above). -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 14:47:41 2025 Received: (at 78221) by debbugs.gnu.org; 4 May 2025 18:47:41 +0000 Received: from localhost ([127.0.0.1]:60129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBeND-0003ts-U1 for submit@debbugs.gnu.org; Sun, 04 May 2025 14:47:41 -0400 Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:45416) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uBeNB-0003tA-A7 for 78221@debbugs.gnu.org; Sun, 04 May 2025 14:47:33 -0400 Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-441c99459e9so2855645e9.3 for <78221@debbugs.gnu.org>; Sun, 04 May 2025 11:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746384447; x=1746989247; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=V/YRqDx8trvoT3wdcS9jp9yNAgeBuxqTEJ4A8aO2izI=; b=YI0SaOkQcPHSQ/2FAOZAYy+JNOyzKiUWEiAfNPF1F9f/r6MNjygRv3fUc9KvCKO7ju FMnLufK28R44BpjXTpgcEAbbdokCtfwKKaheVtDu/Xg5/JpG7wP665qZT85diN4eSJI9 RxMOWvz1ft7b+X+RO1tvZyq5tu9APt2HmH+/tP/1wZdRPKkmkAnPyEWogpj1pdIbRDe0 7GiVdZ77xyl2mBLQ3QBWxuLr3lzjz/PRTIXqh40OHJ0F2QZgRzhcV8+NEV6eg3Xamh6e 5OSEnhMlsL799o7U0kF3J0oXXrgIl40g7mXH++Fap4h4RyRXabrTrD+NUjOz/FrEFJxL ChQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746384447; x=1746989247; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=V/YRqDx8trvoT3wdcS9jp9yNAgeBuxqTEJ4A8aO2izI=; b=sP97nzOUq1MqwiEg2JtorNajxqew6kss2OBRQ4W+Y7GcqDbIevZWoggXdRd2e+EFzT XkTAYhTr2Rd7Tqp7cCjmpW8ifIAiXPGYeKZXfDFxS3MOi0LDVO2ieBVoryrNKDZawYil DnImNacMCLM+tF+5IOtAVqp3LVTEOYWV5kqbwg53/wKwillNZfz4Jl2vcaK65iDzP0KK ICQeDfRKHUGcT2LzbqGCAH4B8llL/afFNvuQOXRcnU+849Hu0sopcAroCMTjW/NnVMGf t6SdUAzS8cdoiAZJ1Be6xRJ88Px/2s8PHVt1gxu8xOhVU3FLOj+idFEx7AkXssAutTtR zMfw== X-Forwarded-Encrypted: i=1; AJvYcCXiOEdaWKNY3NgcKpbKuUEd7JmB+VR2nwh21mGKhYS0s3B8cQ4Q8vmimX4F7zbsaizPm2sD4g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwFX36jciPY2N0bWy99SmctGhQIjJd4/m4r6OSiYUGFh+uoBOOF GwhD4frAu2HtvAheDGHlaab9zz9koYN/o2EUe4qb5OhtoY1yd+UqqAkFQkjJ X-Gm-Gg: ASbGnctjnNxx6SHq3zhQK5ybRF0oQUfpeLZ8RattZM8FtRXp4DWDvzrwGdDOfaiqWiU Muxp9qUJ3CyYAWOKGgIFWrErRLxXPQQ4/hAXja5zPkIpmFvg4Cw5msgqZIgwbkBX7GZ63WrLVFS PUxZ88YCz8k827szTzYRR6UMuC8JIMJnnFuDPPd1SWIHdVWV5FrfS/+MX/6kwGRdTxeZ3KmbiLU qY6tzGkXIUndmzs/B3+poUdXnkaQ3Tw9DFaFCbJtA0pE0L8GGDWFkd+s3mMOglD16ph+PfvLMjW +2LroIKBwwEQEdin7hSRN37Zyf40I8oBqghny2K7nOaNaE98PCNGQCot6INH3YFcaR5z6Mu9kG5 cSrogn9gPcRW2lwAhdIMsdBq2ZT5i4grnTVxBnT0GKP1am0cY X-Google-Smtp-Source: AGHT+IESv9PK8BP92rjbxJtsTKm35hx5A44zSFN33LlZZlrkYKqYE7kt0nGzSnSzIiCpMPTE5jUFvg== X-Received: by 2002:a05:600c:5304:b0:43c:fe15:41e1 with SMTP id 5b1f17b1804b1-441bbea0afbmr94940105e9.4.1746384446573; Sun, 04 May 2025 11:47:26 -0700 (PDT) Received: from pro2 (p200300e0b72a08009157338c42d2beef.dip0.t-ipconnect.de. [2003:e0:b72a:800:9157:338c:42d2:beef]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-441b2ad784asm153790965e9.7.2025.05.04.11.47.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 May 2025 11:47:26 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: References: <86o6w9iwhp.fsf@gnu.org> <86ldrditec.fsf@gnu.org> Date: Sun, 04 May 2025 20:47:25 +0200 Message-ID: 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-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: Alan Mackenzie , Eli Zaretskii , Ihor Radchenko , 78221@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > I was going to suggest mostly the and, except you don't need "eglot supp= lements" since call > hierarchies (and type, too) are blue in Eglot for some months. See > the manual of you're interested. That's nice! Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun May 04 23:09:52 2025 Received: (at 78221) by debbugs.gnu.org; 5 May 2025 03:09:52 +0000 Received: from localhost ([127.0.0.1]:36529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uBmDI-0007a4-Al for submit@debbugs.gnu.org; Sun, 04 May 2025 23:09:52 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12915) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uBmDF-0007Ze-6q for 78221@debbugs.gnu.org; Sun, 04 May 2025 23:09:49 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DE7C74417BD; Sun, 4 May 2025 23:09:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1746414577; bh=2veSrEpEXaZ78tt/rQxYwhNTNkVE13LRSHEVE0QzQVw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=VdGr3DtCJJs5DeIrehdiYfvk1M/t9oObJFDO34efmg7FaMSa+9LrVu4pDAiHEHbD7 ynonm0U0HHZh2yEb7vux1Z1V77sa0xWn2ue2BWrhawO5KttaIbfFHB2F8bNVSEg26b F82MZWdWHzyPsx323VBAOYZCWLz0SCjo+30FfdglernypPzjijuE2sWaALpnCg+UJd ubX/1jxCEYXOnXftzBRUynJP3as67xVVOjfYwY4+VsdseToPqD3jQIcHPhO6kE6Naz Der/evobY8MMYQjdZ3pvBn32HKEVhZ8PpCAl0WmdLebN8gqeaTYcXnXDP6Mp/k5MHH FR6GdFuw363Ng== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A5245441797; Sun, 4 May 2025 23:09:37 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 66AA71204C9; Sun, 4 May 2025 23:09:37 -0400 (EDT) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications In-Reply-To: <874iy0cj1n.fsf@localhost> Message-ID: References: <87h621fybf.fsf@localhost> <87o6w8j40o.fsf@localhost> <874iy0h6bu.fsf@localhost> <87msbsffww.fsf@localhost> <874iy0cj1n.fsf@localhost> Date: Sun, 04 May 2025 23:09:30 -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.044 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: 78221 Cc: 78221@debbugs.gnu.org, Alan Mackenzie 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 (---) >>> - org-display-custom-time >> AFAICT this is called exclusively from font-lock, so >> `inhibit-modifications-hooks` should always be set already. > I was close. `org-toggle-timestamp-overlays' (just above). I see. I think this one would definitely benefit from a bit of `with-silent-modifications` (currently, I suspect that a sequence like open a file + call `org-toggle-timestamp-overlays` + call `undo` can result in the `buffer-modified-p` flag being unwittingly set, and maybe also the timestamp "overlays" may have reappeared). Then again, I suspect this code needs to be moved to `org-remove-font-lock-display-properties` anyway, otherwise the `display` property might "stick" even after the user modifies the text into something that's not a timestamp any more. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri May 09 12:15:22 2025 Received: (at 78221) by debbugs.gnu.org; 9 May 2025 16:15:22 +0000 Received: from localhost ([127.0.0.1]:38777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uDQNe-0005CC-AT for submit@debbugs.gnu.org; Fri, 09 May 2025 12:15:22 -0400 Received: from mail.muc.de ([193.149.48.3]:59894) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uDQNb-0005BJ-I3 for 78221@debbugs.gnu.org; Fri, 09 May 2025 12:15:20 -0400 Received: (qmail 54477 invoked by uid 3782); 9 May 2025 18:15:13 +0200 Received: from muc.de (p4fe158d5.dip0.t-ipconnect.de [79.225.88.213]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 09 May 2025 18:15:12 +0200 Received: (qmail 28385 invoked by uid 1000); 9 May 2025 16:15:12 -0000 Date: Fri, 9 May 2025 16:15:12 +0000 To: Eli Zaretskii Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications Message-ID: References: <86cycqkwuu.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Ihor Radchenko , Stefan Monnier , =?iso-8859-1?Q?Jo=E3o_T=E1vora?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Sat, May 03, 2025 at 14:46:45 +0000, Alan Mackenzie wrote: [ .... ] > > Due to the Emacs's highly-recursive workings and the various hooks we > > have, which are ever-expanding, there's a virtually infinite number of > > situations where some code, called while a buffer-change operation is > > under way, itself calls a buffer-changing primitive, thus generating > > nested notifications. Finding and fixing all of theses situations one > > by one will take us infinite time, so I would like to consider more > > practical alternatives. And for that, IMO we need a very good > > understanding of the problems they cause. > As I proposed in my reply to Stefan M., I don't think finding most/all of > these situations need be too difficult. insdel.c could be temporarily > instrumented to signal an error on detecting an illegitimate buffer > change. The difficulty here might be false positives, when a program > intends to make buffer changes from inside a change hook function. I > don't think these are common, though. I no longer think we've got a systematic way of detecting all these errors. But... I instrumented insdel.c in this way on a slightly outdated code base. (In particular, signal_before_change and signal_after_change were modified to detect nested calls to *-change-functions.) I put Stefan's recent amendment to editfns-tests.el into the mix, too. Then I ran the test suite. The instrumentation detected _only_ the error highlighted by that change to editfns-tests.el, no others. It seems that nested calls of *-change-functions are rare indeed. Again, I think that the complications of handling the nested calls would not be justified by the small number, possibly zero, of such bugs still in the code. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon May 12 23:48:40 2025 Received: (at 78221) by debbugs.gnu.org; 13 May 2025 03:48:40 +0000 Received: from localhost ([127.0.0.1]:56785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uEgdA-0005ve-Nq for submit@debbugs.gnu.org; Mon, 12 May 2025 23:48:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62943) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uEgd6-0005vD-Rj for 78221@debbugs.gnu.org; Mon, 12 May 2025 23:48:33 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CF5B7441499; Mon, 12 May 2025 23:48:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1747108105; bh=hM4/v4UQfzl6fGwqvY1wed+jgmveaEsdjujwJQnPpk4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UDZBt/HQbLN/LNDwPd+PZx9VF8WvwYkpbLAfqtyevbyRsiWscEqVhOkHa0U5XTlm2 4O1VsDorcKsAfvvwPB928GM1XqTe2JjE6pPvnIq+MkQ7CvtcNgpLyFHqXhU5fFIhFJ Bysvm9b2rqxH2PqfstH9+plutuWIb3u64Ul+cTUDeQYK0VhHYTpJZVrRWS7cw3JQTI zxWRThOsikVulzI0APgOw4Lo5GnG47QQ8/g0IFTbpH+ikFGH12Dfb4F1r1kL/yDplR ju1N7PKqoB00KLLyYrcb1raTXQ1mXttLEfxgvpVdB+YP2T6nx3H49z4v5kNalj+2rm WSfj5QFQdf54Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 55722440BE8; Mon, 12 May 2025 23:48:25 -0400 (EDT) Received: from pastel (104-195-232-56.cpe.teksavvy.com [104.195.232.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AF3B0120426; Mon, 12 May 2025 23:48:24 -0400 (EDT) From: Stefan Monnier To: Alan Mackenzie Subject: `inhibit-recording-text-property-changes` In-Reply-To: Message-ID: References: Date: Mon, 12 May 2025 23:48:16 -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.297 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 GB_SUBJ25 0.5 Subject with no Spaces X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , Ihor Radchenko , =?windows-1252?B?Sm/jbyBU4XZvcmE=?= 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 (---) >> - Don't notify changes to text-properties. >> Currently, things like `put-text-property` run the *-change-functions >> like any other buffer modification. In practice this is of dubious value: >> - It's already the case that most calls to `put-text-property` and >> friends don't cause any notification because they are wrapped within >> a `with-silent-modifications` or otherwise take place from code >> which always runs with `inhibit-modification-hooks` set >> (e.g. because it's run from a *-change-function). >> So *-change-functions can't reliably track changes to text-properties. >> - Most *-change-functions are *not* interested in text-property >> changes anyway. >> The above two points suggest maybe we could just refrain from >> running *-change-functions when changing the text-properties (just >> like we do for changes to overlay properties). >> Then again, this would be a backward-incompatible change, so there's >> a chance some packages out there would be negatively affected. >> Another option would be to allow packages to choose whether to receive >> notifications like now or only for changes to the text. >> E.g. just like we have `buffer-modified-tick` and >> `buffer-chars-modified-tick`, we could have `*-change-functions` >> and `*-chars-change-functions` (with some questions remaining about >> `first-change-hook` and the `modification-hooks` property). >> Or we could rely on a (symbol) property being set on the functions >> added to `*-change-functions` to tell whether they want to know about >> changes to text-properties or not. >> Or maybe a more crude way would be a buffer-local variable controlling >> whether `*-change-functions` are called for text-property changes. > > I think it was a mistake in the beginning to have text property > modifications trigger before/after-c-f. +1 > But seeing it's been that way for so long, I don't think it would be > a good idea to change it now. The more I look at it, the more I see it as a serious mistake, indeed. I still have not found a single *-change-function that needs to know about text-property changes. On the contrary, I see that most code that changes text-properties wraps those changes in `with-silent-modifications` to avoid the various undesirable side-effects of treating text-properties as being part of the text. Actually, the whole purpose of `with-silent-modifications` is to work around that historical mistake. Of all the code that touches text-properties I see that the majority is wrapped (directly or indirectly) in `with-silent-modifications`, and of the remaining ones, the majority would actually benefit from being wrapped as well (the authors just haven't bumped (yet) into the downsides). The only case I have found so far where we do want to record text-property changes (not to run *-change-functions, but to mark the buffer as modified and to record the changes in the undo-list) is the `enriched-mode`. For that single use case the rest of ELisp code has had to pay the complexity cost of `with-silent-modifications` (which is delicate to use since its effect is nasty if you do modify the buffer's text) plus the occasional performance cost of uselessly running the *-change-functions and wasting memory by recording those changes on the undo-list (not to mention the occasional breakage of promises of how *-change-functions are run). AFAICT, in the long term, ELisp code would benefit from fixing that historical mistake. I suggest we introduce a new boolean variable `inhibit-recording-text-property-changes`: if nil we get the current behavior, but if non-nil then all text-property modifications are implicitly wrapped in a `with-silent-modifications`: they don't change the modified-p flag, they don't change the undo list, they don't run any modification hooks. I'd expect it to default to nil (for obvious backward compatibility reasons), and major modes can set it buffer-locally to t. Eventually, I'd hope even `enriched-mode` will set it to t, and will instead record the text-property changes "by hand". Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue May 13 00:12:51 2025 Received: (at 78221) by debbugs.gnu.org; 13 May 2025 04:12:52 +0000 Received: from localhost ([127.0.0.1]:56878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uEh0d-0007J9-Ag for submit@debbugs.gnu.org; Tue, 13 May 2025 00:12:51 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:34652) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uEh0a-0007Iy-6l for 78221@debbugs.gnu.org; Tue, 13 May 2025 00:12:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sLHYO2bqCHYRGjH0RSPk7ZXThJNN0i9agvh3Ok9XVac=; b=EnQ3hARsN5EWvy4iLK2O2Icokj uWEDM2mrfA7jKw9XYbJQOjWhaIC08R2h6gE9HCX32T771eE7gXcHcy/GYrgxy8hhNT37YEefuj/yW 2XNWzQZFn/Ah32AmzaMGz/lqSVj/y0Gz/DjPjw3mQerGnUCe37GTV97ExyBP+o9N0WLv9DJPxrlEs kYdNsqVtKjYxVt1IBdoGuxWPbolV7AT4VvIzXkmxmApu/OsR//j3jDVyf90X9E/YG5l9xCVzPQcYy wRbW+1husuc/KAv6FqvYhwKPq/UFaKntonKoWUvxHseRU/p14fclLMDmHH3USbFnCz+c9Hue/Qk2C g8nSbr1A==; Received: from [2600:1010:b00c:6148:0:60:29d2:a201] (port=52570 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uEgzP-009bc5-1x; Tue, 13 May 2025 00:11:35 -0400 Date: Mon, 12 May 2025 21:12:29 -0700 From: Daniel Colascione To: Stefan Monnier , "Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors" , Alan Mackenzie Subject: Re: bug#78221: `inhibit-recording-text-property-changes` User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <76F71E7F-A43D-4124-9203-F55DB5EE71BB@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , Ihor Radchenko , =?ISO-8859-1?Q?Jo=E3o_T=E1vora?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On May 12, 2025 8:48:16 PM PDT, "Stefan Monnier via Bug reports for GNU Em= acs, the Swiss army knife of text editors" wrote: >>> - Don't notify changes to text-properties=2E >>> Currently, things like `put-text-property` run the *-change-function= s >>> like any other buffer modification=2E In practice this is of dubiou= s value: >>> - It's already the case that most calls to `put-text-property` and >>> friends don't cause any notification because they are wrapped with= in >>> a `with-silent-modifications` or otherwise take place from code >>> which always runs with `inhibit-modification-hooks` set >>> (e=2Eg=2E because it's run from a *-change-function)=2E >>> So *-change-functions can't reliably track changes to text-propert= ies=2E >>> - Most *-change-functions are *not* interested in text-property >>> changes anyway=2E >>> The above two points suggest maybe we could just refrain from >>> running *-change-functions when changing the text-properties (just >>> like we do for changes to overlay properties)=2E >>> Then again, this would be a backward-incompatible change, so there's >>> a chance some packages out there would be negatively affected=2E >>> Another option would be to allow packages to choose whether to recei= ve >>> notifications like now or only for changes to the text=2E >>> E=2Eg=2E just like we have `buffer-modified-tick` and >>> `buffer-chars-modified-tick`, we could have `*-change-functions` >>> and `*-chars-change-functions` (with some questions remaining about >>> `first-change-hook` and the `modification-hooks` property)=2E >>> Or we could rely on a (symbol) property being set on the functions >>> added to `*-change-functions` to tell whether they want to know abou= t >>> changes to text-properties or not=2E >>> Or maybe a more crude way would be a buffer-local variable controlli= ng >>> whether `*-change-functions` are called for text-property changes=2E >> >> I think it was a mistake in the beginning to have text property >> modifications trigger before/after-c-f=2E > >+1 The idea, I think, was for users to directly manipulate text properties to= attach semantic information=2E That's why=20 In practice, text properties ended up being volatile implementation detail= s=2E I think XEmacs got this more right by directly exposing intervals (which w= e have anyway) as extents=2E Water under the bridge now=2E=20 > >> But seeing it's been that way for so long, I don't think it would be >> a good idea to change it now=2E > >The more I look at it, the more I see it as a serious mistake, indeed=2E >I still have not found a single *-change-function that needs to know >about text-property changes=2E > >On the contrary, I see that most code that changes text-properties >wraps those changes in `with-silent-modifications` to avoid the various >undesirable side-effects of treating text-properties as being part of >the text=2E Actually, the whole purpose of `with-silent-modifications` i= s >to work around that historical mistake=2E > >Of all the code that touches text-properties I see that the majority is >wrapped (directly or indirectly) in `with-silent-modifications`, and of >the remaining ones, the majority would actually benefit from being >wrapped as well (the authors just haven't bumped (yet) into the >downsides)=2E > >The only case I have found so far where we do want to record >text-property changes (not to run *-change-functions, but to mark the >buffer as modified and to record the changes in the undo-list) is the >`enriched-mode`=2E Can we just delete enriched mode? Good idea, but the world ended up going = in a different direction=2E >For that single use case the rest of ELisp code has had to pay the >complexity cost of `with-silent-modifications` (which is delicate to use >since its effect is nasty if you do modify the buffer's text) plus the >occasional performance cost of uselessly running the *-change-functions >and wasting memory by recording those changes on the undo-list (not to >mention the occasional breakage of promises of how *-change-functions >are run)=2E > >AFAICT, in the long term, ELisp code would benefit from fixing that >historical mistake=2E > >I suggest we introduce a new boolean variable >`inhibit-recording-text-property-changes`: if nil we get the current >behavior, but if non-nil then all text-property modifications are >implicitly wrapped in a `with-silent-modifications`: they don't change >the modified-p flag, they don't change the undo list, they don't run any >modification hooks=2E > >I'd expect it to default to nil (for obvious backward compatibility >reasons), and major modes can set it buffer-locally to t=2E Eventually, >I'd hope even `enriched-mode` will set it to t, and will instead record >the text-property changes "by hand"=2E Minor modes might need it too=2E I think it's fine to add a new hook varia= ble, but I don't think it's safe or even especially convenient (relative to= the new variable) to have something that changes the behavior of existing = code at a distance=2E=20 And speaking of hindsight: if we're going to add a new hook variable, how = about making it a function compatible with add-function and such instead of= a list of functions? From debbugs-submit-bounces@debbugs.gnu.org Tue May 13 08:00:03 2025 Received: (at 78221) by debbugs.gnu.org; 13 May 2025 12:00:04 +0000 Received: from localhost ([127.0.0.1]:58446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uEoIg-0001cC-Tg for submit@debbugs.gnu.org; Tue, 13 May 2025 08:00:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59512) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uEoIa-0001a0-8O for 78221@debbugs.gnu.org; Tue, 13 May 2025 07:59:56 -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 1uEoIS-0003LE-JA; Tue, 13 May 2025 07:59:44 -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=Bg/k3x0jXvm55IzrhKdb9cFCQ1OhcShy3rFIWPRY2RY=; b=gKfvacdnR7MkpP1W4iY2 tebWI8oDvv8v3CGlvx2FM3AH5cB10J+2q+ogEphI1yY6W5hq3hof+3/929p1Be6tLRpSY7OoGJk64 WwlocMbEfHNn7mz/nmgYNU6WHX5lW/X5vIS/m5oCKdxs4nY+ai3gPOZuiXZuIq7NUFUPnKJCFOf7w 1qIRiI+zewdTNZhyhxqAsSXazXmTVzMS7wP8PlKZoiTGfgIkR6Ka5iOrAKb8TXOQd5KRXmbqhD+28 Y3oo7cUKc7uykd5RDau6Mg0kD2+F16HuAX2yYJ+yK7Vu/+mHZe+xBxvF7ydVb5NELhVHlRo5gjfpe MtustiyWTi7S7A==; Date: Tue, 13 May 2025 14:59:36 +0300 Message-Id: <86zffg67rr.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Mon, 12 May 2025 23:48:16 -0400) Subject: Re: `inhibit-recording-text-property-changes` References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: acm@muc.de, yantar92@posteo.net, joaotavora@gmail.com, 78221@debbugs.gnu.org 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: 78221@debbugs.gnu.org, Eli Zaretskii , Ihor Radchenko > , João Távora > > Date: Mon, 12 May 2025 23:48:16 -0400 > > I suggest we introduce a new boolean variable > `inhibit-recording-text-property-changes`: if nil we get the current > behavior, but if non-nil then all text-property modifications are > implicitly wrapped in a `with-silent-modifications`: they don't change > the modified-p flag, they don't change the undo list, they don't run any > modification hooks. I don't have a firm opinion on whether we should introduce this, let alone if this was a "historical mistake" (at least conceptually, since properties are part of buffer text, it follows that any change in them is like changes in the text itself). But if we do decide to introduce this variable, it should not be a simple boolean, but it should also be possible to set it to a list of properties whose changes are not inhibited from producing buffer-change notifications. This is because (a) that's the Emacsy way of handling similar features, and (b) it seems to me that you mainly have simple properties like faces in mind, whereas the Emacs text properties can be very different in purpose, as Daniel points out. It is quite possible that some application, or even Emacs in general, would want certain properties to always generate notifications, even if all the rest don't. I believe Org uses many different properties for many purposes, so perhaps Ihor could comment from Org perspective. P.S. I don't think such a significant feature should be discussed on the bug tracker. The right place is emacs-devel. From debbugs-submit-bounces@debbugs.gnu.org Tue May 13 08:10:06 2025 Received: (at 78221) by debbugs.gnu.org; 13 May 2025 12:10:06 +0000 Received: from localhost ([127.0.0.1]:58502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uEoST-0002EU-Ic for submit@debbugs.gnu.org; Tue, 13 May 2025 08:10:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55740) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uEoSP-0002Di-8s for 78221@debbugs.gnu.org; Tue, 13 May 2025 08:10:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uEoSI-0004YU-Go; Tue, 13 May 2025 08:09:54 -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=tFP5bz16XSPBO6EqpLxoaETkU7mE0mEE+q6mVoCCmKM=; b=VvPhHSA3ARD3u9N0i24m 7m5gRGd4BoiC0xlYomZarDdL0d+Yo6rdHT9tI9BafEnMjulIG+RG0TlhD8ZEh8K8X+FvZFZz2aPLF E7/VXgTG0QKBXPhBfjEHs4cbssqEMNZvHGKWKVGKuu7uxrR2U57S9w4jzGx1J9FUMGPOfP7mY/6bO BKuk1lkejKtIxXrZFZzoLW37jdpgv4h6Ow9xwd11rtyroAxZfPi6ulhbnUTeLvZzHfG6wui5yPWw7 IKf+3M970LALdbIHBT8ylheJRZU3TFkk8LjSg0WxRYnu1Cu8vE+gfduqZRxTAtqEgoZPOBj9uOWpJ kLMiqcjfEuvgmA==; Date: Tue, 13 May 2025 15:09:10 +0300 Message-Id: <86y0v067bt.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <76F71E7F-A43D-4124-9203-F55DB5EE71BB@dancol.org> (message from Daniel Colascione on Mon, 12 May 2025 21:12:29 -0700) Subject: Re: bug#78221: `inhibit-recording-text-property-changes` References: <76F71E7F-A43D-4124-9203-F55DB5EE71BB@dancol.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, yantar92@posteo.net, monnier@iro.umontreal.ca 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 (---) > Date: Mon, 12 May 2025 21:12:29 -0700 > From: Daniel Colascione > CC: 78221@debbugs.gnu.org, Eli Zaretskii , > Ihor Radchenko , > João Távora > > >The only case I have found so far where we do want to record > >text-property changes (not to run *-change-functions, but to mark the > >buffer as modified and to record the changes in the undo-list) is the > >`enriched-mode`. > > Can we just delete enriched mode? Good idea, but the world ended up going in a different direction. This is a tangent, but I don't see any sense in deleting enriched-mode. It's a stand-alone mode, which doesn't impose any requirements on the rest of Emacs, and consumes almost no maintenance (grand total of 10 real changes in the last 10 years). OTOH, it provides a ready-to-use infrastructure for any feature that wants to make text properties persistent. We needed that for etc/HELLO (to avoid the need to encode it in ISO 2022 so as to preserve the charset information), and it was very easy to leverage it for that purpose. If enriched-mode didn't exist back then, we'd have a much harder problem to solve. From debbugs-submit-bounces@debbugs.gnu.org Tue May 13 17:06:07 2025 Received: (at 78221) by debbugs.gnu.org; 13 May 2025 21:06:07 +0000 Received: from localhost ([127.0.0.1]:35229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uEwpC-0004Zx-P1 for submit@debbugs.gnu.org; Tue, 13 May 2025 17:06:07 -0400 Received: from mail.muc.de ([193.149.48.3]:56109) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uEwp8-0004Z5-UL for 78221@debbugs.gnu.org; Tue, 13 May 2025 17:06:05 -0400 Received: (qmail 62522 invoked by uid 3782); 13 May 2025 23:05:56 +0200 Received: from muc.de (pd953a7c2.dip0.t-ipconnect.de [217.83.167.194]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 13 May 2025 23:05:55 +0200 Received: (qmail 30146 invoked by uid 1000); 13 May 2025 21:05:55 -0000 Date: Tue, 13 May 2025 21:05:55 +0000 To: Stefan Monnier Subject: Re: `inhibit-recording-text-property-changes` Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 78221 Cc: 78221@debbugs.gnu.org, Eli Zaretskii , Ihor Radchenko , =?iso-8859-1?Q?Jo=E3o_T=E1vora?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, May 12, 2025 at 23:48:16 -0400, Stefan Monnier wrote: > >> - Don't notify changes to text-properties. > >> Currently, things like `put-text-property` run the *-change-functions > >> like any other buffer modification. In practice this is of dubious value: > >> - It's already the case that most calls to `put-text-property` and > >> friends don't cause any notification because they are wrapped within > >> a `with-silent-modifications` or otherwise take place from code > >> which always runs with `inhibit-modification-hooks` set > >> (e.g. because it's run from a *-change-function). > >> So *-change-functions can't reliably track changes to text-properties. > >> - Most *-change-functions are *not* interested in text-property > >> changes anyway. > >> The above two points suggest maybe we could just refrain from > >> running *-change-functions when changing the text-properties (just > >> like we do for changes to overlay properties). > >> Then again, this would be a backward-incompatible change, so there's > >> a chance some packages out there would be negatively affected. > >> Another option would be to allow packages to choose whether to receive > >> notifications like now or only for changes to the text. > >> E.g. just like we have `buffer-modified-tick` and > >> `buffer-chars-modified-tick`, we could have `*-change-functions` > >> and `*-chars-change-functions` (with some questions remaining about > >> `first-change-hook` and the `modification-hooks` property). > >> Or we could rely on a (symbol) property being set on the functions > >> added to `*-change-functions` to tell whether they want to know about > >> changes to text-properties or not. > >> Or maybe a more crude way would be a buffer-local variable controlling > >> whether `*-change-functions` are called for text-property changes. > > I think it was a mistake in the beginning to have text property > > modifications trigger before/after-c-f. > +1 > > But seeing it's been that way for so long, I don't think it would be > > a good idea to change it now. > The more I look at it, the more I see it as a serious mistake, indeed. > I still have not found a single *-change-function that needs to know > about text-property changes. I can't actually feel terribly strongly about it. I think it was a mistake, but not all that serious. > On the contrary, I see that most code that changes text-properties > wraps those changes in `with-silent-modifications` to avoid the various > undesirable side-effects of treating text-properties as being part of > the text. Actually, the whole purpose of `with-silent-modifications` is > to work around that historical mistake. > Of all the code that touches text-properties I see that the majority is > wrapped (directly or indirectly) in `with-silent-modifications`, and of > the remaining ones, the majority would actually benefit from being > wrapped as well (the authors just haven't bumped (yet) into the > downsides). > The only case I have found so far where we do want to record > text-property changes (not to run *-change-functions, but to mark the > buffer as modified and to record the changes in the undo-list) is the > `enriched-mode`. > For that single use case the rest of ELisp code has had to pay the > complexity cost of `with-silent-modifications` (which is delicate to use > since its effect is nasty if you do modify the buffer's text) plus the > occasional performance cost of uselessly running the *-change-functions > and wasting memory by recording those changes on the undo-list (not to > mention the occasional breakage of promises of how *-change-functions > are run). > AFAICT, in the long term, ELisp code would benefit from fixing that > historical mistake. I think in the long term, you're right. But in the short and medium term (up to ~15 years from now) .... > I suggest we introduce a new boolean variable > `inhibit-recording-text-property-changes`: if nil we get the current > behavior, but if non-nil then all text-property modifications are > implicitly wrapped in a `with-silent-modifications`: they don't change > the modified-p flag, they don't change the undo list, they don't run any > modification hooks. ....., I think the extra complexity will cause confusion. It will cause bugs, too. The situation with text properties is already complicated enough, and the extra flag will be adding to the already great weight of Emacs complexity, something which impedes all of us, especially beginners, in modifying Emacs. So, on balance, I'm against this new mechanism. I don't feel at all strongly about it, though. > I'd expect it to default to nil (for obvious backward compatibility > reasons), and major modes can set it buffer-locally to t. Eventually, > I'd hope even `enriched-mode` will set it to t, and will instead record > the text-property changes "by hand". > Stefan -- Alan Mackenzie (Nuremberg, Germany).