bug#7583: 23.2; ido loads tramp too eagerly

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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