Using Tramp on 2 Remote Servers Simultaneously Fails

[falloutphil]

Hi,

I can successfully use anaconda lookups and just to definitions etc when using Tramp - providing I stick to the rules regarding host names and fix the port number for the RPC service so that we can use it with a firewall. This is very cool!

Recently I noticed that if I'm working on 2 different Python projects in the same emacs instance, but where the code for each project resides on a different server, anaconda-mode will only do lookups, etc against one of those servers.

To demonstrate this I can load up a python file using Tramp (on server A) and hit M-. over a function call, anaconda-mode will take me to the definition, even if it is in a different remote file.

However if I then switch to another python file on a different server (server B), anaconda does not get a response.

To prove the issue is not just an issue with server B, I can reverse the experiment and first try to connect to the file on server B. Here M-. works, but a subsequent attempt do perform the same command on server A, now fails.

I've repeated this several times to show it's definitely a pattern, based on which server is connected to first.

My guess is that only a single RPC Service is ever established and subsequent requests to a different Tramp remote connection result in the RPC request going to the first server, incorrectly.

Ideally this would be fixed so that it could seamlessly handle multiple servers, but an obvious workaround would be a way of tearing down the connection manually using an emacs command, or perhaps just killing anaconda-mode completely and restarting it would work?

Could you confirm the bug is genuine, and advise the most practical work around?

[falloutphil]

A quick cheap and cheerful workaround is:

;; Used when wanting to switch remote servers
(require 'anaconda-mode)
(defun stop-anaconda ()
    "Stop any currently running anaconda-mode process"
    (interactive)
  (anaconda-mode-stop)
  )

Ideally you'd add this to a hook when changing from one to another workspace so that it happens more or less seamlessly. Using workspaces2 package this can be done easily enough:

;; Kill anaconda every time we switch workspace                                                                                                                                                              
(customize-set-variable                                                                                                                                                                                      
 'wg-after-switch-to-workgroup-hook 'anaconda-mode-stop)

The source code could be trivially updated to make anaconda-mode-stop itself interactive.

[proofit404]

Hi, thanks for the issue.

Ideally, we should support running multiple anaconda-mode servers. One for the virtual environment.

Regards, Artem.

[Knusper]

I think this even occurs, when one works on a local project and a remote project the same time... Quite annoying tbh.