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: Sun, 19 May 2019 14:26:15 +0000 Message-ID: <20190519142615.GB5262@ACM> References: <20190516150457.GA639@ACM> <20190516161704.GA527@ACM> <871s0xop2o.fsf@gmail.com> <20190517100118.GB5011@ACM> <87lfz5c7b5.fsf@gmail.com> <20190519114019.GA5262@ACM> <877eamd1in.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="218680"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Amos Bird , 35316@debbugs.gnu.org, Zhang Haijun To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 19 16:27:13 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 1hSMmN-000uk5-S6 for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 May 2019 16:27:11 +0200 Original-Received: from localhost ([127.0.0.1]:49455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hSMmM-0002NL-Qm for geb-bug-gnu-emacs@m.gmane.org; Sun, 19 May 2019 10:27:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57275) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hSMmG-0002N4-01 for bug-gnu-emacs@gnu.org; Sun, 19 May 2019 10:27:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hSMmE-000204-Qe for bug-gnu-emacs@gnu.org; Sun, 19 May 2019 10:27:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49974) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hSMmE-0001zx-Mv; Sun, 19 May 2019 10:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hSMmE-00060i-HS; Sun, 19 May 2019 10:27:02 -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: Sun, 19 May 2019 14:27:02 +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.155827598723051 (code B ref 35316); Sun, 19 May 2019 14:27:02 +0000 Original-Received: (at 35316) by debbugs.gnu.org; 19 May 2019 14:26:27 +0000 Original-Received: from localhost ([127.0.0.1]:35282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hSMlf-0005zi-6N for submit@debbugs.gnu.org; Sun, 19 May 2019 10:26:27 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:14776 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hSMlc-0005zY-Ny for 35316@debbugs.gnu.org; Sun, 19 May 2019 10:26:25 -0400 Original-Received: (qmail 99456 invoked by uid 3782); 19 May 2019 14:26:20 -0000 Original-Received: from acm.muc.de (p2E5D561D.dip0.t-ipconnect.de [46.93.86.29]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 May 2019 16:26:18 +0200 Original-Received: (qmail 26517 invoked by uid 1000); 19 May 2019 14:26:15 -0000 Content-Disposition: inline In-Reply-To: <877eamd1in.fsf@gmail.com> 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:159542 Archived-At: Hello, Noam. On Sun, May 19, 2019 at 09:20:16 -0400, Noam Postavsky wrote: > Alan Mackenzie writes: > > (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. > By "doesn't work", do you mean that it would trigger an infloop? It would trigger a binding stack overflow. (It did when I tried it.) iedit-update-occurrences-2 is (a subroutine of) the handler for the modification-hooks property of the overlay at point. It performs buffer modifications on the other overlays. If inhibit-modification-hooks is bound to nil, these other modifications in their turn cause iedit-update-occurrences-2 to get called recursively. > Would something like this work: > (defvar iedit-inhibit-update nil) > (defun iedit-update-occurrences-2 (occurrence after beg end &optional change) > ... > ;; Let other modification hooks run, but don't recurse infinitely. > (unless iedit-inhibit-update > (let ((inhibit-modification-hooks nil) > (iedit-inhibit-update t)) > ... I haven't actually tried it, but gut feeling says this approach might be problematic. It could end up inserting into/deleting from each overlay many times. Or some of the insertions/deletions wouldn't get the change hooks called for them, depending on how the rest of the code is split into the two "..."s. It might also be even less clean than the explicit calls to before/after-change-functions. > See also Bug#25111 "How modification-hooks let-bind > inhibit-modification-hooks?" https://debbugs.gnu.org/25111 Thanks. I was considering raising the same issue in a bug myself. #25111 is still open, I think (the web interface doesn't explicitly say), and I think the doc is objectively wrong. It doesn't state that when modification-hooks is called, inhibit-modification-hooks has already been set to non-nil. That was what caught me out when I wrote the previous (garbage) patch on ?Thursday. -- Alan Mackenzie (Nuremberg, Germany).