> 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_pipes` etc.)? 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 or view it on GitHub: https://github.com/geany/geany/issues/4082#issuecomment-2506639984 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/issues/4082/[email protected]>
