From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Amos Bird Newsgroups: gmane.emacs.bugs Subject: bug#35316: 26.2; Emacs lags in c++-mode buffer when editing with iedit-mode on Date: Fri, 17 May 2019 09:19:11 +0800 Message-ID: <871s0xop2o.fsf@gmail.com> References: <20190516150457.GA639@ACM> <20190516161704.GA527@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="243453"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: mu4e 1.1.0; emacs 27.0.50 Cc: monnier@iro.umontreal.ca, ccsmile2008@outlook.com To: 35316@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 17 03:20:18 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 1hRRXl-0011Dh-91 for geb-bug-gnu-emacs@m.gmane.org; Fri, 17 May 2019 03:20:17 +0200 Original-Received: from localhost ([127.0.0.1]:39357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRRXj-0001Mf-Ug for geb-bug-gnu-emacs@m.gmane.org; Thu, 16 May 2019 21:20:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRRXd-0001Kg-U2 for bug-gnu-emacs@gnu.org; Thu, 16 May 2019 21:20:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hRRXb-0003gg-JU for bug-gnu-emacs@gnu.org; Thu, 16 May 2019 21:20:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43339) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hRRXW-0003ec-ND; Thu, 16 May 2019 21:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hRRXW-0007Mv-H0; Thu, 16 May 2019 21:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Amos Bird Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Fri, 17 May 2019 01:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35316 X-GNU-PR-Package: emacs,cc-mode X-Debbugs-Original-To: debbugs-submit@debbugs.gnu.org X-Debbugs-Original-Cc: "35316@debbugs.gnu.org" <35316@debbugs.gnu.org>, Stefan Monnier , Zhang Haijun Original-Received: via spool by 35316-submit@debbugs.gnu.org id=B35316.155805594628166 (code B ref 35316); Fri, 17 May 2019 01:20:02 +0000 Original-Received: (at 35316) by debbugs.gnu.org; 17 May 2019 01:19:06 +0000 Original-Received: from localhost ([127.0.0.1]:56882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRRWc-0007K1-BX for submit@debbugs.gnu.org; Thu, 16 May 2019 21:19:06 -0400 Original-Received: from mail-pg1-f179.google.com ([209.85.215.179]:47096) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hRRWW-0007J3-EV; Thu, 16 May 2019 21:19:04 -0400 Original-Received: by mail-pg1-f179.google.com with SMTP id t187so2402647pgb.13; Thu, 16 May 2019 18:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:date :message-id:mime-version:content-transfer-encoding; bh=19y8iTcEaZG2TC9/rYFGl700lifFKU9sNr1ZsGymKWw=; b=i/rVlmg7XfgGDg1zdHAnAbMeQsU28NfUu4ylUTIHRXpe0mY3Ii1rrKHq81MCeCxgd+ ejvKB6Q5AATYyoNi5b7UZK/QA1GgklhPkVxprfkm/RA0h49CYT9dMpwwYqmawS/J7vRt lRQRj7LDNlKXBcu73dsaKgwwhkNpVwqOn/11eFKd2EVqumZE+Q1OUUDknkkJvSCc8nAH awcIXhBbdDI6d4BgCVB9RBzmjYk9B+7/bjIaTScT3XO/Da8LTA5LKMiKSvWhWl+fwwXe k2ATnp67NbddcjKntyhS1wNBSo8u7diHfAhYS3JLp4LeJrffogvFH3GkfB7w4vuG1eSU QADg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=19y8iTcEaZG2TC9/rYFGl700lifFKU9sNr1ZsGymKWw=; b=L4SdidHI+skL3lhK70EZrljveKBiDa+PSl2IY5ePg1Q79qElyI1RO+7qWAdUvuk3tR q8YD/GR9ZM6r1dUV62YVTMbeG8APJsSnXBTdI3RLlzAsTT1lKvbLjt52SGcQ1Su3Djot fY9+peaZDomYUsN85nQnn1iY1W6oPpiiVbqk9Qq+WYSVXeDJxegtPZYNZbvh29ENQzgh Dw+GodbP1Kh4E0c1RAkfiQals3sO2rx+LWZVhpfUjfp2DmtJ0/+Yu9G5mbyE15Rte4co iPf69dfXYAKkNy56Zy8Trx4eQu5OjRabTAR+a93KtW23uibd3iKzya6+qJYkGrKKKwyO xDAw== X-Gm-Message-State: APjAAAX5kUWHngXAXs69u7IKSmC1/aL0adNu4JVs37zd87ri6/a/pX0f j0SEzssEvQTZzcjvThnkS7fQiMDM3XNyqg== X-Google-Smtp-Source: APXvYqwPZMJjDQz1PA33y6O81oKuVPAIq3VBh0yoD7BD597CgC+PQEwtRZX93D4mP/p/OOumSM1b6Q== X-Received: by 2002:a63:5c5f:: with SMTP id n31mr54193858pgm.325.1558055934243; Thu, 16 May 2019 18:18:54 -0700 (PDT) Original-Received: from localhost ([13.75.109.155]) by smtp.gmail.com with ESMTPSA id l21sm9042192pff.40.2019.05.16.18.18.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 16 May 2019 18:18:53 -0700 (PDT) In-reply-to: <20190516161704.GA527@ACM> 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:159430 Archived-At: Hello, this patch works as expected. Is there any similar=20 technique I can apply to undo-tree? After modifying hundreds of=20 copies using iedit, doing undo/redo freezes for several minutes. regards, Amos Alan Mackenzie writes: > Hello, Zhang. > > On Thu, May 16, 2019 at 15:46:33 +0000, Zhang Haijun wrote: > > >> > =E5=9C=A8 2019=E5=B9=B45=E6=9C=8816=E6=97=A5=EF=BC=8C=E4=B8=8B=E5=8D= =8811:04=EF=BC=8CAlan Mackenzie =E5=86=99=E9=81=93=EF=BC=9A > >> > The problem is in the function iedit-update-occurrences-2.=20 >> > There, >> > inhibit-modification-hooks is bound to t, and the many=20 >> > changes are made. >> > The hook after-change-functions is called explicitly after=20 >> > each change. > >> > But before-change-functions is not called in this loop. This=20 >> > is a very >> > bad idea. Unlike many modes, CC Mode has critical parts of=20 >> > its >> > functionality in the before-change-functions hook, and=20 >> > depends on this >> > hook and after-change-functions both being called for each=20 >> > change. > >> > When CC Mode detects after-change-functions being called=20 >> > without >> > before-..., it enlarges the region to the whole buffer, calls >> > c-before-change with this enlarged region, finally proceding=20 >> > with the >> > rest of c-after-change. It does this to protect its buffer's=20 >> > integrity. > > >> It seems that this leads too much redundant work. > > What iedit-mode is doing with after-change-functions is=20 > 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=20 >> > processing the >> > entire buffer for each cursor, rather than just part of the=20 >> > buffer >> > involved. > >> > So, why are you binding inhibit-modification-hooks to t and=20 >> > calling >> > after-change-functions this way? Why not just let the=20 >> > modification hooks >> > run in the normal fashion? What is it about=20 >> > before-change-functions >> > which is bad in iedit-mode? > >> I=E2=80=99m not the developer of iedit. > > Would you please consider forwarding this email to the=20 > 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=20 >> depend on >> ;; after-change-functions to update original >> ;; buffer. Since inhibit-modification-hooks is=20 >> set to >> ;; non-nil, after-change-functions hooks are=20 >> not going >> ;; to be called for the changes of other=20 >> occurrences. >> ;; So run the hook here. > > I saw this comment too. I had a look at the repository on=20 > github, and > this handling of after-change-functions has been there since at=20 > 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=20 > &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=20 > not going > ;; to be called for the changes of other=20 > 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=20 > another-occurrence))) > ;; deletion > (dolist (another-occurrence (remove occurrence=20 > 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++=20 > Mode test > buffer, just over 16k long, on a variable with 75 copies in it,=20 > I press > C-;. On editing the copies of these variables, the response is=20 > now > instantaneous. > > The question remaining is what was the problem which led to this=20 > mistaken > after-change-functions handling? Is this problem still there? -- Amos Bird amosbird@gmail.com