[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tramp (2.2.6-pre); Persistent attempts to "go remote"
From: |
Michael Albinus |
Subject: |
Re: tramp (2.2.6-pre); Persistent attempts to "go remote" |
Date: |
Wed, 10 Oct 2012 21:24:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
Dave Abrahams <address@hidden> writes:
Hi Dave,
>> Reading `ede-directory-get-toplevel-open-project', there are two calls
>> of `file-truename'. It is not obvious to me, why a remote directory is
>> used as argument for one of the calls. Maybe you could debug
>> `ede-directory-get-toplevel-open-project'?
>
> I'm trying, but it looks like even `M-x find-function' is getting
> tangled up in TRAMP, and now that Emacs process is hung. I'm probably
> going to have to kill it.
Hmm. Maybe you have a simple recipe I could apply in order to reproduce?
I don't use EDE myself, so I need some advice what to do.
>> One wild guess: the remote directory looks like a remote temp
>> directory. Tramp changes temporarily the value of
>> `temporary-file-directory'. Since the EDE actions are invoked by a
>> timer, it could happen that they are applied at time when Tramp has
>> overwritten that variable.
>
> That's kind of horrible, IMO! Shouldn't you be taking advantage of
> dynamic scoping to mask the old value so that when timers run they still
> have the old value? Or would that not work?
Tramp changes such global variables by let-bind. No global change, as
far as I'm aware of.
>> Another guess: Tramp might have changed temporarily `default-directory'
>> to that remote directory during execution of your asynchronous shell
>> command. And EDE uses that value, becauses it jumps in by the timer.
>
> It was my understanding that timers would only run at idle time and not
> in arbitrary contexts. If Emacs timers are susceptible to such temporary
> changes, well, that's *really bad*.
That's also my understanding. But we have seen the backtrace, which
started with invocation from a timer. Maybe I shall consult the
documentation, again.
> Is TRAMP careful to protect all such temporary global changes with
> unwind-protect so they don't stick?
As said, I believe that Tramp changes such global variables inside a let
clause only. But maybe there's something I've overseen. Therefore, it
would be great if I would know a recipe to reproduce the problem.
Best regards, Michael.