bug#32591: 26.1; Ido-find-file does not intuitiely support tramp

[Lars Ingebrigtsen <larsi@gnus.org>]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

Michael Albinus <michael.albinus@gmx.de> writes:

> Ido greys out "~/" because of the double slash. It has nothing to do with
> a remote file name. Again, there is no remote file name, only a string
> which might be a remote file name when it is complete.
>
>> Type a : to specify a path and watch the "~/" get un-greyed out.
>
> That seems to be an ido problem. With plain "M-x find-file" I cannot
> reproduce it.
>
> However, even if this grey out does not work as expected, I believe that
> opening the file (after entering RET) still works as expected.

Let's see...  I `C-x C-f' while in a Tramp-ey buffer:


[-- Attachment #2: Type: image/png, Size: 7642 bytes --]

[-- Attachment #3: Type: text/plain, Size: 22 bytes --]


Then type ~/.emacs:


[-- Attachment #4: Type: image/png, Size: 9765 bytes --]

[-- Attachment #5: Type: text/plain, Size: 684 bytes --]


So the greyed-out parts here seem to say that we're going to get
~/.emacs on the remote host...  and hitting RET does indeed give me
that.

To get the ~/.emacs on the local machine, I have to delete everything in
the minibuffer and type ~/.emacs.

I've been tripped up by this before, because I'm so used to just typing
`C-x C-f ~/.emacs RET' without even looking (to get to my local .emacs
file).  But I think the current behaviour is the intended one, really --
it's consistent, powerful and makes sense.

So I'm closing this bug report -- I think this is working as intended.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no