[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tramp (2.2.3-pre); a bit too eager

From: Dave Abrahams
Subject: Re: tramp (2.2.3-pre); a bit too eager
Date: Thu, 20 Oct 2011 14:43:30 -0400
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin)

on Thu Oct 20 2011, Michael Albinus <> wrote:

> Dave Abrahams <address@hidden> writes:
> Hi Dave,
>> I recently added this to my .emacs:
>>       ;; If I don't set this during startup, an error can cause it to
>>       ;; be set to something that invokes TRAMP whenever I try to
>>       ;; switch buffers.
>>       (setq default-directory "~")
>> The problem was that an error loading my personal .loaddefs.el file was
>> liable to leave default-directory (globally somehow) set such that TRAMP
>> would intervene (and fail) every time I even tried ido-switch-buffer.  I
>> couldn't even switch to my *Messages* buffer without first doing `M-:
>> (setq default-directory "~")'.
> `default-directory' is a buffer local variable. It is essential for
> Tramp to trust a correct value here, I don't see a scenario where Tramp
> could detect an improper setting.

Well, I don't know what it was set to, but I suspect it was "/".  It
could certainly detect that the hostname was empty—which I think was my
situation—or that the port was illegal, or that the protocol was

And... if contacting the host repeatedly failed it might be good for
Tramp to get out of the way and stop intervening for the next few

>> I'm sure this is at least partly ido's fault, but TRAMP should probably
>> not ever be involved in Emacs becoming totally unusable except to
>> someone who can guess the magic incantaion.
> Tramp is invoked based on file name syntax. If `default-directory' has a
> remote file name syntax, chances are good that the Tramp file name
> handler is called.

oh, it looks like there are several unguarded setq's of
default-directory in ido.

> Maybe the best would be to try to reproduce the problem from your
> environment. Do you have an .emacs plus a scenario, which is know to
> reproduce the problem?

Not at the moment; as you can imagine it was more important to me to fix
the problem so I could get back to work than it was to file an accurate
bug report.  If this ever comes back (and I've seen it before so I
suspect it will) I'll be sure to gather more information.

Dave Abrahams
BoostPro Computing

reply via email to

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