Lsp-Bridge, Not Even Wrong

People will wonder, why browbeat a youngster? I guess I'm still sore he scuttled my book review of Three Body Problem for being off-topic. I also wanted to commandeer emacs-china.org as my personal advertising platform, but he beat me to it. So the forum is rife with EAF this and EAF that.

In typical lsp, the message sequencing be like Figure 1:

normal.png

Figure 1: Typical

Lsp-bridge offloads steps 2 and 4 in Figure 1 to a third-party python process.

abnormal.png

Figure 2: Atypical

1. Why lsp-bridge isn't faster

  • Steps 2 and 4 in Figure 1 are async and take no time. They merely serialize and transmit request strings.
  • Emacs processing of Pyright's responses remains single-threaded.
  • Most lsp servers like Pyright are single-threaded.

2. Why lsp-bridge is obviously wrong

  • Introduces additional process.
  • Introduces python dependency.
  • Introduces rpc translation layer (epc.el).

3. Why lsp-bridge is egregiously wrong

Completion requests are now hard-wired (in python, no less) to occur in lockstep with keystroke notifications in steps 1b and 2b of Figure 2. This is obviously bad if the lsp server does not support completions, which I grant is unlikely, but more alarmingly, you must type into the buffer to get completions. You cannot C-M-i on a pre-existing word "wt" and expect to get "wth" and "wtf".

There is a saying in American politics. If you're explaining, you're losing. My guy wrote a treatise why he spurned emacs's traditional completion-at-point behaviors.