GNU bug report logs - #25111
How modification-hooks let-bind inhibit-modification-hooks?

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Phillip Lord <phillip.lord <at> russet.org.uk>, Noam Postavsky <npostavs <at> gmail.com>, 25111 <at> debbugs.gnu.org
Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks)
Date: Mon, 3 Jun 2019 19:15:49 +0000

Hello, Eli.

To recap, the problem we were talking about was the modification-hooks
overlay property, whose value is a function which gets called before and
after modification of the text under an overlay.

When such a function gets called, inhibit-modification-hooks is left at
nil.  When the other four similar overlay/text-property "change
functions" get called, inhibit-modification-hooks gets bound to t.

This is difficult to document coherently.  My proposal of last week was
to fix the code, also to bin inhibit-modification-hooks to t for the
modification-hooks overlay property, even though this would be an
incompatibility in Lisp.

Ping?  ----------------------------->-----------------------------------
                                                                       |
On Mon, May 27, 2019 at 14:31:09 +0000, Alan Mackenzie wrote:          |
> Hello, Noam.                                                         |
                                                                       |
> On Sat, May 25, 2019 at 10:36:55 -0400, Noam Postavsky wrote:        |
> > Alan Mackenzie <acm <at> muc.de> writes:                                |
                                                                       |
> > >>> @@ -3621,9 +3621,14 @@ Special Properties                      |
                                                                       |
> > >>> +When Emacs calls these functions, @code{inhibit-modification-hooks} is
> > >>> +set to @code{nil}.                                            |
                                                                       v
> > >> As Phillip mentioned in the OP, Emacs in fact binds it to t.    |
                                                                       |
> > > Are you sure?  We're talking here about the text property (in which I
> > > think inhibit-modification-hooks IS at nil) as opposed to the overlay
> > > property (where inhibit-modification-hooks is bound to t).       |
                                                                       |
> > Oh, you're quite right.  Here's some test code:                    |
                                                                       |
> [ .... ]                                                             |
                                                                       |
                                                                       |
> > Which produces this:                                               |
                                                                       |
> > mod-hook-text-prop (1 4), inhibit? nil                             |
> > mod-hook-change-fun (1 4), inhibit? t                              |
> > mod-hook-ov-prop (#<overlay from 1 to 5 in *test*> nil 1 4), inhibit? t
> > mod-hook-change-fun (1 1 3), inhibit? t                            |
> > mod-hook-ov-prop (#<overlay from 1 to 2 in *test*> t 1 1 3), inhibit? t
> > mod-hook-change-fun (1 1), inhibit? t                              |
> > mod-hook-change-fun (1 4 0), inhibit? t                            |
                                                                       |
> > I think we need to emphasize the difference in this case, it's rather
> > confusing.                                                         |
                                                                       V
> Alternatively, we could perhaps regard the first of these results (for
> modification-hooks) as a bug in the code, which seems like it ought to be
> binding inhibit-modification-hooks to non-nil like the others.  Maybe we
> should amend the code, even though this would be a jarring
> incompatibility with previous Emacs versions.  Eli?

> [ .... ]

> > I've updated the patch based on your and Eli's feedback.

> Yes, I agree that "confusing the internal mechanism" is unhelpful here.
> Thanks for getting rid of it.

> [ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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