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#23006: 25.0.92; Loading Tramp breaks pcomplete in eshell-mode Date: Tue, 22 Mar 2016 09:37:39 -0400 Message-ID: References: <871t7d4ion.fsf@gmx.de> <87bn69uouo.fsf@gmx.de> <764322aa-50ea-96b4-7c2a-36fbd60b2b54@yandex.ru> <8760wgvql0.fsf@gmx.de> <87r3f4ub0o.fsf@gmx.de> <87k2kvomui.fsf@gmx.de> <877fgvom2b.fsf@gmx.de> <57b602fa-a6b7-48c7-22f0-3751cd956228@yandex.ru> <8737rjol0t.fsf@gmx.de> <67874c87-ff4b-c1d9-8567-4aab31252d0b@yandex.ru> <87y49bn53t.fsf@gmx.de> <87twjzn0ep.fsf@gmx.de> <00533907-878e-7f62-7b65-a4ba3318a8e9@yandex.ru> <87egb2n8sp.fsf@gmx.de> <87fuviln5g.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458653905 14903 80.91.229.3 (22 Mar 2016 13:38:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Mar 2016 13:38:25 +0000 (UTC) Cc: 23006@debbugs.gnu.org, Dmitry Gutov To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 22 14:38:14 2016 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 1aiMVf-0005Yg-Sa for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Mar 2016 14:38:12 +0100 Original-Received: from localhost ([::1]:36935 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiMVf-00062N-73 for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Mar 2016 09:38:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiMVa-0005ze-Kf for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 09:38:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiMVW-0003KE-J9 for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 09:38:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiMVW-0003KA-GJ for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 09:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aiMVW-0002bN-Bx for bug-gnu-emacs@gnu.org; Tue, 22 Mar 2016 09:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Mar 2016 13:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23006-submit@debbugs.gnu.org id=B23006.14586538779990 (code B ref 23006); Tue, 22 Mar 2016 13:38:02 +0000 Original-Received: (at 23006) by debbugs.gnu.org; 22 Mar 2016 13:37:57 +0000 Original-Received: from localhost ([127.0.0.1]:57962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiMVR-0002b4-3s for submit@debbugs.gnu.org; Tue, 22 Mar 2016 09:37:57 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:33827) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiMVP-0002ap-G6 for 23006@debbugs.gnu.org; Tue, 22 Mar 2016 09:37:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AvEwA731xV/5a2xEVcgxCEAoVVuzcJhH6CTQQCAoE8ORQBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kiDcIzyMBAQEBAQEEAQEBAR6LOoUFB4QtBYtEhHCJOZlSgUUjggocgW4igTQFgT8BAQE X-IPAS-Result: A0AvEwA731xV/5a2xEVcgxCEAoVVuzcJhH6CTQQCAoE8ORQBAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kiDcIzyMBAQEBAQEEAQEBAR6LOoUFB4QtBYtEhHCJOZlSgUUjggocgW4igTQFgT8BAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="197732854" Original-Received: from 69-196-182-150.dsl.teksavvy.com (HELO pastel.home) ([69.196.182.150]) by ironport2-out.teksavvy.com with ESMTP; 22 Mar 2016 09:37:39 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 8BCA963F25; Tue, 22 Mar 2016 09:37:39 -0400 (EDT) In-Reply-To: <87fuviln5g.fsf@gmx.de> (Michael Albinus's message of "Tue, 22 Mar 2016 13:20:27 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:115318 Archived-At: > cd / TAB calls file-name-all-completions. This returns several > candidates, like "/adb:". That's OK. Indeed. > Afterwards, (file-directory-p "adb:") is called from completion-file-name-table: Aha, now we're going somewhere: > file-directory-p("adb:") > #[257 "\302\203\n\302!\205\301\203\301!\205\300?\206\300!\207" > [file-directory-p #[257 > "\211GSH\302=\203\301\205\303\301\"\202\300\205\303\300\"?\207" > ["~\\'" "\\`\\(\\.\\.?\\|CVS\\)/\\'" 47 string-match] 4 "\n\n(fn FILE)"] > nil] 3 "\n\n(fn F)"]("adb:") > completion-file-name-table("/" #[257 > "\302\203\n\302!\205\301\203\301!\205\300?\206\300!\207" > [file-directory-p #[257 > "\211GSH\302=\203\301\205\303\301\"\202\300\205\303\300\"?\207" > ["~\\'" "\\`\\(\\.\\.?\\|CVS\\)/\\'" 47 string-match] 4 "\n\n(fn FILE)"] > nil] 3 "\n\n(fn F)"] t) So, it seems the issue is that the completion predicate calls file-directory-p and that this happens in a part of the file name that's just at the boundary between "a local file name" and "a remote file name", so while file-name-all-completions did not need receive a remote file name it returned (apparently) remote file names. One avenue that may be needed then is to bind non-essential while checking the completion predicate (somewhere in pcomplete.el, or comint.el, or minibuffer.el.). But in this specific instance, (file-directory-p "/adb:") should simply return nil, IMO. > Tramp has no information, that file-name-completion is still in > progress, and does its job. It tries to connect to the remote host > "/adb:" in order to check. For me (file-directory-p "/adb:") doesn't try to connect to "adb" but instead signals "Host name must not match method name 'adb'". I think it's correct not to try to connect to "adb", but I think it should just return nil because "/adb:" is not a directory. > And yes, this is our basic disagreement. I'm not able to implement > proper Tramp operation without this information. Why do you refuse to > tell this to Tramp? Because I don't see any fundamental difference between "completion" and "non completion". I do see that in some cases, the completion code may try to "generate" new file names, and maybe in these particular sub-cases it would make sense to bind non-essential, but not wholesale around the whole completion operation. Stefan