Q: plans to (re)implement SLIME/SLIMV via the "host" lisp?

[phmarek]

Hi Andrej,

I started a CL RPC library for neovim quite some time ago but then didn't find any more time for it; it's nice to see that you're working on that front!

Do you have any plans to (re)implement SLIME resp. SLIMV via that one? Or perhaps an emacs lisp compatibility layer?

[adolenc]

Hey,

first of all thank you so much for your work on cl-messagepack, if it wasn't for it I definitely wouldn't get this far this quickly. I tried to separate msgpack-rpc's part of this package as much as I could from the rest of cl-neovim, but unfortunately my implementation at the moment is shoddy at best. If you ever find time to work on it I would be more than happy to switch to your implementation or accept your patches.

Both of your ideas sound really cool (the second one actually never occurred to me but has the potential to be huge) and while I really hope we eventually get SLIME implementation that makes use of neovim's multithreading in one way or another, I sadly don't have enough time to work on it in the near future.

[adolenc]

Hey,

I just made adolenc/neomacs repository, which I will use to play around with your second idea, public. Do note however that while it is a top priority, it is probably going to take me quite a while before I get something like SLIME working :) .

[phmarek]

Ouch, an interesting approach ... Not sure whether that's the best way, performance-wise.

Are you planning to interpret elisp or to do code-walking to translate to CL?

Perhaps there's some CL SLIME for hemlock, Second-Climacs, etc.?

Thanks for telling!

[justinmk]

Would it make sense to use GuileEmacs as the elisp engine? I guess since it's racket-based it is not an exact fit for a CL project, but it would save the hassle of re-implementing elisp.

[adolenc]

Welp, I didn't really expect that (basically empty) repository to spread around this much, but I suppose it's my own fault for not realizing how clickbaity the description actually sounded :D . Since the primary purpose of that project was for me to learn more about Emacs/(Neo)vim/Common Lisp, and since I am still not sure that that approach could lead to something actually usable, I am making the repo private for the time being.

@phmarek The thing is that after skimming through the Emacs documentation it seemed to me that a sizable portion of elisp has a pretty straight-forward equivalent in Common Lisp and/or cl-neovim, but I do realize that there is also a large portion that would be very tricky to implement. In any case I decided to try doing it this way because I could either port slime to use CL and cl-neovim and become the maintainer, or I could try doing it this way and (if successful) the project could serve as a springboard for "ports" of other Emacs plugins; and the latter sounded more appealing to me.

I honestly have no real intuition about the performance (getting slime to work via neomacs was going to help me get it), but I would expect the communication between Neovim and cl-neovim to be the bottleneck? But then again, won't this really be a problem for any approach?

@justinmk With how massive a project (re)implementing elisp could end up being, doing something like that is probably the more sane option. Unfortunately I only really know r5rs and figuring out Racket to me is a lot less fun than hacking around in Common Lisp, so I'll probably leave that idea to somebody else :)

[phmarek]

@adolenc Any ideas how the emacs keybindings would be "translated" to Neovim? Reading #lisp there's always some talk about Meta-this and Control-that ... using the exact same combinations would

• result in conflicts
• not match the vi "object" model (word, line, paragraph,...)
• be still different from the current vim ways (eg. slimv bindings)...

I guess the keyboard bindings would need to be hidden behind a :EmacsKey function (which would call the elisp functions), with vim-bindings the user is accustomed to added as necessary...

[HiPhish]

Hi, I have been learning Common Lisp for the past few weeks and re-implementing Slime would be really cool. Do you have any progress to report?

I have looked into how Slime works: there is a backend server called Swank that does the heavy lifting and an Emacs client (the actual Slime) that sends data to the server and receives responses.

Swank is included in Slime and there is no Swank-only repository, but we could just ignore the Slime stuff and waste a few MBs of disc space. Or we try to convince the Slime developers to make Swank its own repository. It doesn't really matter, Swank can be installed via Quicklisp: (ql:quickload "swank").

From there on all that's left is "just" recreating the frontend to work with Neovim. It wouldn't have to be written in Common Lisp, but it would be appropriate to require Common Lisp in a plugin that's already working on Common Lisp anyway. There is a swank-client package that can abstract the Swank interaction for us, so that would make it easier to work with Swank since the Swank protocol doesn's seem to be documented anywhere: https://github.com/brown/swank-client

I wouldn't simply port Slime over to Neovim, Slime is a product of Emacs's plugin culture and many of its conventions (especially the key-combos) make no sense in Vim. Personally I wouldn't ship with any bindings and instead provide a sort of language that follows a consistent gramma. Using Vim is already like speaking a language with the editor, so that makes sense. The key point here is to make it consistent, kind of like comparing the commands for lldb with those of gdb if you have used those two debuggers. Users can then map keys to those commands any way they wish to.

" Comiling a top-level expression:
:Slime compile toplevel

" Compiling the current expression
:Slime compile current-exp

" Send an expression to the REPL
:Slime send-to-repl toplevel

You get the idea. I would also not call it Slime, Slime stands for Superior Lisp Interaction Mode for Emacs. How about Slip.nvim: Swank-Lisp Integration Plugin for Neovim?

[phmarek]

@adolenc: would you care to allow help on neomacs?

[phmarek]

@adolenc: How's it going? Can we help with neomacs? At least testing would surely be within reach...