From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Renaming eglot -- or at least add an alias? Date: Fri, 14 Oct 2022 09:25:00 +1100 Message-ID: <86ilknco4a.fsf@gmail.com> References: <8335c0p2fn.fsf@gnu.org> <83leproov6.fsf@gnu.org> <83fsfzonwn.fsf@gnu.org> <5a1e604c-4500-a476-da3d-259d9057a7f0@yandex.ru> <838rlromxu.fsf@gnu.org> <83h70dk3wf.fsf@gnu.org> <835ygqg1bh.fsf@gnu.org> <87ilkqbsp3.fsf@thornhill.no> <0ef04e1e-3f6c-31b6-4852-0c9c2c43b912@yandex.ru> <86h708ft1k.fsf@stephe-leake.org> <86bkqgdnz6.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17744"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.9.0; emacs 29.0.50 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 14 01:16:24 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oj7R9-0004RF-VR for ged-emacs-devel@m.gmane-mx.org; Fri, 14 Oct 2022 01:16:24 +0200 Original-Received: from localhost ([::1]:43356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oj7R8-00032t-TG for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Oct 2022 19:16:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oj7Pl-0001qe-J2 for emacs-devel@gnu.org; Thu, 13 Oct 2022 19:14:57 -0400 Original-Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]:42989) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oj7Pf-0001YC-UH for emacs-devel@gnu.org; Thu, 13 Oct 2022 19:14:57 -0400 Original-Received: by mail-pl1-x62f.google.com with SMTP id c24so3154297pls.9 for ; Thu, 13 Oct 2022 16:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:to:from:user-agent :references:from:to:cc:subject:date:message-id:reply-to; bh=0s34orwV1I7f5WJPWJcgqCwM6iFIIEf0VvTGjo+KZ8k=; b=bgwrMGqH2xjkdfFwkgG7VYNEWy0zGRGCyYgD0IXakrHeZJ8WZYUQ9A0VhJr/ROqK0H UpgEV2tPPIhW9tKlGT5rpYljH74JktgR40uPfN19JnzSMAZWxVLF6S5FHk0yLj7XUte3 jwumR11q2lSUhRGaIN1dNWBBYt1/kSLSH+yMu/GCLO8wtcN9U3hZ6YH65RlC+z7QmZvE fWzRc8sUavenBDDim60qDI060BFPbVkN/IUSPhUJuEVoKqGwqx3dwIzQze0AEXld+Hdu pXR6Q4zI6kc7XFKQm3kJ1WT+PrPedt/LPjxvvWJvtVogzImjuxohnisvvmi07JhRG0PH WEsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:to:from:user-agent :references:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0s34orwV1I7f5WJPWJcgqCwM6iFIIEf0VvTGjo+KZ8k=; b=hJwvuzl5rWv27iI0J8FBEBvLk2OSVoOOIpjt9jsngm4ulHymt4X9CqcTwWIIMiMpCk Cejw1yf3y0bMeqRCof8ojI6BU4rsaFP5L5SDKN+80Fwv3AgOhKUsnrCTukdcxrwMClrf Xz/oTCJO5HurkItWy7CamsYxcTM041iO0LFAE6U41DSH9BU+KoTWn541YKasTKamopNA vOx4uVMf+RRHXRs4VNyFI8btvWTIswEjAgo4WVBfDj3X07WGlIp1/BlbVRg7MinmBCnM wBlXEpQSr/75DQ6Ib2smkYMMljbq74jARANJZP5Sc9+SzwRssiIz8PWs8pXCehLsE5mr /L0Q== X-Gm-Message-State: ACrzQf2DuXZbUyxQ6jblmuZUqzGHkMv/CBWwTyH/usOK/Ro1c5zC6XsH pmxZFkYuADd/KdUq2p1JTrL8zR+Dxb4= X-Google-Smtp-Source: AMsMyM77ywqKhypLr46s2AShV2NWVsMKXttYhYa5AIxJ5Fw43rCu6cBns9k9/wvz82UluLCqDXuYLA== X-Received: by 2002:a17:902:d4c5:b0:183:6e51:503 with SMTP id o5-20020a170902d4c500b001836e510503mr2279173plg.84.1665702889571; Thu, 13 Oct 2022 16:14:49 -0700 (PDT) Original-Received: from dingbat (124-169-22-230.dyn.iinet.net.au. [124.169.22.230]) by smtp.gmail.com with ESMTPSA id oj5-20020a17090b4d8500b001f262f6f717sm3931363pjb.3.2022.10.13.16.14.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Oct 2022 16:14:48 -0700 (PDT) In-reply-to: <86bkqgdnz6.fsf@stephe-leake.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::62f; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x62f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:297701 Archived-At: Stephen Leake writes: > 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. > > 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. > >> 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. I think I agree. I've often seen the criticism that LSP based solutions are no good because of poor performance arising from the use of JSON as the communication format. As someone who has done his share of web development and is very familiar with the pros and cons of JSON and alternative formats which (I think) are far superior, I can udnerstand where this concern can come from. However, having used LSP based setups (lsp-mode and eglot) fro quite some time on some large projects with many files and some large source files and in a couple of different languages, I have to say I've not noticed performance issues at all. I have run into other issues, most of which have been resolved. I did find with eglot that it was important to ensure the packages it users were up-to-date (i.e. xref, flymake, eldoc etc). What I have observed is that unsurprisingly, results are very dependent on the language server you are using. For example, I switched the LSP server I was using for Javascript and immediately experienced a much better result. Actually, this was one of the nice aspects of using an LSP based work flow. Changeing LSP server was a simple as downloading the server executable and changing one variable in my client config. I have not used LSP for font locking, but have used it for indentation and it worked fine with no observable performance issues like typing lag etc. The other aspect of using LSP which I've found interesting, but really only as something to hack/playh with, has been setting up your own LSP server for a specific language. I experimented using Clojure and Raku and was surprised how quickly/easily you could add functionality to my editor, primarily as I was able to leverage of built-in functionality of the languages I was working with. I think this ability to leverage of the target languages built-in features combined with a smaller code base and reduced maintenance within the editor core is what gives the LSP architecture an edge over solutions like tree-sitter. The fact it can be used with multiple different editors is the sugar on top. However, if the effort has been done to add tree-sitter support for a language and it is maintained, then it will likely to perform better in many cases and could well be the preferred choice for many users.