From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Elisp LSP Server Date: Fri, 15 Oct 2021 09:35:00 +0300 Message-ID: <83o87qkd7v.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35287"; 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: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 15 08:36:42 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 1mbGpe-0008xT-LX for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Oct 2021 08:36:42 +0200 Original-Received: from localhost ([::1]:44420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbGpd-0006wX-0g for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Oct 2021 02:36:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59884) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbGok-0006Fj-JX for emacs-devel@gnu.org; Fri, 15 Oct 2021 02:35:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49564) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbGoj-0005mS-Pb; Fri, 15 Oct 2021 02:35:45 -0400 Original-Received: from [87.69.77.57] (port=4812 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbGo2-0003EA-3N; Fri, 15 Oct 2021 02:35:02 -0400 In-Reply-To: (message from Richard Stallman on Thu, 14 Oct 2021 18:26:01 -0400) 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:277088 Archived-At: > From: Richard Stallman > Cc: luangruo@yahoo.com, agzam.ibragimov@gmail.com, philipk@posteo.net, > psainty@orcon.net.nz, emacs-devel@gnu.org, > joaotavora@gmail.com, mardani29@yahoo.es > Date: Thu, 14 Oct 2021 18:26:01 -0400 > > 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). That interface will be first and foremost useful for Emacs, because that's the main/only editor people use to edit Emacs Lisp programs. It's true that other editors will be able to use that, but the chances of someone using VSCode to edit Emacs Lisp are slim at best. > 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. This assumption/conclusion misses an important point, see below. > 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? Doing that in the same process will make Emacs slower, because Emacs is fundamentally single-threaded. On modern systems that routinely have 8 or 16 execution units, off-loading some of the processing to asynchronous code that exploits additional execution units is a significant advantage, and allows us to be much more scalable. If Emacs had true concurrency, we could do that in the same process by arranging for additional threads. But since that is not available, running a language processor in a separate process is the next best. And since a protocol for that already exists, reusing the protocol in this case sounds like an idea worth exploring. Of course, if it turns out the LSP protocol doesn't help much, we could always implement our own protocol (which would then solve the fear of VSCode using that, although I think that's us being haunted by the shadow of a dwarf).