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

[Amos Bird <amosbird@gmail.com>]

Hello, this patch works as expected. Is there any similar 
technique I can apply to undo-tree? After modifying hundreds of 
copies using iedit, doing undo/redo freezes for several minutes.

regards,
Amos

Alan Mackenzie <acm@muc.de> writes:

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


--
Amos Bird
amosbird@gmail.com