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

[Noam Postavsky]

Alan Mackenzie <acm@muc.de> writes:

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

Sorry, it was a bit unclear, the first "..." was just intended to be the
docstring.  I.e., the code I put in there should be at the top-level of
the function, and wrap the rest of the code.

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

Although it misses text property and overlay change hooks.

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

Yes, it's open.

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

Yeah, it's a tricky case.  The docs are definitely not adequate.