[[!meta title="lsp-bridge: a smooth-as-butter asynchronous LSP client"]] [[!meta copyright="Copyright © 2022 Andy Stewart"]] [[!inline pages="internal(2022/info/lspbridge-nav)" raw="yes"]] # lsp-bridge: a smooth-as-butter asynchronous LSP client Andy Stewart and Matthew Zeng (IRC: Andy: manateelazycat) [[!inline pages="internal(2022/info/lspbridge-before)" raw="yes"]] Emacs built-in single-threaded mechanism and GC design will cause Emacs to freeze when receiving oversized LSP data. Lsp-bridge uses python's threading technology to build caches that bridge Emacs and LSP server. Lsp-bridge will provide a smooth completion experience without compromise to slow down emacs' performance. lsp-bridge is completely asynchronous, to the point that even the completion popup is controlled by lsp-bridge. It offloads all the computation to an external python process, and hence the emacs session itself stays always responsive, as it has very few things to do. lsp-bridge has now supported 39 LSP servers and all kinds completion backend: include LSP、 TabNine、 Citre、 Elisp、 Search Words、 Path、 Yasnippet、 Tempel、 Telegra、 English etc, it just works pretty well out of the box. Related design, please check and (sorry, I'm Chinese Emacser) [[!sidebar content=""]] # Discussion ## Notes - ## Questions and answers - Q: Is the fatal mistake of this approach that you can't M-x find-function into the code? - A: It is an unfortunate tradeoff. But what is the "fatal" part? - Q:Will lsp-bridge replace eglot/lsp-mode, or could it work with them? - A: Yes, lsp-bridge will replace lsp-mode/eglot and company/corfu. - Q:Is it possible to use lsp-mode and lsp-bridge together (Disabling completions of lsp-mode)? - A: lsp-bridge is plugin to replace lsp-mode and eglot, can't work with lsp-mode. - Q:Is there a demo of lsp-bridge showing its performance? - A:Hard to do that in 20 minute presentation about the principles. Best to try it to see. - Q:Will this be a candidate for core Emacs? - A:Perhaps not, it uses a lot of Python and many Emacsers may not like that instead of pure elisp. - Q:If performance is the main objective, why Python and not something like, e.g. Rust? - A:Python is easy to develop in, and LSP's performance is IO-based. The key is multi-threading, not language performance. - A: LSP is IO intensive not CPU intensive, Python isn't doing too good with latter but former is pretty fine. Anyways, as I've explained in the talk, the multithreading design fundamentally fixed the problem, it doesn't need any faster language. Existing python ecosystem and python's ease of development were also part of consideration - Q: Is there a benchmark comparison with lsp-mode and eglot? - A: It is a nuisance to create a benchmark comparison when lsp-bridge and lsp-mode/eglot are structured so fundamentally different (single-thread & multi-thread). Feel free to try lsp-bridge on a huge repository with a slow server (i.e volar, java), you will experience the difference immediately - Q:You tried lsp-mode , but have you tried Eglot re:performance? I heard lsp-mode isn't that efficient. - A:lsp-bridge is much much faster than eglot and lsp-mode - A: lsp-mode and eglot both suffer from bottlenecks from the single-threaded Emacs and the uncontrollability of the codebase size & lsp-servers, I've also heard eglot is better in terms of performance than lsp-mode, but lsp-bridge avoided this problem fundamentally - Q:How well does lsp-bridge coexist with clojure-lsp and cider? - A: clojure-lsp is part of the supported language servers already., C# also supported by OmniSharp - Q:Can lsp-bridge work with all LSP backends or just Python at the moment? - A: All LSP backends. - A: - Q: Is there any plan to support dap-mode or something alike? - A: Yes, but this year I've already spent so much time on develop lsp-bridge/EAF/blink-search/deno-bridge/markmacro. We can use lsp-bridge's technology build faster dap-mode similar project. - Q: does lsp-bridge work over Tramp? - A: tramp is very slow, I will planinng write new plugin to replace tramp, then we will make lsp-bridge work on remote machine, and something like VSCode does,  idea - Q: Does acm mode work on terminal or it only works on GUI? - A: The main acm-mode bundled with lsp-bridge only works on GUI at the moment. There is a community maintained repo that enables acm-mode to work on terminal: - Q: acm-mode is fast, is it possible to use it outside of lsp-bridge as a standalone mode? - A: No, acm-mode fast is because lsp-bridge's multi-thread and asynchronous design, not because acm-mode itself - Q: What lsp features will not be considered in lsp-bridge? How about symbol highlight, breadcrumbs? - A:lsp-bridge's highest priority is performance, symbol highlight is not useful and it will slow down the render performance (symbol-overlay is better choose) - A: breadcrumbs is not LSP procotol, I just want we coding like hacker that live in Emacs, I don't want make Emacs like a VSCode clone. [[!inline pages="internal(2022/info/lspbridge-after)" raw="yes"]] [[!inline pages="internal(2022/info/lspbridge-nav)" raw="yes"]] [[!taglink CategoryCoding]]