Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong behaviour with Tramp and custom method #1326

Closed
jeberger opened this issue Nov 28, 2017 · 5 comments

Comments

@jeberger
Copy link
Contributor

commented Nov 28, 2017

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 added a commit that referenced this issue Nov 28, 2017
@abo-abo

This comment has been minimized.

Copy link
Owner

commented Nov 28, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 28, 2017

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

@jeberger

This comment has been minimized.

Copy link
Contributor Author

commented Nov 28, 2017

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.

abo-abo added a commit that referenced this issue Nov 28, 2017
@jeberger

This comment has been minimized.

Copy link
Contributor Author

commented Nov 29, 2017

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

This comment has been minimized.

Copy link
Owner

commented Nov 29, 2017

Please PR with your suggested change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.