Wrong behaviour with Tramp and custom method

[jeberger]

Hi,

I have a custom Tramp method to configure remote access using Putty. This method is called jmb and was appended to tramp-methods. You can see the custom method here. Now I have a wrong behaviour the first time I try to use this method in counsel-find-file.

Steps to reproduce

• Close all Tramp buffers and connections: tramp-cleanup-all-connections.
• Enable ivy-auto-select-single-candidate.
• Start counsel-find-file.
• Type /jmb: followed by RET.

Expected behaviour

• I should get a user@host prompt.
• Upon typing the user and host, I may get prompted for the password, then should see a list of remote files which I can navigate.

Observed behaviour

• I get a user@host: /jmb:jmb: prompt.
• Upon typing the user and host, I get a Tramp error "failed to connect" and am sent back to the user@host: /jmb:jmb: prompt.

Extra information

• If I type /jmb:user@host: before typing RET, everything works fine.
• If I have an open remote buffer, or simply an active Tramp connection in the background, everything works fine.
• If I type /ssh: followed by RET, I get the expected user@host prompt. If I then cancel with C-g and retry with /jmb: followed by RET, everything works fine. Note that in that case, I get offered a choice of ssh or jmb as completion for the user@host prompt, but I can still ignore the choices and proceed with the actual user and host.
• If I disable ivy-auto-select-single-candidate, I get the expected user@host prompt with a single jmb candidate which I can ignore.

[abo-abo]

I don't know the intricacies of tramp, so I can't make a proper fix. I added code that disables ivy-auto-select-single-candidate on remotes. Please test and let me know if it fixes your problem.

[jeberger]

Nope: file-remote-p: Wrong type argument: stringp, nil

[jeberger]

Don't waste too much time searching for the problem. I just realized that I no longer need my custom Tramp method with recent Tramp versions, and counsel-find-file works fine with the standard Tramp methods, so there's no hurry to fix this.

[jeberger]

Note that ivy--directory will always be nil when the problem occurs, so the check for file-remote-p is superfluous. Moreover, your fix will disable ivy-auto-select-single-candidate for all cases where ivy-directory is nil. A better workaround would probably be to let-bind ivy-auto-select-single-candidate to nil when calling ivy-read for user@host in ivy.el:767.

I have completed a more thorough analysis of the problem, and I think I understand the sequence of events that create it:

• When I type /jmb: followed by RET, ivy--directory-done tries to open /jmb: as-is (probably because of a call to file-exists-p or something like it), which delegates to Tramp.
• Tramp fails to open /jmb: but it remembers the attempt in its connection history. The connection history now contains an attempt to connect to host "jmb" with user nil.
• Now ivy--directory-done asks Tramp for possible completions for user@host. Tramp looks into the history and finds the (nil, "jmb") entry that just got added and nothing else.
• Since there is a single user@host candidate, the nested call to ivy-read returns immediately.
• The prompt I see is actually the remote find file prompt. I'm not sure why it starts with "user@host" instead of starting with "Find file".

[abo-abo]

Please PR with your suggested change.