Revised and expanded Q and A

1 files changed, 16 insertions, 16 deletions

diff --git a/2022/talks/lspbridge.md b/2022/talks/lspbridge.md
index d3d728e6..afe3af88 100644
--- a/2022/talks/lspbridge.md
+++ b/2022/talks/lspbridge.md
@@ -31,9 +31,9 @@ Related design, please check <https://manateelazycat.github.io/emacs/2022/05/12/
 
 ## Questions and answers
 
--   Q: Is the fatal mistake of this approach that you can\'t M-x
+-   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\"
+    -   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?
@@ -41,7 +41,7 @@ Related design, please check <https://manateelazycat.github.io/emacs/2022/05/12/
         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
+    -   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
@@ -51,13 +51,13 @@ Related design, please check <https://manateelazycat.github.io/emacs/2022/05/12/
         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
+    -   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
+    -   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
+        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
@@ -66,25 +66,25 @@ Related design, please check <https://manateelazycat.github.io/emacs/2022/05/12/
         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.
+    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
+        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
+        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
+    -   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
+        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
@@ -98,15 +98,15 @@ Related design, please check <https://manateelazycat.github.io/emacs/2022/05/12/
         <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
+    -   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
+    -   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
+        hacker that live in Emacs, I don't want make Emacs like a
         VSCode clone.