add etherpads to wiki pages

1 files changed, 86 insertions, 0 deletions

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 <https://manateelazycat.github.io/emacs/2022/05/12/
 
 
 [[!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"]]