From: Noam Postavsky <npostavs@gmail.com>
To: Alan Mackenzie <acm@muc.de>
Cc: Amos Bird <amosbird@gmail.com>,
35316@debbugs.gnu.org, Zhang Haijun <ccsmile2008@outlook.com>
Subject: bug#35316: 26.2; Emacs lags in c++-mode buffer when editing with iedit-mode on
Date: Sun, 19 May 2019 13:41:14 -0400 [thread overview]
Message-ID: <87mujibav9.fsf@gmail.com> (raw)
In-Reply-To: <20190519142615.GB5262@ACM> (Alan Mackenzie's message of "Sun, 19 May 2019 14:26:15 +0000")
Alan Mackenzie <acm@muc.de> writes:
>> 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.
Sorry, it was a bit unclear, the first "..." was just intended to be the
docstring. I.e., the code I put in there should be at the top-level of
the function, and wrap the rest of the code.
> It might also be even less clean than the explicit calls to
> before/after-change-functions.
Although it misses text property and overlay change hooks.
>> 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),
Yes, it's open.
> 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.
Yeah, it's a tricky case. The docs are definitely not adequate.
next prev parent reply other threads:[~2019-05-19 17:41 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
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 [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mujibav9.fsf@gmail.com \
--to=npostavs@gmail.com \
--cc=35316@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=amosbird@gmail.com \
--cc=ccsmile2008@outlook.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).