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

[Alan Mackenzie]

Hello, Zhang.

On Thu, May 16, 2019 at 15:46:33 +0000, Zhang Haijun wrote:


> > 在 2019年5月16日，下午11:04，Alan Mackenzie <acm@muc.de> 写道：

> > The problem is in the function iedit-update-occurrences-2.  There,
> > inhibit-modification-hooks is bound to t, and the many changes are made.
> > The hook after-change-functions is called explicitly after each change.

> > But before-change-functions is not called in this loop.  This is a very
> > bad idea.  Unlike many modes, CC Mode has critical parts of its
> > functionality in the before-change-functions hook, and depends on this
> > hook and after-change-functions both being called for each change.

> > When CC Mode detects after-change-functions being called without
> > before-..., it enlarges the region to the whole buffer, calls
> > c-before-change with this enlarged region, finally proceding with the
> > rest of c-after-change.  It does this to protect its buffer's integrity.


> It seems that this leads too much redundant work.

What iedit-mode is doing with after-change-functions is definitely wrong,
and will lead to misfunctioning in any major mode which uses
before-change-functions, as CC Mode does.

> > So, the lag with the multiple cursors is being caused by processing the
> > entire buffer for each cursor, rather than just part of the buffer
> > involved.

> > So, why are you binding inhibit-modification-hooks to t and calling
> > after-change-functions this way?  Why not just let the modification hooks
> > run in the normal fashion?  What is it about before-change-functions
> > which is bad in iedit-mode?

> I’m not the developer of iedit.

Would you please consider forwarding this email to the maintainer of
iedit.  Thanks!

> I find a comment in the function iedit-update-occurrences-2:

>                 ;; todo: reconsider this change Quick fix for
>                 ;; multi-occur occur-edit-mode: multi-occur depend on
>                 ;; after-change-functions to update original
>                 ;; buffer. Since inhibit-modification-hooks is set to
>                 ;; non-nil, after-change-functions hooks are not going
>                 ;; to be called for the changes of other occurrences.
>                 ;; So run the hook here.

I saw this comment too.  I had a look at the repository on github, and
this handling of after-change-functions has been there since at least
2012.  :-(

When I comment out the offending bits of code from
iedit-update-occurrences-2, like this:



--- iedit-lib.el~       2019-04-19 08:03:29.000000000 +0000
+++ iedit-lib.el        2019-05-16 15:58:27.158575662 +0000
@@ -490,7 +490,7 @@
 
 (defun iedit-update-occurrences-2 (occurrence after beg end &optional change)
   ""
-  (let ((inhibit-modification-hooks t)
+  (let (;; (inhibit-modification-hooks t)
         (offset (- beg (overlay-start occurrence)))
         (value (buffer-substring-no-properties beg end)))
     (save-excursion
@@ -509,10 +509,11 @@
                 ;; non-nil, after-change-functions hooks are not going
                 ;; to be called for the changes of other occurrences.
                 ;; So run the hook here.
-                (run-hook-with-args 'after-change-functions
-                                    beginning
-                                    ending
-                                    change))
+                ;; (run-hook-with-args 'after-change-functions
+                ;;                     beginning
+                ;;                     ending
+                ;;                     change)
+               )
               (iedit-move-conjoined-overlays another-occurrence)))
         ;; deletion
         (dolist (another-occurrence (remove occurrence 
iedit-occurrences-overlays))
@@ -521,10 +522,11 @@
             (unless (eq beg end) ;; replacement
               (goto-char beginning)
               (insert-and-inherit value))
-            (run-hook-with-args 'after-change-functions
-                                beginning
-                                (+ beginning (- beg end))
-                                change)))))))
+            ;; (run-hook-with-args 'after-change-functions
+            ;;                     beginning
+            ;;                     (+ beginning (- beg end))
+            ;;                     change)
+           ))))))
 
 (defun iedit-next-occurrence ()
   "Move forward to the next occurrence in the `iedit'.



, then iedit-mode and C++ Mode work well together.  In a C++ Mode test
buffer, just over 16k long, on a variable with 75 copies in it, I press
C-;.  On editing the copies of these variables, the response is now
instantaneous.

The question remaining is what was the problem which led to this mistaken
after-change-functions handling?  Is this problem still there?

-- 
Alan Mackenzie (Nuremberg, Germany).