News for hackers. Stuff that matters.
Re:A vision of a multi-threaded Emacs by alex_smart on Monday May 30, 2022 @02:24PM (#31561969)
If your lsp-client code is doing anything where you need binding with a native library or the speed of emacs lisp is a factor, you are doing it wrong. All an lsp-client needs to do is make requests to the lsp-server, listen to the responses and update the UI. It literally doesn't matter how slow emacs-lisp is.

The only way an lsp-client could be slow is by making a request to the server and then blocking on the response - which is wrong and the package writer's fault because they are not using the asynchronous api emacs provides for communicating with a process.

Re:A vision of a multi-threaded Emacs by gcommer on Monday May 30, 2022 @05:09PM (#31563651)
There's tons of little details and inefficiencies in elisp that crop up such that easy things like "listen to responses" are hard to get fast. Random example: before native json support, large lsp responses (which can be multiple megabytes from some servers!) would take over a second and hitch the UI just to parse the json response. And that was after a lot of work to get response parsing dominated by json instead of GC time.