Merlin mode over TRAMP is broken

[ihodes]

http://link.isaachodes.io/203z292h1L28/Screen%20Shot%202016-03-10%20at%2011.27.33%20AM.png

I don't expect it to work, but I don't expect it to take over emacs. Even when I'm working on a buffer outside of TRAMP, these errors persist.

[trefis]

I expect this is with the master version which you will have built from source? Try using the "beta" branch, which actually isn't a beta but a legacy branch; yes we're good with names.

Also, what is TRAMP?

[ihodes]

I'm on 2.3.1, opam-installed (didn't give building from source a try yet, given my previous issue).

TRAMP = lets emacs manipulate files over ssh.

[trefis]

OK thanks!

So, this kind of error usually means that your merlin binary and the merlin.el loaded by emacs speak different versions of the protocol, which means that you're either using an old ocamlmerlin binary which might have been lying around somewhere, or a merlin.el file that you installed by some other means different from opam.

Can you make sure that it is not the case?

[ihodes]

They appear to be the same versions (both from the opam installation in the same location). I think this had to do with merlin in emacs trying to talk to merlin on my remote machine, via TRAMP, which doesn't have ocamlmerlin installed.

[fxfactorial]

@ihodes I use merlin with tramp, works just fine.

My only tramp support in init.el is:

(setq tramp-default-method "ssh") (setq password-cache-expiry nil)

And need to have merlin binary on the remote machine.

[ivg]

Doesn't work for me. Tried with both methods "ssh" and "scp", here is the log:

Tramp: Opening connection for xenial using ssh...
Tramp: Sending command `exec ssh   -o ControlMaster=auto -o ControlPath='tramp.%r@%h:%p' -o ControlPersist=no -e none xenial'
Tramp: Waiting for prompts from remote shell...done
Tramp: Found remote shell prompt on `xenial'
Tramp: Opening connection for xenial using ssh...done
Tramp: Inserting `/ssh:xenial:/home/ubuntu/factory/bap/src/bap_main.ml'...
Tramp: Encoding remote file `/ssh:xenial:/home/ubuntu/factory/bap/src/bap_main.ml' with `(gzip <%s | base64)'...done
Tramp: Decoding local file `/tmp/tramp.18837QFY.ml' with `(lambda (beg end) (base64-decode-region beg end) (let ((coding-system-for-write (quote binary)) (coding-system-for-read (quote binary))) (apply (quote call-process-region) (point-min) (point-max) (car (split-string gzip -d)) t t nil (cdr (split-string gzip -d)))))'...done
Tramp: Inserting `/ssh:xenial:/home/ubuntu/factory/bap/src/bap_main.ml'...done
Starting merlin instance: default (binary=ocamlmerlin).
selected directory: #("/ssh:xenial:/home/ubuntu/factory/bap/src/" 1 4 (tramp-default t))
Error in merlin/send-command-async callback: (error "Command ((assoc) (document auto /ssh:xenial:/home/ubuntu/factory/bap/src/bap_main.ml) (query protocol version 3)) failed with error nil")
Error in merlin/send-command-async callback: (error "Command ((assoc) (document auto /ssh:xenial:/home/ubuntu/factory/bap/src/bap_main.ml) (query tell start end open Core_kernel.Std
...

On both machines I have installed from opam:

• merlin 2.5.0
• tuareg 2.0.10

The remote machine is actually a vagrant box, with access configured via .ssh/config

[fxfactorial]

I used to have merlin work just fine over tramp, now its busted with spurious buffers.

[let-def]

Tramp applies emacs properties on the filename of the buffer. Those get sent to merlin which doesn't know how to parse properties.

I will fix this, but it will take some time. In the meantime, I think the proper behavior should be:

• when TRAMP is used, the merlin binary to use should be looked up on the remote host by TRAMP (you might have to adjust paths)
• paths need to be translated. This feature is generally useful for using merlin through VM, so a general solution might be needed.

[fxfactorial]

Here's one thing I noticed:

I have merlin working if I do:

/ssh:name_of_other_machine:/some/path/to/project, that fixed the spurious buffer issue,

but then merlin didn't want to respect the .merlin of the other machine.

[let-def]

Docker also has a similar path mapping problem, I opened #611 to track developments related to both.