EmacsConf2022 - lsp-bridge: a smooth-as-butter asynchronous LSP client

The fact that lsp-bridge doesn't use the regular completion at point functions such that you are bound to it's proprietary one is an absolute dealbreaker for me and I believe many more. Corfu, Vertico, Marginalia etc. all make it so much easier to extend emacs and composite your config compared to what was previously needed to "helmize" every new package. I don't see how lsp-bridge's way is really that benefitial to offset these "costs".

I have been using the emacs fork from the LSP authors (which makes JSON processing async) and have found it to be a much smoother, essentially invisible solution to the same problem: https://old.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance I think they intend to upstream their changes, but so far it has been working beautifully for me.

I saw in that thread that you’re using nix as well. How are you building this fork with nix? I’m tired of how shitty tsserver is

Yea I came to a similar experience. Is it a little "snappier"? sure. But lsp-ui, company-box, and all kinds of keybinding all break. I know the Emacs community isn't one to embrace the One True Way approach, but we're fragmented between eglot and lsp. The fact that the lsp side of the house is starting to fracture worries me a little. Hopefully some of the optimizations can be brought into the standard lsp package?

That it accepts server responses via a process filter bound to emacs's single thread defeats whatever parallelism it purports. Bravo nonetheless to its author who by all appearances is still in high school.

Someone added support straight into the [emacs overlay](https://github.com/nix-community/emacs-overlay/blob/master/overlays/emacs.nix#L136)! So all you have to do is install the emacs-lsp package from that overlay and you should be good to go

Oh nice, thanks, I’ll try it out

Some discussion about these topics in the issue which was mentioned in the talk [here](https://github.com/minad/cape/issues/52#issuecomment-1336325757).

[deleted]

> its author who by all appearances is still in high school. Please be kind & respectful as per r/emacs rules. If you want to have a Resume match with the author who happened to be in the emacs community for more than a decade and had [written hundreds of packages](https://www.emacswiki.org/emacs/AndyStewart), and who also happened to be the ex-CTO of the company behind deepin Linux distro, I suggest you take it to LinkedIn please.

Does it work with TRAMP?

You have your own focus. And it is completely fine. The author has already stated his technical decision why capf is a burden for performance. LSP-bridge sacrifices compatibility with builtin emacs functionality for better performance. He achieved his goal and his approach is completely reasonable. I do hope someone could do something that does not compromise compatibility with performances. It seems that LSP-mode changes the C code to make some progress on this. But it will take long time to get it merged to upstream (or even impossible to merge). It is promising. While LSP-bridge does not touch the C code and implements a performant one in a easier way, and again, compromised for compatibility.

You have ido, helm, ivy, vertigo. Ido is even the builtin way but I think not so many people is really using it. You have vc and Magit, and I think the majority is using Magit. For “standard LSP”, do you mean eglot, the builtin LSP?

Probably not

:(

> I thought a bit more about Lsp and the impedance mismatch. From what I remember about lsp, the server always wants to be informed about the current buffer state, such that it has a full picture. Then lsp completion is just asking for candidates at the current point and this is quite different from the Capf two-step process. To adapt Lsp to that model is kind of mind bending. If I wouldn't care about relying on existing Emacs machinery (because of my Vertico work etc), I can understand that one wants to throw this away and just rebuild something exclusively for Lsp. A quote from corfu’s author

I expected a demo of lsp-bridge on a big project but it was a general talk which I could learn from the project readme. Anyway after I watched it yesterday, I decided to try lsp-bridge with my Spacemacs on a go project. Yes, lsp-bridge is blazing fast. Completion suggestions were flying in as I typed and from all kind of sources: lsp, yas and even text in buffer. It feels as fast and responsive as IntelliJ and VSCode. However the scope of features of lsp-bridge is intentionally small. Some features like symbol highlight and breadcrumb will not be implemented, I assumed tree-sitter would take over them instead. For now I'm still staying with lsp-mode, it is a bit slower but I get all of lsp features. But great work from lsp-bridge team, they really show me how super fast lsp on Emacs can be. Btw I don't care much about the argument that lsp-bridge deviates too far from the core such as ignoring capf. This kind of thinking won't take us anywhere. It took helm, ivy then the recently defunct selectrum for the community to come to a collection vertico, consult, orderless and marginalia which when combined together give you what helm and ivy provides.

With all due respect, I think otherwise. If this has objective benefits, people will adapt. If it has none, then it will fall into obscurity. These approaches must be given a fair shot, a priori it’s impossible to tell which one is better. I for one, found helm’s tight integration very useful.

>That it accepts server responses via a process filter bound to emacs's single thread defeats whatever parallelism it purports. Why would it?

[deleted]