--- Begin Message ---
Subject: |
|
Date: |
Sun, 4 Dec 2016 20:53:24 -0000 |
User-agent: |
SquirrelMail/1.5.2 [SVN] |
The documentation for "modification-hooks" on overlays says:
If these functions modify the buffer, they should bind
‘inhibit-modification-hooks’ to ‘t’ around doing so, to avoid
confusing the internal mechanism that calls these hooks.
But as far as I can see, the only place these gets called
"signal_after_change"
and "signal_before_change", inhibit-modification-hooks is already specbound
to t, so this advice is unnecessary.
Also, the documentation for inhibit-modification-hooks says:
If you do want modification hooks to be run in a particular
piece of code that is itself run from a modification hook, then
rebind locally ‘inhibit-modification-hooks’ to ‘nil’.
which suggests that, in fact, it is possible to call the modification
hooks from inside another call to these functions.
This is true for both emacs-25 and master.
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#25111: (Inaccurate documentation of inhibit-modification-hooks) |
Date: |
Tue, 25 Jun 2019 09:17:09 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hello, Noam.
On Mon, Jun 24, 2019 at 18:48:14 -0400, Noam Postavsky wrote:
> Alan Mackenzie <address@hidden> writes:
[ .... ]
> > I think the changes as now formulated are right. Perhaps one or
> > both of you might like to give the following patch a quick review.
> > Thanks!
> Minor formatting nitpick:
> > +++ b/doc/lispref/display.texi
> > @@ -1752,9 +1752,12 @@ Overlay Properties
> > +When these functions are called, @code{inhibit-modification-hooks} is
> > +bound to non-@code{nil}. If the functions modify the buffer, you
> > +might want to bind @code{inhibit-modification-hooks} to nil, so as to
> ^^^
> > +cause the change hooks to run for these modifications. However, doing
> > +this may call your own change hook recursively, so be sure to prepare
> > +for that. @xref{Change Hooks}.
> > +++ b/doc/lispref/text.texi
> > @@ -3639,6 +3642,13 @@ Special Properties
> > beginning and end of the inserted text. The functions are called
> > @emph{after} the actual insertion takes place.
> > +When these functions are called, @code{inhibit-modification-hooks} is
> > +bound to non-@code{nil}. If the functions modify the buffer, you
> > +might want to bind @code{inhibit-modification-hooks} to nil, so as to
> ^^^
> @code{nil} for both of these, right? Otherwise looks good to me.
Whoops! Thanks for spotting these.
I've fixed them and committed the changes. I'm closing the bug with
this post.
--
Alan Mackenzie (Nuremberg, Germany).
--- End Message ---