From c6c2d25cb561946e993e5dc5919afed8017cd087 Mon Sep 17 00:00:00 2001 From: Sacha Chua Date: Thu, 8 Dec 2022 20:18:23 -0500 Subject: add etherpads to wiki pages --- 2022/talks/lspbridge.md | 86 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) (limited to '2022/talks/lspbridge.md') diff --git a/2022/talks/lspbridge.md b/2022/talks/lspbridge.md index cc58a67e..d3d728e6 100644 --- a/2022/talks/lspbridge.md +++ b/2022/talks/lspbridge.md @@ -23,6 +23,92 @@ Related design, please check + +## 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"]] -- cgit v1.2.3