bug#35316: 26.2; Emacs lags in c++-mode buffer when editing with iedit-mode on

[Alan Mackenzie]

Hello, Noam.

On Sun, May 19, 2019 at 09:20:16 -0400, Noam Postavsky wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >  (defun iedit-update-occurrences-2 (occurrence after beg end &optional 
> > change)
> >    ""
> > -  (let ((inhibit-modification-hooks t)
> > +  (let (;; (inhibit-modification-hooks t)
> > +        ;; Note: `inhibit-modification-hook' will already be non-nil when 
> > this
> > +   ;; function is called.  Setting it to nil here doesn't work.

> By "doesn't work", do you mean that it would trigger an infloop?

It would trigger a binding stack overflow.  (It did when I tried it.)
iedit-update-occurrences-2 is (a subroutine of) the handler for the
modification-hooks property of the overlay at point.  It performs buffer
modifications on the other overlays.  If inhibit-modification-hooks is
bound to nil, these other modifications in their turn cause
iedit-update-occurrences-2 to get called recursively.

> Would something like this work:

>     (defvar iedit-inhibit-update nil)

>     (defun iedit-update-occurrences-2 (occurrence after beg end &optional 
> change)
>      ...
>      ;; Let other modification hooks run, but don't recurse infinitely.
>      (unless iedit-inhibit-update
>        (let ((inhibit-modification-hooks nil)
>              (iedit-inhibit-update t))
>        ...

I haven't actually tried it, but gut feeling says this approach might be
problematic.  It could end up inserting into/deleting from each overlay
many times.  Or some of the insertions/deletions wouldn't get the change
hooks called for them, depending on how the rest of the code is split
into the two "..."s.

It might also be even less clean than the explicit calls to
before/after-change-functions.

> See also Bug#25111 "How modification-hooks let-bind
> inhibit-modification-hooks?" https://debbugs.gnu.org/25111

Thanks.  I was considering raising the same issue in a bug myself.
#25111 is still open, I think (the web interface doesn't explicitly
say), and I think the doc is objectively wrong.  It doesn't state that
when modification-hooks is called, inhibit-modification-hooks has
already been set to non-nil.  That was what caught me out when I wrote
the previous (garbage) patch on ?Thursday.

-- 
Alan Mackenzie (Nuremberg, Germany).