summaryrefslogtreecommitdiffstats
path: root/2022/talks/lspbridge.md
blob: 0966a169555f7082affd3791771629bb1d70a163 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
[[!meta title="lsp-bridge: complete 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: complete 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.

[[!sidebar content=""]]
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)



[[!inline pages="internal(2022/info/lspbridge-after)" raw="yes"]]

[[!inline pages="internal(2022/info/lspbridge-nav)" raw="yes"]]

[[!taglink CategoryCoding]]