Re: tramp and diff-mode results in Emacs crash

[Chong Yidong]

Stefan Monnier <address@hidden> writes:

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

You're right, I wasn't thinking very clearly about the problem.  But I
now know what it is.

Basically, after the file handler performs its changes, it's time for
the original insertion to combine its after-change calls.  But it has
to perform combine-after-change execute for the temp file changes made
by the file handler.  But combine_after_change_buffer will no longer
be valid since the temp file was destroyed, and the call to set-buffer
in combine-after-change-execute fails.

So I reverted my previous change, and changed combine-after-change-execute
to return nil when combine_after_change_buffer is not a valid buffer.
This fixes the bug too, and I think it shouldn't be much more
dangerous than the previous workaround.