Theodor Thornhill writes: > On 13 October 2022 12:20:13 CEST, Stephen Leake wrote: >>Theodor Thornhill writes: >> >>> On 13 October 2022 02:47:51 CEST, Stephen Leake wrote: >>>>Richard Stallman writes: >>>> >>>>> [[[ To any NSA and FBI agents reading my email: please consider ]]] >>>>> [[[ whether defending the US Constitution against all enemies, ]]] >>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]] >>>>> >>>>> > > Because all of the interaction between server and client in lsp is json >>>>> > > there's a huge overhead with parsing and shipping things into the emacs >>>>> > > user interface. So IMO what tree-sitter is good at should be left to >>>>> > > tree-sitter. >>>> >>>>Premature optimization. >>>> >>> >>> Why do you say that? >> >>Because it gives a supposed cause without evidence of an actual problem. >> >>> I've been using lsp for a long time, and typing lag can get unbearable >>> with servers that sends too much stuff. When 20k completions >>> containing _full_ documentation for every result that json gets >>> humongous. >> >>Ok, that's actual data. On the other hand, did you measure different >>parts of the process, so you are sure that the json is the bottleneck, >>and not something else? It's not clear just from this description that a >>tree-sitter implementation would be faster. >> > > Yes I did,at the time. Though I cannot find the issue at hand, but it was related to Elm-language-server if memory serves me right. > > >>In addition, LSP supports sending the documentation later, after the user >>has actually looked at a completion item, using a completionItem/resolve >>request. So this sounds like a specific client or server implementation >>problem more than an inherent LSP problem. >> > > Sure, but that's life. Nonconforming servers are everywhere, and these > issues are bound to happen. If something as important and simple as > colors and indentation would be unusable because of a bug in a > transitive dependency we have a much bigger problem, imo. Tree-sitter > will not cause us these headaches as easily. > > >>> Adding syntax highlights on top of that isn't advisable, considering >>> emacs nonmultithreaded nature. >> >>Syntax highlighting, mediated by font-lock, should only ever send small >>amounts of data; one screen full at a time. That is if the server >>supports the textDocument/semanticTokens/range request, and not just the >>textDocument/semanticTokens/full request. >> > > Yes, and yet again we are at the mercy of the specific server. Using > tree-sitter we can much more reliably resolve the situation on our > own. Of course, in both cases the tech is new and will mature, but to > me tree-sitter seems like the obvious winner. > LSP is too flexible to block the editor. -- Akib Azmain Turja Find me on Mastodon at @akib@hostux.social. This message is signed by me with my GnuPG key. Its fingerprint is: 7001 8CE5 819F 17A3 BBA6 66AF E74F 0EFA 922A E7F5