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?