[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: Fri, 21 Oct 2011 17:51:17 -0400
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (darwin)

on Fri Oct 21 2011, Michael Albinus <> wrote:

> Dave Abrahams <address@hidden> writes:
>> 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
>> seconds.
> That's an idea. But what shall Tramp do then to "get out of the way"?
> Returning an error? It does, and it annoys. Returning nil? 

I don't know enough about Tramp internals to guess what function is
"returning" in your questions above, nor in what context it's being
called.  I meant, essentially, turning itself off for any server that
fails.  If Tramp is asked to establish the same connection N times in M
seconds, and it fails, that connection could be (temporarily?) put on a
"do not try" list... and then for paths specifying that connnection
Tramp might simply act as though it doesn't exist.

Thinking about this some more, that might be too simplistic.  I guess I
was sort of counting on you to take the general idea and make it

> This is often a valid answer for the file name operations, but it
> could be the wrong answer. Disabling itself, and recall the function?
> This would return something like "/ssh:host#wrongport:/" does not
> exist. Maybe this is the least confusing answer ...

Sure, but I think the idea is to say that only so often.

>>> 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.
> default-directory shall be set in a buffer only for good reasons. A
> library like ido, which does minibuffer completion, shall always
> let-bind this variable. Maybe it is worth a bug report? (I do not use
> ido myself).

Already reported:
Feel free to add your voice to the report.

>>> 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.
> Thanks. And I will check, whether I could inject the "too much errors,
> sorry, I don't serve for a while" into Tramp. What would be a good
> period for silence? 10 seconds?

I don't know; I think you can probably only find out through user
experience.  I know that Tramp sometimes has remote buffers for files on
servers that become unavailable, and when that happens it can also be a
maddening experience, because of Tramp's retries, to even get `M-x
tramp-cleanup-all-buffers' typed.  The best response, of course, would
be for Tramp to offer to close all buffers for unavailable servers, and
if the answer was "no," merely disable their connections...

So I don't know if the different "connection trouble" scenarios have one
correct response, either :-P

Dave Abrahams
BoostPro Computing

reply via email to

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