summaryrefslogblamecommitdiffstats
path: root/2022/talks/lspbridge.md
blob: 40b444f660579c4c2fc42548b3b6f5c138474d6d (plain) (tree)
1
2
3
4
5
6
7
8
9
                                                                        






                                                                                                     
                                                        
                                                         













                                                                                                                                                                                                                                                                           
                       







                                                  
                                                               
                                
                                                                 






                                                                       
                                                                    








                                                                        
                                                                
                                                                       
                                                                    
                                                                   


                                                                   







                                                                      
                                        


                                                                       
                                                                       



                                                                      
                                                





                                                                                 
                                                                
                                                                     
                                                                     












                                                                        
                                                                     


                                                                        
                                                              


                                                                      
                                                                 

                     




                                                                 
[[!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"]]

<!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
<!-- You can manually edit this file to update the abstract, add links, etc. --->


# 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 <https://manateelazycat.github.io/emacs/2022/05/12/lsp-bridge.html> and <https://manateelazycat.github.io/emacs/2022/06/26/why-lsp-bridge-not-use-capf.html> (sorry, I'm Chinese Emacser)


[[!sidebar content=""]]
# Discussion

## Notes

-   <https://github.com/manateelazycat/lsp-bridge>

## 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:
        <https://github.com/manateelazycat/lsp-bridge#supported-language-servers>
-   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
        <https://github.com/manateelazycat/lsp-bridge/issues/357>
-   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:
        <https://github.com/twlz0ne/acm-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]]