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

Previous Next

Package: emacs;

Reported by: "Phillip Lord" <phillip.lord <at> russet.org.uk>

Date: Sun, 4 Dec 2016 20:55:01 UTC

Severity: minor

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 25111 <at> debbugs.gnu.org, Phillip Lord <phillip.lord <at> russet.org.uk>
Subject: bug#25111: (Inaccurate documentation of inhibit-modification-hooks)
Date: Mon, 27 May 2019 14:31:09 +0000
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}.

> >> 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.

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).




This bug report was last modified 6 years and 30 days ago.

Previous Next


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