From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#9793: 24.0.90; Unwanted tramp connection on eshell completion. Date: Tue, 25 Oct 2011 08:16:31 -0400 Message-ID: References: <87r529a8g2.fsf@gmail.com> <871uu7lcv7.fsf@gmail.com> <87wrbxjrfi.fsf@gmx.de> <87y5wamva0.fsf@gmx.de> <87fwihgxqa.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1319545074 29778 80.91.229.12 (25 Oct 2011 12:17:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2011 12:17:54 +0000 (UTC) Cc: 9793@debbugs.gnu.org, Thierry Volpiatto To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 25 14:17:49 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RIfwz-00083s-Fw for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Oct 2011 14:17:49 +0200 Original-Received: from localhost ([::1]:44538 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIfwy-00025y-Sr for geb-bug-gnu-emacs@m.gmane.org; Tue, 25 Oct 2011 08:17:48 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIfwh-0001IW-K5 for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2011 08:17:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIfwc-0007Gz-1u for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2011 08:17:31 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIfwb-0007Gt-RY for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2011 08:17:25 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RIfy9-0002Ql-Va for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2011 08:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Oct 2011 12:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9793 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9793-submit@debbugs.gnu.org id=B9793.13195450969291 (code B ref 9793); Tue, 25 Oct 2011 12:19:01 +0000 Original-Received: (at 9793) by debbugs.gnu.org; 25 Oct 2011 12:18:16 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RIfxQ-0002Pn-4o for submit@debbugs.gnu.org; Tue, 25 Oct 2011 08:18:16 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RIfxO-0002Pb-56 for 9793@debbugs.gnu.org; Tue, 25 Oct 2011 08:18:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOinpk5MCrTo/2dsb2JhbABDqRSBBoFuAQEEAVYjBQsLNBIUGA0kiBO0WYhDBKE9hEU X-IronPort-AV: E=Sophos;i="4.69,404,1315195200"; d="scan'208";a="144273252" Original-Received: from 76-10-180-232.dsl.teksavvy.com (HELO ceviche.home) ([76.10.180.232]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 25 Oct 2011 08:16:31 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 12AF466158; Tue, 25 Oct 2011 08:16:31 -0400 (EDT) In-Reply-To: <87fwihgxqa.fsf@gmx.de> (Michael Albinus's message of "Tue, 25 Oct 2011 12:41:01 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 25 Oct 2011 08:19:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:53113 Archived-At: > Tramp has some code to guess whether it is in completion mode. Yuck! > Check of `non-essential' is one proof, Actually, no. non-essential could be used for other things than completion. > checking the last keyboard input (being TAB, or not) is another one. Yuck! > If Tramp finds out that it is in completion mode, it suppresses some > remote actions, like expand-file-name. Since your code > (let ((default-directory "/")) (file-directory-p "tequila:")) > does not show an evidence of the completion mode, all remote actions are > performed. OK, so now I know why the two behaved differently. > The actions for `file-directory-p' are never been suppressed, that's why > Tramp performs them also when being in completion mode. Good. >> In shell-mode completion also understands Tramp file names (yup, that's >> a bug, we should probably default comint-file-name-prefix to "/:/"), so >> that's not the problem. > Better not. There are still needed checks in shell.el, which are applied > to remote files. `comint-file-name-prefix keeps the remote part of those > files. I do not propose to remove the variable. Only to make it default to "/:/" (instead of just ""). >>> But this makes the trouble with the completion predicate >>> `file-directory-p'. >> Yup, I think we should somehow make it so Tramp can say >> (file-directory-p "/tequila:") => t >> without trying to connect to tequila (after all, even if we can't >> connect to tequila, this is still a "directory", just one we currently >> can't access). > That was the intention of my patch :-) > Return t in case of remote files. But that's not what I suggest. I suggest to "blindly" return t for /: only (as well as things like /ssh:: I guess), but not for /: where we'd still connect and test whether it's indeed a directory. > Inside Tramp it could be behave such a way when it detects it is in > completion mode. That means, when `non-essential' is set to t. Shall I > do it this way? I suggest to do that regardless of whether we're in completion mode or not. Stefan