Re: An idea: combine-change-calls

[Alan Mackenzie <acm@muc.de>]

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).