tower-lsp VS kakoune-lsp

I am using nom / nom_locate to build the parser side because I've done a handful of other projects with it, and I plan to use tower-lsp to hook up the language server side.

I realize this might not be for everyone, but I'm writing it in Rust using Lib-ruby-parser and tower-lsp: two existing libraries that handle a bunch of the heavy lifting for me. I'm more productive in Rust than with Ruby at this point, despite doing Ruby full time for 15 years, plus I really really don't want to have to deal with a slow LSP--that was the whome impetus for this project. I started in the spring, made a bunch of headway, then backtracked to redo the internals to make it easier to handle monkeypatching, overriding/redefining of methods, etc. across your project.

https://github.com/ebkalderon/tower-lsp is a generalized LSP implementation in a lower-level language (Rust) so you may get a better idea by reading through that repo. It seems that the server opens a TCP socket that the client later connects to, but I'm not really sure.

I was taking a look at the tower_lsp example here (https://github.com/ebkalderon/tower-lsp/blob/master/examples/stdio.rs) and had a question about how the document sync works between the client and the server.

Mine all use [tower-lsp](https://github.com/ebkalderon/tower-lsp/) for the LSP protocol stuff, and then either [Tree-sitter](https://github.com/tree-sitter/tree-sitter) or [Nom](https://github.com/Geal/nom). If I do another I'll probably try [Chumsky](https://github.com/zesterer/chumsky) which combines some of the advantages of both.

Kakoune with LSP (gopls).

You could dive into installing kak-lsp, which will provide the code intelligence features you want. Kakoune doesn't do windowing on it's own, so your going to need to rely on something like tmux or a terminal emulator that does similar, such as wezterm, or even a tiling window manager (which is what is being used in the video). Kakoune really needs a lot of time invested to configure well though.

Why do you need vscode? Kakoune supports code actions, so this should work in the editor with the best editing model ever. See lsp-code-actions from https://github.com/kak-lsp/kak-lsp.

In addition, rather than using its own full-fledged programming language for plugins or choosing to use a specific programming language, it provides a limited configuration language that's closer to a domain-specific language and to be used as a "glue" between Kakoune and programs written in any language. For example, the kak-lsp plugin uses a program written in Rust that is integrated with Kakoune with a thin wrapper of Kakoune's configuration language.

If you're having problems with these capabilities, try to look at the kak-lsp debug output: https://github.com/kak-lsp/kak-lsp#troubleshooting

kak-lsp doesn't print to *debug* under normal operation. If you want to check on kak-lsp, enable verbose logging as described here and tail -f the log file.

So, since pretty much everything happens through a shell, you can use anything that produces an executable to write your logic. kak-lsp, for example, is written in Rust, with some kakscript to define the commands, hooks and options a user needs to interface with it.