Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Those should be included already though in
https://github.com/geany/geany/blob/master/scripts/gtk-bundle-from-msys2.sh#L251
we still have "win32". Maybe I missed to update ir accordingly.
No, gspawn-win64-helper.exe and gspawn-win64-helper-console.exe seem to be missing from the script.
Ohhhh.
Did you try Geany's spawn API (spawn_async_with_pipesetc.)? IIRC
these use Windows native APIs on Windows and maybe this helps.
I'm afraid that for jsonrpc-glib I need the GIOStream interface which I get from gsubprocess using https://docs.gtk.org/gio/ctor.SimpleIOStream.new.html. But there's nothing like that in the spawn API.
That said, I have an idea (or hope at least). I've only been testing this on an arm64 VM under macOS. This means that the Geany x86_64 process is emulated there (works surprisingly well) and launches an arm64 server (I tested it with the go LSP) so what happens is that there's this launch sequence:
Geany (x86_64) -> gspawn-win64-helper.exe (x86_64) -> gopls (arm64)
So something emulation-related can go wrong on the way and it may work correctly on a x86_64 native machine (I'll try to test it if I survive Windows update on that machine after 1 year of inactivity).
Admittedly, I have no clue about LSP but some how intuitively I assumed
the client and server communicate via network.
Could this be a solution, to (at least on Windows) have the plugin talk
to the server via TCP/UDP/whatever network protocol?
Some servers support TCP/IP communication but typically stdin/stdout is used (the client, i.e. the LSP plugin, is responsible for launching/terminating servers so it normally has access to their stdin/stdout).
(I can see you haven't tried the LSP plugin yet :-P)
The only LSP server I've seen so far that requires TCP/IP is the one for Godot but this is because this server runs as some game-development server regardless of LSP and LSP clients just connect/disconnect to/from it.
Since most servers support stdin/stdout communication, I actually didn't implement TCP/IP support in the server and kept the "simple" (well, apart all of the process management) logic that LSP servers are launched by the client. Instead, I developed this proxy (written in python so the development was much easier than the usual C + glib)
https://github.com/techee/lsp-proxy
that communicates with the LSP client (i.e. the LSP plugin) using stdin/stdout but can use TCP/IP towards the server (or support multiple servers for a single language).
In any case, yes, in the worst case I could try to implement the TCP/IP communication in the plugin but not many servers support it (clangd which the OP wants to use does support it though).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.