GNU bug report logs - #78221
31.0.50; Improving *-change-functions notifications

Previous Next

Full log

Message #110 received at 78221 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: acm <at> muc.de, yantar92 <at> posteo.net, joaotavora <at> gmail.com,
 78221 <at> debbugs.gnu.org
Subject: Re: `inhibit-recording-text-property-changes`
Date: Tue, 13 May 2025 14:59:36 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 78221 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>,  Ihor Radchenko
>  <yantar92 <at> posteo.net>,  João Távora
>  <joaotavora <at> gmail.com>
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.