Subject: Re: bug#39389: 27.0.60; A couple of bugs messing with minibuffer completion of /sudo::

From: Michael Albinus <[email-masked]>
Date: Wed, 05 Feb 2020 15:39:57 +0100

Jimmy Yuen Ho Wong <[email-masked]> writes:

Hi,

>> > I expect either that variable didn't exist and Tramp file name
>> > completion was always fast, or when it's off, ido just reverts back to
>> > the behavior of the regular `find-file`, which should allow me to type
>> > out the whole Tramp syntax.
>>
>> Why do you expect this? At least the docstring of that variable doesn't
>> tell that ido behaves like this, when the variable is set to nil.
>
> Because no reasonable person will knowing turn on something that will
> break tramp during find-file completely.

It is not about turning *on*, it is about turning *off* (setting
ido-enable-tramp-completion to nil). I, for example, would not expect
remote file names to work, after setting a variable with this name to nil.

>> I agree with you, that the variable shall document its behaviour in this
>> case.
>>
>
> It's not a documentation problem. It's called the principle of least
> astonishment, and the culprit for bug 1 is hidden somewhere in
> `ido-read-internal` in one of the 2 cases that deals with tramp
> syntax.

admin/MAINTAINERS does not mention anybody who feels responsible for
ido.el. I hope somebody can chime in. I'm not such familiar with ido.

> For bug 2 and 3, there's definitely something wrong with the
> `auth-source-search` call in `tramp-read-passwd` that's blocking the
> display of the password prompt, as the same workaround works for both
> issues.

Both bugs require exec-path-from-shell.el MELPA, which I don't use. Have
you contacted the author of that package, for debugging?

Before seeing evidences, I wouldn't say that "there's definitely
something wrong with the `auth-source-search` call in
`tramp-read-passwd`". It is used by many users as it is.

Best regards, Michael.