The author of iedit seems not too active(not everyday) on github. Here is the email on his account info of github: victorhge@gmail.com. However, the gmail is blocked in china(the page shows that he is in china). I don't known if he can read the mail. Besides iedit, I tried with multiple-cursors(https://github.com/magnars/multiple-cursors.el) with the similar editing operation. It works well(no obvious lags). »ρΘ‘ Outlook for Android ________________________________ From: Alan Mackenzie Sent: Sunday, May 19, 2019 7:40:19 PM To: Amos Bird; Zhang Haijun Cc: 35316@debbugs.gnu.org Subject: Re: bug#35316: 26.2; Emacs lags in c++-mode buffer when editing with iedit-mode on Hello, Amos and Zhang. First thing, apologies for the patch I sent you a few days ago. It was based on a misunderstanding, and it is total garbage! The misunderstanding was the assumption that `inhibit-modification-hooks' would be nil on entry to `iedit-update-occurrences-2', and that leaving it nil would allow the `before-change-functions' and `after-change-functions' hooks to run normally. In actual fact `inhibit-modification-hooks' is t at that point, and cannot successfully be bound to nil. So, both `before-change-functions' and `after-change-functions' need to be called explicitly for successful processing. So, please disregard that previous patch from me, and try out instead the patch below. In C++ Mode it is somewhat slower, since it is actually doing the change processing, but not unusably so. Undo seems to be working a bit faster too, though it is often not instantaneous as one would wish (see below). On Sat, May 18, 2019 at 01:35:58 +0800, Amos Bird wrote: > Hi Alan! > > Are we still talking about C++ Mode > Yeah it's c++ mode but it can also be reproduced with c mode. > The minute long frozen is caused mainly by the lsp-mode, howeveer > it's still laggy after turning lsp off. > > How big is your file? Can you characterise it in any way? > You can try emacs/src/xdisp.c . iediting all "make_fixnum", > turning them into "make_fixnum_why_undo_redo_is_so_slow", and > undo. > It's about 10-20 seconds freezing time here. When I do this now (with the patch in place), undo works in two stages, taking about 0.4s and 2.4s respectively on my machine. > > It seems I have more work to do on this in any case. As a matter of interest, could one of you please give me the name and email address of the iedit-mode maintainer. I haven't got a github account, and don't want to create one, so I don't think I can get in touch with her/him that way. > Looking forward to it! OK, here goes! --- iedit-lib.el.orig 2019-05-19 10:55:31.681959998 +0000 +++ iedit-lib.el 2019-05-19 11:08:27.549988930 +0000 @@ -490,7 +490,9 @@ (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. (offset (- beg (overlay-start occurrence))) (value (buffer-substring-no-properties beg end))) (save-excursion @@ -501,6 +503,9 @@ (ending (+ beginning (- end beg)))) (when (not (eq another-occurrence occurrence)) (goto-char beginning) + (run-hook-with-args 'before-change-functions + beginning + (+ beginning change)) (insert-and-inherit value) ;; todo: reconsider this change Quick fix for ;; multi-occur occur-edit-mode: multi-occur depend on @@ -517,13 +522,17 @@ ;; deletion (dolist (another-occurrence (remove occurrence iedit-occurrences-overlays)) (let ((beginning (+ (overlay-start another-occurrence) offset))) + (goto-char beginning) + (run-hook-with-args 'before-change-functions + beginning + (+ beginning change)) (delete-region beginning (+ beginning change)) (unless (eq beg end) ;; replacement (goto-char beginning) (insert-and-inherit value)) (run-hook-with-args 'after-change-functions beginning - (+ beginning (- beg end)) + (+ beginning (- end beg)) change))))))) (defun iedit-next-occurrence () > regards, > -- > Amos Bird > amosbird@gmail.com -- Alan Mackenzie (Nuremberg, Germany).