Is it safe to use the combine-after-change-calls like this?

Is it safe to use the combine-after-change-calls like this?

[Zhang Haijun]

I want to use it with multiple-cursors.el(https://github.com/magnars/multiple-cursors.el) like this:
1. When multiple-cursors activates, set combine-after-change-calls to t
2. Edit the buffer with multiple active cursors
3. Before multiple-cursors deactivates, call combine-after-change-execute and set combine-after-change-calls back to nil.

I’m using the package iedit.el(https://github.com/victorhge/iedit). It works like multiple-cursors.el, which has multiple active cursors.  

The problem is that: when editing with multiple active cursors, emacs lags too much. It seems that most of cpu is used by functions in after-change-functions.

The issue: https://github.com/victorhge/iedit/issues/83

Re: Is it safe to use the combine-after-change-calls like this?

[Stefan Monnier]

> The problem is that: when editing with multiple active cursors, emacs lags
> too much. It seems that most of cpu is used by functions in
> after-change-functions.
>
> The issue: https://github.com/victorhge/iedit/issues/83

I see in this issue that you're using iedit in a CC-mode buffer.
Does the problem occur with other major modes?
E.g. in perl-mode or cperl-mode buffers (which have "similarly" heavy
requirements to apply syntax-table text-properties).


        Stefan

Re: Is it safe to use the combine-after-change-calls like this?

[Stefan Monnier]

> 1. When multiple-cursors activates, set combine-after-change-calls to t
> 2. Edit the buffer with multiple active cursors
> 3. Before multiple-cursors deactivates, call combine-after-change-execute
> and set combine-after-change-calls back to nil.

As for the subject's question: I think it might be safe, but it probably
won't make a difference: combine-after-change-calls is ignored when
before-change-functions is non-nil.

Also, regarding interaction with non-CC-mode buffers: you might be able
to improve the efficiency of the code by executing the command of the
various cursors starting with the one closest to point-max and finishing
with the one closest to point-min.

For CC-mode buffers I have more trouble guessing if such an ordering
would also help, or would hurt, or make no difference.


        Stefan

Re: Is it safe to use the combine-after-change-calls like this?

[Zhang Haijun]

> combine-after-change-calls is ignored when before-change-functions is non-nil.

I just recognize this. It is not nil in c++-mode buffers.

> Also, regarding interaction with non-CC-mode buffers: you might be able
> to improve the efficiency of the code by executing the command of the
> various cursors starting with the one closest to point-max and finishing
> with the one closest to point-min.

I don’t understand this well. I see that when iedit-mode is on, it calls after-change-functions on change around every active cursors for every char inputing.

Re: Is it safe to use the combine-after-change-calls like this?

[Stefan Monnier]

>> Also, regarding interaction with non-CC-mode buffers: you might be able
>> to improve the efficiency of the code by executing the command of the
>> various cursors starting with the one closest to point-max and finishing
>> with the one closest to point-min.
> I don’t understand this well.

If you're currently operating (via Iedit or MC) at positions 10, 42 and
347, then I think it's going to be slightly more efficient if Iedit/MC
runs your command (e.g. self-insert-command, delete-char, you name it)
in the order

    run at 347
    run at 42
    run at 10
    
then if it does it in the order

    run at 10
    run at 42
    run at 347
    
> I see that when iedit-mode is on, it calls after-change-functions on
> change around every active cursors for every char inputing.

Yes, of course, that's what after-change-functions is for.


        Stefan

Re: Is it safe to use the combine-after-change-calls like this?

[Alan Mackenzie]

Hello, Zhang.

On Thu, Apr 18, 2019 at 05:34:56 +0000, Zhang Haijun wrote:

> > combine-after-change-calls is ignored when before-change-functions is non-nil.

> I just recognize this. It is not nil in c++-mode buffers.

CC Mode maintains several caches of state information, which are updated
in the before-change-functions and after-change-functions hooks.  This
is on the assumption that successive buffer changes are usually close to
eachother.  Obviously, this is less true in iedit-mode, and it is likely
that these caches hinder rather than help in this case.

> > Also, regarding interaction with non-CC-mode buffers: you might be able
> > to improve the efficiency of the code by executing the command of the
> > various cursors starting with the one closest to point-max and finishing
> > with the one closest to point-min.

> I don’t understand this well. I see that when iedit-mode is on, it
> calls after-change-functions on change around every active cursors for
> every char inputing.

One thing which might help in the future is the macro
combine-change-calls, which is a bit like combine-after-change-calls,
but also works when before-change-functions isn't nil.

combine-change-calls is in the Emacs repository master, and should be
getting released with Emacs 27.1 in the medium future (maybe about a
year from now).

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Is it safe to use the combine-after-change-calls like this?

[Stefan Monnier]

>> I don’t understand this well. I see that when iedit-mode is on, it
>> calls after-change-functions on change around every active cursors for
>> every char inputing.
>
> One thing which might help in the future is the macro
> combine-change-calls, which is a bit like combine-after-change-calls,
> but also works when before-change-functions isn't nil.

I think in the case of iedit this is problematic, because
combine-change-calls can't be used around code which internally depends
on those before/after functions (e.g. in the present case, it could
misbehave if its behavior depends on the text-properties that are
updated via before/after-change-functions, like syntax-table).

For comment-combine-change-calls, we think it's OK because we hope that
(un)comment-region will not be affected by those stale data, but with
iedit there's much less knowledge/control of the range of code that would
be run within the combine-change-calls, making it more problematic.


        Stefan