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: Elisp LSP Server Date: Wed, 13 Oct 2021 11:31:59 +1100 Message-ID: <87fst5ae2t.fsf@gmail.com> References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <87ee99dv34.fsf@gmail.com> <07cf50ddddb5a9556aa94201a7ac88c9@webmail.orcon.net.nz> <87fstf3god.fsf@fastmail.fm> <87ily2947q.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23745"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.0; emacs 28.0.60 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 13 03:51:13 2021 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 1maTQG-0005vN-RM for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Oct 2021 03:51:12 +0200 Original-Received: from localhost ([::1]:50460 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maTQE-0004ar-Jr for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Oct 2021 21:51:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1maTP0-0003mr-3L for emacs-devel@gnu.org; Tue, 12 Oct 2021 21:49:54 -0400 Original-Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]:45684) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1maTOy-0008Rc-7l for emacs-devel@gnu.org; Tue, 12 Oct 2021 21:49:53 -0400 Original-Received: by mail-pf1-x434.google.com with SMTP id i65so1027087pfe.12 for ; Tue, 12 Oct 2021 18:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version; bh=J+5rcBOobcfq4H7YrXfCDPCA9/00OVwFZ1vyMcFpOJE=; b=nbGBJ8xpHTpAh03cK1REFYpzNQbUzX0FL6o658YaM8p3/SP31iC33M7xxARK7wVVJE IHPKLlTCTa3cngBw9fNoDJFk5kn7SFKvsV7EnubPeu3vcg3uU5eVKw+tfs8RIr78jXeu gEFOAY7dkb8IQF0hft40njo0nzLbHTo2jo1hnoGpokhU5tQIY34cCQPMIQqA0W9vbCCq Zw4CeBTqf8ljpuXzWrWuoCTsFBAs/XOqig0oFA8LzjTq2OoJwuV8/R5qlzj1cB3gxpGh CC0jHyVY64VFv5y9Qz1hhiQ7trPUtVIsKTr+GVOEg2jxI8D982KWcTzNeaxQzZ/DdoPd wZlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version; bh=J+5rcBOobcfq4H7YrXfCDPCA9/00OVwFZ1vyMcFpOJE=; b=TQmXZH2o1dfKe3QKy9/kTMnHU6U/LF65S+HZsVYNKlEgrdaQv3TJSBHT/D0pumIgK8 4WPpKvZmIaXUg0hNNwQCMX44iSC/scjvxCH1VVx2uC+w0AlIlunzhmEzOLMjGJDloPqJ 21wq3hqmm/ih4YG5Xf+KHNAlbcw215ycBpeH/zO/kv25nyd67aEmMvXEiPhMHvMq42Qd QX6ImqA2OiiBED2xAj+meM7OL2x+NyxTvUtpcv5GDYGti22HWCHDiMhybObU/PfKe7ZZ UcOAJm0REAoEHmY5Fefdzvbv9IelPSsxVEMPyisbrWh3R3BW0XycQ3DjVnoCjbdNIs1g ulJg== X-Gm-Message-State: AOAM531umsC1Gs9YUAdapdN0D/RSkRHR+tgdpB0PWpd5X5lsLj7M0kBG 7C3WaRSvDV++eGF/khUZ52hx5hOFPkg= X-Google-Smtp-Source: ABdhPJzf+Qx11dtpTNFzbF8ZDRruQy/c1lGl/8YnyAfTot2MVAt24q78QJtC28iAXnOfO7vYrQUGKg== X-Received: by 2002:a63:3548:: with SMTP id c69mr22021021pga.111.1634089790046; Tue, 12 Oct 2021 18:49:50 -0700 (PDT) Original-Received: from tim-desktop ([124.149.107.7]) by smtp.gmail.com with ESMTPSA id d67sm12041795pfd.151.2021.10.12.18.49.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 18:49:49 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::434; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x434.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.23 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:276852 Archived-At: 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. ]]] > > > Aside from what Stefan mentioned, lsp-mode has another problem: it > > encourages users to, and even automatically downloads proprietary > > software from the internet. > > This suggests that lsp-mode is poison. Recommending it in Emacs might > put us in a morally contradictory position. > > Would you please explain more about this? Perhaps give some names to > the programs in the scenario, and say how they relate to each other? I think the LSP situation has been both misrepresented and misunderstood. There is nothing inherently evil about LSP. It is just a protocol. There is nothing in LSP which requires proprietary software or use of non-free services. There can be instances of LSP implementations which might do this, but that is about the implementation and not about support of the protocol. Ironically, the first place I ever heard about/discussed a LSP like solution was on this list many years ago during discussions about how to provide better and more consistent support for things like completion, syntax highlighting, linting etc. At that time, it was acknowledged that one reason many editors built for a specific language were able to provide more superior support in these areas was because they had a built-in parser for the language being used and that for Emacs to provide something similar would require it had the ability to parse each language being supported. This triggered efforts like the one to allow Emacs to leverage of Eclipse to provide enhanced language support for Java and to some extents, efforts like CEDET and Semantic. The basic idea behind LSP is an extension of this idea. In an ideal world, every programming language would also include an LSP language server. It would be maintained in parallel with the development of the language. Any editor which wanted to support that language would implement the client side of the LSP protocol and install the language provided LSP language server, avoiding the need for each editor to implement it's own version of a language parser in order to provide more 'intelligent' support for things like completion, API documentation, linting, etc. The fact MS has used LSP to provide enhanced features on github has nothing to do with LSP directly - Github integration is not a required part of the protocol and is not mentioned in the LSP sepcs. You are not required to use github because you use LSP. Likewise, your not required to use VSCode extensions, although some languages might distribute their LSP language server components via that service. Likewise, language servers for LSP may or may not be free and may or may not encourage use of non-free software - it needs to be evaluated based on each LSP language server. Even if a language server is distributed via github and to use it you have to download the server from github, this is not sufficient justification not to support LSP. We already have a number of packages in ELPA and nongnu ELPA where the main repository is on github. I am ambivalent about an LSP language server for ELISP. This is mainly because all the bits an LSP language server provides are already part of Emacs and partly because I don't see any real benefit or use case for ELISP outside of Emacs (I know there are some out there who would like to use Elisp for everything, but I feel that is an example of a 'hammer looking for a nail' type syndrome - just because Elisp can be used as a general purpose programming language doesn't mean it should be). I suspect that if you configured Emacs to use the same key bindings for Elisp support features, so that when developing Elisp code it 'felt' the same as when developing code for an LSP supported language, you would satisfy much of the requirements raised by the OP. Having said that, if someone wants to have a go at developing an LSP language server for Elisp, I would encourage them to do so. While I suspect they will soon find the amount of work required and the benefits it provides difficult to justify/maintain, it does no harm and it may result in other benefits and is a project which would likely provide a good platform for expanding/enhancing an individual's elisp knowledge at a deeper level. In summary, for the OP, - No, I don't think anyone has tried developing an LSP server for Elisp - Sure, if you want to do it, go for it - No idea what language to use or how to implement the server. It has been suggested elisp would be the obvious choice, but I don't see how you can implement elisp outside Emacs without pretty much implementing most of emacs. Other language servers have used Rust or Go to implement the language parser. I guess it will be whatever language you feel is best to implement an elisp parser outside of elisp.