on Fri Oct 21 2011, Michael Albinus <michael.albinus-AT-gmx.de> wrote:
> Dave Abrahams <[email protected]> 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 workable. > 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: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9814 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 http://www.boostpro.com _______________________________________________ Tramp-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/tramp-devel
