Re: tramp and diff-mode results in Emacs crash

[Stefan Monnier]

>> Oh, wait, you're saying that the problem is that when
>> combine-after-change-execute is run it begins by calling lock_file, which
>> causes more changes?  Hmm... I still don't see why that would be a problem.
>> Can you show some backtraces?

> I couldn't get Emacs to crash, but here is a backtrace from a
> breakpoint just before Emacs gets confused.

> Basically, insert_from_string calls prepare_to_modify_buffer before
> signal_after_change (the latter is supposed to signal the changes due
> to the insertion).  But prepare_to_modify_buffer calls lock_file,
> which calls the Tramp file handlers, which does its own insertion in a
> temp buffer, which runs signal_after_change, which first runs
> signal_after_change on the original buffer---all this happens *before*
> signal_before_change on the original buffer gets to run!

Why is the above sequence a problem?

> This analysis indicates that the more general solution is to bind
> inhibit_modification_hooks around the call to lock_file in
> prepare_to_modify_buffer, but that seems to me too risky a change at
> this stage in the release.

It still feels like it'd hide the problem rather than fix it.
But maybe it's just because I still don't know what the problem is.


        Stefan