Dave Abrahams <[email protected]> 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. _______________________________________________ Tramp-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/tramp-devel
