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#7583: 23.2; ido loads tramp too eagerly Date: Tue, 18 Oct 2011 15:04:27 -0400 Message-ID: References: <8739esu4p6.fsf@gmail.com> <8739eslo7f.fsf@gmx.de> <87y5wkskfd.fsf@gmail.com> <87ty78rvlf.fsf@gmail.com> <878vojya45.fsf@gmail.com> <87botfpn4e.fsf@gmail.com> <87boteq2nm.fsf@gmail.com> <87ehyas07i.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1318964861 25119 80.91.229.12 (18 Oct 2011 19:07:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2011 19:07:41 +0000 (UTC) Cc: Michael Albinus , 7583@debbugs.gnu.org To: Thierry Volpiatto Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 18 21:07:37 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 1RGF0i-0005w3-Pb for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Oct 2011 21:07:37 +0200 Original-Received: from localhost ([::1]:44021 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGF0i-0005mL-1B for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Oct 2011 15:07:36 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:34141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGF0e-0005ki-Lw for bug-gnu-emacs@gnu.org; Tue, 18 Oct 2011 15:07:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGEyG-0001BT-Bc for bug-gnu-emacs@gnu.org; Tue, 18 Oct 2011 15:05:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGEyG-0001Ak-9M for bug-gnu-emacs@gnu.org; Tue, 18 Oct 2011 15:05:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RGEzB-0005Wo-Pd for bug-gnu-emacs@gnu.org; Tue, 18 Oct 2011 15:06:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Oct 2011 19:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7583 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7583-submit@debbugs.gnu.org id=B7583.131896473221212 (code B ref 7583); Tue, 18 Oct 2011 19:06:01 +0000 Original-Received: (at 7583) by debbugs.gnu.org; 18 Oct 2011 19:05:32 +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 1RGEyi-0005W5-7Q for submit@debbugs.gnu.org; Tue, 18 Oct 2011 15:05:32 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RGEyd-0005Vt-MB for 7583@debbugs.gnu.org; Tue, 18 Oct 2011 15:05:29 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p9IJ4Rcq001524; Tue, 18 Oct 2011 15:04:27 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id D28F7B4031; Tue, 18 Oct 2011 15:04:27 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4014=0 X-NAI-Spam-Version: 2.2.0.9286 : core <4014> : streams <692907> : uri <986502> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 18 Oct 2011 15:06: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:52811 Archived-At: > To e.g "/ssh:" which is an incomplete address > and hang indefinitely. > Just like when you do C-x C-f and enter in prompt /ssh: and press RET. I'm beginning to understand. Indeed, I see that C-x C-f /ssh: RET and C-x C-f /sudo: RET both behave oddly (they try to connect to hosts `ssh' or `sudo'). They don't hang for me, but arguably they should not even try to treat the "ssh" or "sudo" as a hostname. Michael? >> "vanilla Emacs completion" uses try-completion, so you must thinking of >> some other "elsewhere". What is that other "elsewhere"? > External libraries like anything create completion modes that replace > most completing-read's. > So the completing-read that use all-completions are ok, but the one that > use try-completion are usable only in a vanilla Emacs environment. So you're saying that Tramp handles try-completion subtly differently from all-completions and that your completion code uses try-completion subtly differently from the way vanilla completion uses it. I wonder if the first pat is indeed true, and if so why (could be that it was a hack to try and distinguish icomplete/ido from TAB, back when we didn't have non-essential). As for the second part, I have no reason to doubt you, tho I'd be interested to try and understand how it is different and why that triggers the problem. My guess is that you're doing something similar to lightning completion (i.e., roughly, call minibuffer-complete after every key-press), yet ... ..Oh, wait, I think I see something interesting: % emacs -Q C-x C-f /ssh: TAB RET RET C-x C-f /ssh: TAB The first C-x C-f just ends up loading Tramp then trying to connect to `ssh' and fail, but it also changes something inside Tramp because on the second C-x C-f the TAB causes Tramp to try to connect some "default" host (apparently it uses the first host in my ~/.ssh/config, and subsequent attempts will try subsequent hosts in that file). We don't want that, and your completion scheme might be bumping into this very problem. Michael? > No i say completion in Emacs is made differently so it is acceptable, > though it should not hang like described above. I think you're just seeing the result of bugs. Stefan