I pushed up a working (but lots of rough edges) REPL-over-LSP implementation (leveraging GenLSP by forking Next LS):
Demo video here: Michael Russo on X: "Elixir "REPL-over-LSP", now with a working prototype 🎉 (Kudos to @mitchhanberg for writing GenLSP and Next LS, which made this almost too easy :) Demo here: #myelixirstatus https://t.co/qL9usFPLz0" / X
It’s important to note that I didn’t modify Eglot (LSP client that ships with Emacs), besides telling it where to find my LSP server.
@mauricio.szabo wrote:
@mjrusso problem of integrating in LSP is that we don’t actually solve client issues. I don’t believe any LSP client that exists now expects an “evaluate” operation, and while that can be added, clients don’t actually have any logic for this kind of interaction to happen - meaning there are no UI design to handle evaluations, for example.
The great advantage to reuse some nREPL client is that if the client/plug-in doesn’t send all the information, the only actual change they need to add is to send that info - every other task related to “evaluate something and get back a result”, like some “awaiting result” state, or a command to “break” the evaluation, are probably already present. Piggiebacking on something that exists, even if it needs some adjustment, can be a huge advantage compared to start something fully custom that will need to start up implementations from scratch.
I know this is kind of a weird chicken-and-egg situation, where we need client support to justify a server implementation, and we need server support tonikplement the ckient side too 
To clarify my position: I think LSP support is a net positive because it makes it extremely easy for LSP users to experience the joys of REPL-driven development. That being said, I would personally use a better, more focused tool if one were available that worked with my editor-of-choice. In my ideal world we’d have both kinds of options
A few more notes about REPL-over-LSP:
- Elixir is pretty unique because (ironically) there’s no need to expose a REPL UI in the editor: you can already IEx into whatever node you want.
- I don’t think that most of the UI issues you mention are blockers. LSP supports showing arbitrary messages, for example (although of course it didn’t work in my demo video linked above, but I have seen it work while I was implementing this… I must have broken something at some point, or hit some bug somewhere).
All that being said, you can absolutely do a better job with a focused tool, and nREPL is certainly better.
@cevado wrote:
I’m stuck in a bunch of stuff that I already started, but I was planning to glue together your implementation of nrepl with the auto-complete/intelisense from LIvebook(that part of the code is pretty much isolated) to show how we could get a better autocomplete with nrepl.
Amazing, I’m really looking forward to seeing this!
I understand the idea of leveraging the already existing LSP infrastructure as a starting point, but as a long term thing it feels like diminishing all the power that comes from an nrepl approach(that is you being already inside in a live system).
Just a small point of clarification, the two approaches are the same in the sense that you also get an equivalent live system in the LSP case. (At the cost of more moving parts: the LSP server acts as a sort of proxy for eval’ing code on a networked node.) I explain how this works in this video: Michael Russo on X: "Follow-up demo with more details about how an Elixir "REPL-over-LSP" setup might work: #myelixirstatus https://t.co/J4MjFXa0WA" / X
Thanks for pinging me. Some really great discussion here.
