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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]