Question: Features: LSP? Client-server architecture?

[losnappas]

Hi, is there LSP support, is there plans for it?

2nd, how about a client-server architecture where I can connect the editor to the same session from multiple terminals, a la kakoune/emacsclient?

[sminez]

LSP support is something I'm hoping to look at in the near future but there's nothing in place currently.

Client server wise that was part of my original design but it's not currently how things are currently set up as it would mean that all actions end up being RPC calls rather than in process. I'd like to have a think about how / if it would be a useful addition before committing one way or the other on adding it 🙂

[rakoo]

About LSP, Acme has an LSP client: acme-lsp

One might try to hack on it to adapt it to ad, and I think the 9p interface of ad makes it so that an external program like that is "enough", and it is not needed inside ad itself

[sminez]

I'm aware, yeah 🙂

The acme client actually has quite a lot of acme specific logic in it I think (it did last time I checked) so I'm exploring options of what would be easiest to work with.

At the very least I'd like nice support for go to definition, formatting, hover text and maybe suggestions. Fully implementing all of LSP isn't something I want to tackle as part of ad itself but like you say, the filesystem interface should be sufficient for external clients to implement whatever LSP functionality you want

[losnappas]

Thanks for the responses! Good to hear about lsp, that it's on the map. It's often a big pain point, I've seen multiple editors having a long tail of "bugs" (features they didn't think of, like multiple language servers for 1 file).

Client server wise that was part of my original design but it's not currently how things are currently set up as it would mean that all actions end up being RPC calls rather than in process. I'd like to have a think about how / if it would be a useful addition before committing one way or the other on adding it

Interesting. Perhaps there's something like "server functions" from React (web dev world), where a regular function call gets transformed into a HTTP request during compilation step (browser->backend), for rust.

[sminez]

Sorry, I probably didn't explain what I meant very clearly: ad's filesystem interface is already an RPC mechanism that would allow you to have a client UI running in a separate process if you added a few other control files. It's just that doing things this way adds the overhead of using the RPC protocol to every editor interaction which is always going to be slower and less efficient than doing things in a single process.

I've had people ask about remote editing and sharing editing sessions which technically would work but the experience wouldn't be great I don't think. At least under the current implementation. That as a workflow isn't something I'm looking to focus on any time soon but I have some ideas around how I would approach it as and when it became something I was interested in pursuing :slightly_smiling_face:

[losnappas]

Oh yeah, that makes sense. Idk how much overhead it is but I personally would gladly endure quite some, the workflow upgrade to have windowing using my WM is worth it.