[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: An idea: combine-change-calls
From: |
Alan Mackenzie |
Subject: |
Re: An idea: combine-change-calls |
Date: |
Sun, 25 Mar 2018 19:14:24 +0000 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
Hello, Stefan.
On Sat, Mar 24, 2018 at 18:18:05 -0400, Stefan Monnier wrote:
> > The motivation is bug #30735,
> [ Not surprised: I told you CC-mode's change-functions are too costly,
> because they presumes that before&after-change-functions are called at
> a "human" rate (comparable to pre/post-command-hook).
> before&after-change-functions should be handled a bit like POSIX
> signals: do as little work as possible there, and handle them
> later elsewhere. `comment-region` is not the only command that can
> make many small changes. ]
Yes, acknowledged.
> > What do people think?
> I actually do like the idea of combining such things, tho it's risky:
> e.g. if the code within combine-change-calls uses syntax-ppss it might
> get wrong results since syntax-ppss-flush-cache is triggered via
> before-change-functions. The same problem would affect
> syntax-propertize, of course.
OK. That could be a problem in general.
I've actually got a working implementation going. It is this:
(defmacro combine-change-calls (beg end &rest form)
`(if (not inhibit-modification-hooks)
(let* ((-beg- ,beg) (-end- ,end)
(end-marker (copy-marker -end-)))
(run-hook-with-args 'before-change-functions beg end)
(let ((inhibit-modification-hooks t))
,@form)
(run-hook-with-args 'after-change-functions
beg (marker-position end-marker)
(- -end- -beg-)))
,@form))
With it used in newcomment.el, C-c C-c and C-u C-c C-c on large portions
of CC Mode files go fast enough.
> Grepping for `add-hook.*before-change-functions` indicates that similar
> problem could appear elsewhere. Not sure what to do about it other than
> to say "don't over-use it, it might bite you".
> Also we'd need such a system to check that the bounds
> are indeed obeyed.
> One more thing: with the sample code you showed, undoing will still be
> just as slow since it won't benefit from combine-change-calls.
Yes, this is indeed the case.
> Maybe combine-change-calls should also combine all those changes on the
> undo-list into a big "delete+insert" (of course, it could also try and
> keep the undo granularity but mark those undo entries so that they're
> undone within their own combine-change-calls).
:-) Either of those would be quite a project, but possibly worth doing.
Thanks for the idea.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
- An idea: combine-change-calls, Alan Mackenzie, 2018/03/24
- Re: An idea: combine-change-calls, Stefan Monnier, 2018/03/24
- Re: An idea: combine-change-calls,
Alan Mackenzie <=
- Re: An idea: combine-change-calls, Stefan Monnier, 2018/03/25
- Re: An idea: combine-change-calls, Alan Mackenzie, 2018/03/26
- Re: An idea: combine-change-calls, Stefan Monnier, 2018/03/26
- Re: An idea: combine-change-calls, Alan Mackenzie, 2018/03/27
- Re: An idea: combine-change-calls, Stefan Monnier, 2018/03/27
- Re: An idea: combine-change-calls, Alan Mackenzie, 2018/03/27
- Re: An idea: combine-change-calls, Stefan Monnier, 2018/03/27
- Re: An idea: combine-change-calls, Alan Mackenzie, 2018/03/28
- Re: An idea: combine-change-calls, Stefan Monnier, 2018/03/28
- Re: An idea: combine-change-calls, Alan Mackenzie, 2018/03/29