Re: tramp (2.4.3.27.1 nil/nil); Sudo password prompt matching broken on MacOS for emacs27

[Jimmy Yuen Ho Wong]

Ok sorry forget what I said earlier, I just retested everything by
elimination, there are actually multiple problems at play here and one
was covering another.

Bug 1:

If `ido-enable-tramp-completion` is set to `nil`, it's impossible to
open a file as root with `ido-find-file`. Here are the reproduction steps:

1. In Terminal, $ /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs -Q

2. M-x ido-mode

3. M-x set-variable ido-enable-tramp-completion RET nil RET

4. C-x C-f //sudo:

5. Minibuffer prompt will show `File file: /sudo:/ [No match]` and
there's no way to remove the auto completed / in the end.


Bug 2:

1. $ echo 'PATH=".:$PATH"' > .bash_profile

2. $ echo '(require
'exec-path-from-shell)(exec-path-from-shell-initialize)' > .emacs

3. $ /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs 

4. C-x C-f /sudo:: RET

5. Cursor now stops blinking but no password prompt is shown.

6. If you TAB complete after /sudo: but before the final :, prompt will
not be stuck


This bug can only be reproduced if steps 1-3 are followed exactly. The
following examples can't reproduce this problem:

* $ /Application/MacPorts/Emacs.app/Contents/MacOS/Emacs -Q -l tramp -l
/path/to/exec-path-from-shell --eval '(exec-path-from-shell-initialize)'
/sudo::

* $ echo '(set exec-path (cons "." exec-path))' > .emacs;
/Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs

There's some very weird interactions with how Emacs starts up, what
happens to Emacs after `call-process` on SHELL  and setting `exec-path`,
and tab completion of /sudo:: in the minibuffer. This appears to have
been the case since relatively early versions of Emacs 27.


Bug 3:

1. Same as Bug 2

2. $ echo '(require
'exec-path-from-shell)(exec-path-from-shell-initialize)(require 'crux)'
> .emacs

3. Same as Bug 2

4. Same as Bug 2

5. M-x crux-sudo-edit

6. Minibuffer now stuck at "Tramp: Sending Password"


This one is why I originally reported here. Possibly due to similar
reasons as Bug 2.

Does it sound like a Tramp issue? Should I report this to emacs-devel
instead?

Thanks for bearing with me.