From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel,gmane.emacs.tramp Subject: Re: TRAMP: Host name must not match method ... Date: Mon, 19 Aug 2013 14:07:43 +0200 Message-ID: <87haelopdc.fsf@gmx.de> References: <87y581dbfl.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1376914090 27112 80.91.229.3 (19 Aug 2013 12:08:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Aug 2013 12:08:10 +0000 (UTC) Cc: tramp-devel@gnu.org, emacs-devel@gnu.org To: Matt McClure Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 19 14:08:12 2013 Return-path: Envelope-to: ged-emacs-devel@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 1VBOFm-0000ed-Fd for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2013 14:08:10 +0200 Original-Received: from localhost ([::1]:42670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBOFl-0006UI-HW for ged-emacs-devel@m.gmane.org; Mon, 19 Aug 2013 08:08:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBOFb-0006GG-KL for emacs-devel@gnu.org; Mon, 19 Aug 2013 08:08:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBOFT-0001xx-FC for emacs-devel@gnu.org; Mon, 19 Aug 2013 08:07:59 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:53367) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBOFT-0001xU-68 for emacs-devel@gnu.org; Mon, 19 Aug 2013 08:07:51 -0400 Original-Received: from detlef.gmx.de ([91.41.141.193]) by mail.gmx.com (mrgmx101) with ESMTPS (Nemesis) id 0Lyi0B-1W7fjm2Qlz-0164at for ; Mon, 19 Aug 2013 14:07:50 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V03:K0:fj/ojpwngQ6ot9XjoLmT618cR2JsxEgzRnOFEopMN38fi3a/cYQ l6iraHdbLsdHF9OjQLrSiXEpewNfgM6COyDKpUwVcDiy/Jx/Jb/67C+MK7VBQ3jCSMu5QrB IIY9vpfap/0awYHgS6jj5vDjaSQcYMDVGdFTY4bGHFd3OS9IZYbfzk+GyhvFpeCTfwRcYFR XO1/d2Yiq6lYvJEQjDzkw== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.15.15 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162874 gmane.emacs.tramp:8392 Archived-At: Matt McClure writes: Hi Matt, > Here's the backtrace the first time it stops: [...] > tramp-dissect-file-name("/ssh:" t) > tramp-find-foreign-file-name-handler("/ssh:") > tramp-file-name-handler(substitute-in-file-name "/ssh:") > substitute-in-file-name("/ssh:") > apply(substitute-in-file-name "/ssh:") > tramp-completion-run-real-handler(substitute-in-file-name ("/ssh:")) > tramp-completion-file-name-handler(substitute-in-file-name "/ssh:") > substitute-in-file-name("/ssh:") [...] > rfn-eshadow-update-overlay() Strange. The user error in `tramp-dissect-file-name' is raised only when `tramp-completion-mode-p' returns nil. That function checks (beside other things) the variable `non-essential', which is bound to t inside `rfn-eshadow-update-overlay'. So there shouldn't be any problem. Could you, please, check whether you might have shadow lisp files? Try "M-x list-load-path-shadows". In the debugger, you might also check the value of `non-essential', when you pass `rfn-eshadow-update-overlay' and the break point. > C-x C-f /ssh:vagrant@192.168.33.2:/ RET > > This time the backtrace looks different. I notice these two stack > frames that look suspicious: > > substitute-in-file-name("/ssh:vagrant@192.168.10.") > completion--sifn-requote(27 "/ssh:vagrant@192.168.10.2:/") Here I don't see exactly what happens; I'm not so familiar with the completion code in minibuffer.el. But maybe this is caused by the same reason as the first break, let's see. Best regards, Michael.