Re: tramp (2.2.6-pre); Persistent attempts to "go remote"

[Dave Abrahams]

on Wed Oct 10 2012, Michael Albinus <michael.albinus-AT-gmx.de> wrote:

> Dave Abrahams <address@hidden> writes:
>
>> Hi Michael,
>
> Hi Dave,
>
>> Despite having done tramp-cleanup-all-connections and
>> tramp-cleanup-all-buffers, my use of `M-x shell-command ... &' with
>> something that invokes emacsclient is causing TRAMP to try to reconnect.
>> I'm not sure of the reasons; the stack trace seems to indicate that EDE
>> may be involved.  I'll try to leave this Emacs process around so we can
>> debug it...
>
> You are right, it seems to be a bad interaction with EDE. The crucial
> point is this:
>
>>   file-truename("/scpc:io.local:/private/tmp/emacs-mac-mrNX/")
>>   
>> ede-directory-get-toplevel-open-project("/var/folders/b2/w0_x7_854hz82sbrdxqqd6gr0000gn/T/")
>
> 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.

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

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

Is TRAMP careful to protect all such temporary global changes with
unwind-protect so they don't stick?

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost