diff options
| -rw-r--r-- | 2022/talks/lspbridge.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/2022/talks/lspbridge.md b/2022/talks/lspbridge.md index 0966a169..cc58a67e 100644 --- a/2022/talks/lspbridge.md +++ b/2022/talks/lspbridge.md @@ -1,4 +1,4 @@ -[[!meta title="lsp-bridge: complete asynchronous LSP client"]] +[[!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"]] @@ -6,14 +6,13 @@ <!-- You can manually edit this file to update the abstract, add links, etc. ---> -# lsp-bridge: complete asynchronous LSP client +# 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. -[[!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. @@ -23,6 +22,7 @@ lsp-bridge has now supported 39 LSP servers and all kinds completion backend: in 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=""]] [[!inline pages="internal(2022/info/lspbridge-after)" raw="yes"]] |