bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39389: 27.0.60; A couple of bugs messing with minibuffer completion


From: Jimmy Yuen Ho Wong
Subject: bug#39389: 27.0.60; A couple of bugs messing with minibuffer completion of /sudo::
Date: Sat, 8 Feb 2020 13:03:47 +0000

For bug 2 and 3, the author said `file-remote-p` might have triggered
some weird code paths that triggered this bug. I don't know how to
edebug further as `redisplay_internal` keeps calling it. Do you know
how to debug it?

https://github.com/purcell/exec-path-from-shell/issues/95#issuecomment-582629738

On Wed, Feb 5, 2020 at 2:39 PM Michael Albinus <address@hidden> wrote:
>
> Jimmy Yuen Ho Wong <address@hidden> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]