but that just seems to exit without doing anything so I guess I’m running it wrong (the --node-ipc was a guess from looking at some other project I think – but it seems to do the same thing without that flag).
Thanks, not sure what I’m doing wrong, but on commit b0a5c83, running it without options for me (ubuntu 18.04) exits successfully without leaving any new processes running, and nothing listening on TCP.
I’m not very familiar with the node APIs, but I don’t see something in server.ts that looks like it’s supposed to listen over TCP. It looks like the top level essentially just calls process.on(‘message’, …), which is documented to communicate with a child process, but I don’t see anything obvious that looks like it’s supposed to start one of those – and of course my editor will not be a child process of the server. So since I’m obviously not understanding how it works, I’m not sure how to debug. Any further hints appreciated…
Ah right, yeah so it seems the server process runs with IPC communication by default. This is why it works with vim-coc out of the box. Usually LSP’s implement a --stdout flag to also allow communication through stdin / stdout, that’s what many other lsp client plugins use. We don’t implement any different communication mode though.
Is there a way to tell the emacs lsp mode to communicate with the server via ipc?
Right: from my initial quick look at the emacs code I suspect all the LSP support is currently using stdout, and indeed I had the impression that rescript-vscode currently doesn’t support that, thanks for confirming that.
But my questions are: Am I correct that server.ts is supposed to start listening on a TCP socket? What code is supposed to do that?
Sorry I should probably just install VS-code and watch what happens – and I’m sure I would just for debugging purposes if I got into this – but for now I’m trying to just get an idea how much work would be entailed in making this work in emacs, and that’s (installing / using VS code) a bit of a detour on a detour for me.
Ah, we had different understanding of “IPC” I think: to me that meant just any inter-process communication (TCP, yaml over stdout, whatever), to you specifically node IPC as exposed in the node API as process.on, process.send, child_process.fork etc.
Looking at server.ts again this morning it seems obvious: VS code runs server.ts using child_process.fork or similar, which tells node to run that program with an implicit event loop.
Thanks for your help
So I guess to support emacs, one (I’m certainly not promising to do it) would need to do one of:
Modify the rescript-vscode server to add support for starting it other than from another node process, I guess adding some (optional?) explicit event loop, to be exposed on the commandline as a --stdout flag
Write some emacs code to pretend to be a node process by simulating whatever it is that node does to implement child_process.fork (maybe that’s supposed to be a private implementation detail of node though)
Write some intermediary in JS/TS that speaks both node IPC (to talk to rescript-vscode) and JSON-RPC-over-stdout (to talk to emacs LSP)
I don’t know which of those is sanest yet – my googlings on this subject of the communication channels that the JSON-RPC goes over haven’t turned up much.