From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Elisp LSP Server Date: Thu, 14 Oct 2021 18:26:01 -0400 Message-ID: References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <87ee99dv34.fsf@gmail.com> <07cf50ddddb5a9556aa94201a7ac88c9@webmail.orcon.net.nz> <87r1d0562u.fsf@yahoo.com> <87r1cz7qcd.fsf@posteo.net> <87bl4367av.fsf@yahoo.com> <87fstf7kz4.fsf@posteo.net> <87o8814q1v.fsf@yahoo.com> <87r1cs9faa.fsf@yahoo.com> <87a6jdqz4k.fsf@yahoo.com> <83wnmhnlp6.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6140"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, psainty@orcon.net.nz, emacs-devel@gnu.org, luangruo@yahoo.com, joaotavora@gmail.com, mardani29@yahoo.es, agzam.ibragimov@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 15 00:29:04 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 1mb9Di-0001N0-AW for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Oct 2021 00:29:02 +0200 Original-Received: from localhost ([::1]:56966 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mb9Dg-00083W-Hr for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Oct 2021 18:29:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52946) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mb9Aq-0004TT-RI for emacs-devel@gnu.org; Thu, 14 Oct 2021 18:26:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37096) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mb9Aq-0001Na-Gw; Thu, 14 Oct 2021 18:26:04 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1mb9An-0007Se-AJ; Thu, 14 Oct 2021 18:26:01 -0400 In-Reply-To: <83wnmhnlp6.fsf@gnu.org> (message from Eli Zaretskii on Wed, 13 Oct 2021 15:39:01 +0300) 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:277079 Archived-At: [[[ 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. ]]] > This makes very little sense to me: we are supposed to refrain from > developing an Emacs-specific feature whose primary audience is Emacs > itself, I think that is a misunderstanding of what the issue is. I think we all agree that we want to develop code within Emacs to analyze Emacs Lisp code in whatever ways are useful. Those results will be available in Emacs for whatever use we want to make of them. The question at issue -- unless I have misunderstood -- is NOT about doing that. Because someone might find a way of using it with proprietary > software? The proposal at issue -- unless I have misunderstood -- is to develop a server interface for Emacs specifically to make those analysis results available to other editors (which may mean, principally VScode). Please correct me if I have misunderstood the facts of the proposal and its presuppositions. If I understood right, this can't be of any benefit to editing with Emacs. Because all the analysis results we can produce will be available anyway for editing in Emacs. Editing Emacs Lisp code with Emacs will not be improved by this. The only benefit of this additional work will be to help people edit it with VScode. That's why I think this would be an own goal. Would it be possible to make Emacs launch a child Emacs and use it as a language server to get the results of these analyses? I suppose so. Just as it is possible to launch Emacs inside M-x term and edit in that child Emacs. Is there is any practical advantage to starting a child Emacs to do this analysis in? I don't see it. Why not do it in the initial Emacs process? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)