[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tramp and diff-mode results in Emacs crash
From: |
Chong Yidong |
Subject: |
Re: tramp and diff-mode results in Emacs crash |
Date: |
Wed, 28 Feb 2007 17:27:25 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.94 (gnu/linux) |
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.