From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs 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 Message-ID: <20190516161704.GA527@ACM> References: <20190516150457.GA639@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="203751"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Stefan Monnier , "35316@debbugs.gnu.org" <35316@debbugs.gnu.org> To: Zhang Haijun Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 16 18:18:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRJ5B-000qpx-UI for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 May 2019 18:18:14 +0200 Original-Received: from localhost ([127.0.0.1]:60709 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRJ5A-0008JV-L0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 May 2019 12:18:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:48131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRJ54-0008J6-99 for bug-gnu-emacs@gnu.org; Thu, 16 May 2019 12:18:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hRJ52-0001hI-RG for bug-gnu-emacs@gnu.org; Thu, 16 May 2019 12:18:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42631) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hRJ4z-0001ce-SQ; Thu, 16 May 2019 12:18:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hRJ4z-0002om-M8; Thu, 16 May 2019 12:18:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 16 May 2019 16:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35316 X-GNU-PR-Package: emacs,cc-mode Original-Received: via spool by 35316-submit@debbugs.gnu.org id=B35316.155802344010779 (code B ref 35316); Thu, 16 May 2019 16:18:01 +0000 Original-Received: (at 35316) by debbugs.gnu.org; 16 May 2019 16:17:20 +0000 Original-Received: from localhost ([127.0.0.1]:56173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRJ4K-0002nn-4s for submit@debbugs.gnu.org; Thu, 16 May 2019 12:17:20 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:45723 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hRJ4H-0002nc-Kb for 35316@debbugs.gnu.org; Thu, 16 May 2019 12:17:18 -0400 Original-Received: (qmail 4628 invoked by uid 3782); 16 May 2019 16:17:05 -0000 Original-Received: from acm.muc.de (p4FE15BED.dip0.t-ipconnect.de [79.225.91.237]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 16 May 2019 18:17:04 +0200 Original-Received: (qmail 1361 invoked by uid 1000); 16 May 2019 16:17:04 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159403 Archived-At: Hello, Zhang. On Thu, May 16, 2019 at 15:46:33 +0000, Zhang Haijun wrote: > > 在 2019年5月16日，下午11:04，Alan Mackenzie 写道： > > 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).