From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.bugs Subject: bug#19636: [TRAMP] global minor mode hangs connection when accessing files in :lighter Date: Sun, 25 Jan 2015 21:15:44 +0100 Message-ID: References: <87d268jejx.fsf@gmx.de> <87h9vey7gl.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1422217036 6083 80.91.229.3 (25 Jan 2015 20:17:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Jan 2015 20:17:16 +0000 (UTC) Cc: 19636 <19636@debbugs.gnu.org> To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 25 21:17:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YFTcO-000830-Qj for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Jan 2015 21:17:13 +0100 Original-Received: from localhost ([::1]:38769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFTcN-0008QZ-Tt for geb-bug-gnu-emacs@m.gmane.org; Sun, 25 Jan 2015 15:17:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFTcK-0008QJ-1x for bug-gnu-emacs@gnu.org; Sun, 25 Jan 2015 15:17:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YFTcE-0001Q4-UV for bug-gnu-emacs@gnu.org; Sun, 25 Jan 2015 15:17:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37561) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YFTcE-0001Pw-QJ for bug-gnu-emacs@gnu.org; Sun, 25 Jan 2015 15:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YFTcE-0007em-2r for bug-gnu-emacs@gnu.org; Sun, 25 Jan 2015 15:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philippe Vaucher Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Jan 2015 20:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19636 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19636-submit@debbugs.gnu.org id=B19636.142221698329323 (code B ref 19636); Sun, 25 Jan 2015 20:17:01 +0000 Original-Received: (at 19636) by debbugs.gnu.org; 25 Jan 2015 20:16:23 +0000 Original-Received: from localhost ([127.0.0.1]:56253 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YFTbb-0007cs-3n for submit@debbugs.gnu.org; Sun, 25 Jan 2015 15:16:23 -0500 Original-Received: from mail-oi0-f50.google.com ([209.85.218.50]:44088) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YFTbX-0007cX-RV for 19636@debbugs.gnu.org; Sun, 25 Jan 2015 15:16:20 -0500 Original-Received: by mail-oi0-f50.google.com with SMTP id h136so4568471oig.9 for <19636@debbugs.gnu.org>; Sun, 25 Jan 2015 12:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jVKWZLApfj1aYH7tSxqI8FQBh2qi3xOCSmMOyEs+sJE=; b=xiJaKedZ+RVKcq6SfHsk//P/kX5rqc413A7lsN5rXmDA0GnREmF2hhaqqlhZB6Tc/d F0D79EqU7LMjf/JklRKDPGhhiMY0u0rHY8FqSvL2e/C+NHQHXziB1vHK53t0HFSZ1Kil Jt8wMaI/d6ViyJlNHvRPymkzq/Fw5FH/0OoVRXG4ACbRAjkUB/iJBPzqomhwX63dafGZ U8k1STSZU1AO2eCoUkD5sJV7Ht2mWTNFthDMnAvVLPIgVzaHIqunTrOhl0u1gwhSKLmD WxeVL/197a/BPGN7FOIr5uwEX3FpK2R5ltE+ZogDiNDMzU5du3xM2wlJx0Kz+YZWbrnN X9uw== X-Received: by 10.202.198.214 with SMTP id w205mr9502115oif.74.1422216974281; Sun, 25 Jan 2015 12:16:14 -0800 (PST) Original-Received: by 10.202.229.4 with HTTP; Sun, 25 Jan 2015 12:15:44 -0800 (PST) In-Reply-To: <87h9vey7gl.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:98726 Archived-At: > > That's an interesting workaround, can I assume that > > `default-directory` over a TRAMP connection is always absolute? what > > about symlinks? > > You can always assume, that `default-directory' is absolute, being it > local or remote. Symlinks are not expanded, 'tho. > > However, there is always the buffer local variable > `buffer-file-truename'. Maybe you could use it somehow, when setting the > lighter? Something like > > (if buffer-file-truename (file-name-directory buffer-file-truename) default-directory) Thanks for mentionning `buffer-file-truename', I didn't know about it. Unfortunately my problem is more complex than that because at the moment this package does many files existence checks in order to find the project root directory (e.g it tries to find any of "Gemfile", ".git", "Makefile" in the current directory, then if not found in the parent one, etc). I know that all these filesystem checks doesn't scale very well when not done locally, but I'm kinda stuck with the current design. It is planned to refactor it all into leveraging caching and possibly doing these checks by spawning a little bash script remotely. > Short analysis of the debug buffer: (snip) > Here Tramp opens a second connection in order to call git. (snip) > And here Tramp tries to use the primary connection for getting the > truename of the default directory. Tramp is not able to accept those > requests while preparing the second connection for > start-file-process. Maybe I need to add something in order to make it > more robust. This is not such easy, it might take time. Ah, that's very helpful to understand what's going on. What is weird is that there seems to be some kind of deadlocking happening, because "git fetch" takes less than 10 seconds to finish, and in the log we see that it just waits for 10 seconds until the "Are you awake" message (I tried increasing the timeout but it just waits until the timeout, not processing either the "git fetch" or the `file-truename'. It seems that when the second connection starts, if you request something that happens to use the first connection, the second connection will also be stuck and nothing will happen until the timeout is reached. So, basically I can see 3 ways to tackle the problem: - Don't try to do project detection when there's more than one TRAMP connection to the same host. Can you point me at a way to do that? Something like `(tramp-connections-count default-directory)' - Find a way to detect wether the 2nd connection is "ready", which is my attempt with `tramp-connectable-p' or `file-remote-p', but I believe this way is a dead-end because TRAMP will tell me about the 1st connection and not the 2nd one. - Fix TRAMP so it better handles multiple connections, but it's likely to involve quite some work. Maybe a simple idea would be that calls to `file-truename` always use the most recent connection? I'm not sure I make sense so feel free to ignore it :) Thank you! Philippe