[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: |
Stefan Monnier |
Subject: |
Re: tramp and diff-mode results in Emacs crash |
Date: |
Wed, 28 Feb 2007 10:48:26 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.93 (gnu/linux) |
>> - ~/software/emacs22/bin/emacs -q
>> - C-x C-f /10.0.1.169:foo.rej RET
>> - C-c C-u
>>
>> I see only "Back to top level." The diff is unmodified by the
>> command. Menus stop working, C-x C-b says "Back to top level." or
>> nothing, C-x b alternates between "S" and "Back to top level." in the
>> minibuffer without ever letting me change buffers, etc.
> I checked in a fix for this.
> (It's not a great fix, but it's the safest one I could think of. The
> problem arises when combine-after-change-calls is on. The Tramp
> filename handlers can be called (by lock_file) just before Emacs is
> about to combine after-change calls, but those filename handlers can
> themselves produce after-change calls because they scribble in temp
> buffers. It is possible to get Emacs into a confused state in this
> way. I simply made the Tramp handlers bind inhibit-modification-hooks
> to avoid this problem. We may want to revisit the interaction of file
> modification hooks with combine-after-change-calls after the release.)
Maybe the workaround is OK, but I still don't understand what is the bug.
When using combine-after-change-calls, if changes are made in different
buffers, then the after-change-functions are run each time modifications are
done on a different buffer.
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?
Stefan