all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Zhang Haijun <ccsmile2008@outlook.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	"35316@debbugs.gnu.org" <35316@debbugs.gnu.org>
Subject: bug#35316: 26.2; Emacs lags in c++-mode buffer when editing with iedit-mode on
Date: Thu, 16 May 2019 16:17:04 +0000	[thread overview]
Message-ID: <20190516161704.GA527@ACM> (raw)
In-Reply-To: <PS1PR06MB2759849B039B99A23B463011A80A0@PS1PR06MB2759.apcprd06.prod.outlook.com>

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





  reply	other threads:[~2019-05-16 16:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5A24EADA-D920-4E1D-8CAE-511A6A74588C@outlook.com>
2019-04-19  0:22 ` bug#35316: 26.2; Emacs lags in c++-mode buffer when editing with iedit-mode on Zhang Haijun
2019-04-19  0:32   ` Zhang Haijun
2019-04-19 16:20     ` Stefan Monnier
2019-04-20  2:44       ` Zhang Haijun
2019-05-09 13:23         ` Zhang Haijun
2019-05-16 15:04   ` Alan Mackenzie
2019-05-16 15:46     ` Zhang Haijun
2019-05-16 16:17       ` Alan Mackenzie [this message]
2019-05-17  0:48         ` Zhang Haijun
2019-05-17  1:19         ` Amos Bird
2019-05-17 10:01           ` Alan Mackenzie
     [not found]           ` <20190517100118.GB5011@ACM>
2019-05-17 17:35             ` Amos Bird
2019-05-19 11:40               ` Alan Mackenzie
2019-05-19 13:20                 ` Noam Postavsky
2019-05-19 14:26                   ` Alan Mackenzie
2019-05-19 17:41                     ` Noam Postavsky
2019-05-19 13:51                 ` Zhang Haijun
2019-11-04  3:16                   ` Zhang Haijun
2020-09-20 17:59                     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190516161704.GA527@ACM \
    --to=acm@muc.de \
    --cc=35316@debbugs.gnu.org \
    --cc=ccsmile2008@outlook.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.