From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Using incremental parsing in Emacs Date: Sat, 04 Jan 2020 10:45:44 +0200 Message-ID: <83mub3hao7.fsf@gnu.org> References: <83blrkj1o1.fsf@gnu.org> <86zhf4gwhl.fsf@stephe-leake.org> <83tv5cgvar.fsf@gnu.org> <86v9psgkqe.fsf@stephe-leake.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="221871"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 04 09:46:40 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1inf4y-000vbM-KU for ged-emacs-devel@m.gmane.org; Sat, 04 Jan 2020 09:46:40 +0100 Original-Received: from localhost ([::1]:60664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inf4x-0000kt-Ij for ged-emacs-devel@m.gmane.org; Sat, 04 Jan 2020 03:46:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48992) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inf45-0008H6-0e for emacs-devel@gnu.org; Sat, 04 Jan 2020 03:45:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1inf43-0003qP-V9; Sat, 04 Jan 2020 03:45:44 -0500 Original-Received: from [176.228.60.248] (port=1595 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1inf43-0004BN-6b; Sat, 04 Jan 2020 03:45:43 -0500 In-reply-to: <86v9psgkqe.fsf@stephe-leake.org> (message from Stephen Leake on Fri, 03 Jan 2020 15:53:45 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243910 Archived-At: > From: Stephen Leake > Date: Fri, 03 Jan 2020 15:53:45 -0800 > > The interface should look like LSP; it aims to support everything an IDE > needs from a "language server" (ie parser), and allows for custom > extensions where it falls short. Maybe I'm the odd one out, but I don't think I have a clear idea of what the "LSP interface" entails. Would you (or someone else) post a summary, or point to some place where this is described succinctly enough to not require a long study? We did learn one important thing from using LSP servers: that processing the JSON stuff back and forth adds non-trivial overhead and slows down the application enough to annoy users, even after we did all we can to speed up the translation. So I think it makes sense to take one more look at the issue and see if we can come up with better interfaces, which will suit Emacs applications better and allow faster processing. Using a library that processes stuff locally would then allow us to implement such interfaces more easily, since we will be free from the restrictions imposed by the need to communicate with external processes. we'll most probably want some combination of LSP-based and local parsers-based features. E.g., it's quite possible that LSP servers could be better for some complex jobs, where speed matters less. My point is that we shouldn't lock up our minds, not yet anyway. A fresh look at these issues, taking the incremental parsing into account, could benefit us in the long run. > LSP language servers are implemented in some compiled language, not > elisp; eglot/lsp-mode is just the elisp side of the protocol. The elisp > sends edits and info requests (ie, "insert/delete this text at this > point", "fontify/format this range") to the server, and handles the > responses. I'm saying we should look into this and see whether there are better ways that that. Suppose such a server had direct access to buffer text: would that allow a more efficient interface than the above? We shouldn't be "dragged" after the LSP ideas just because they are there, and we shouldn't automatically decide that an interface is OK just because it can be done in Lisp with no changes on the C level. Emacs has some unique features and requirements that might affect the design of the interfaces to such servers and libraries. We've been there several times with minor features like line numbers and fill-column indicator. Why would this issue be an exception? Especially since we have lately quite a "schism" among our active developers: those who have the most experience in implementing such applications aren't familiar well enough with the C internals, and avoid making changes there. This could very well be an obstacle to coming up with good ideas regarding the best interfaces and implementation options for the related features. > ada-mode works in a similar way, but LSP is an industry standard, so it > is a better choice. > > If Emacs has a mode that conforms to the editor side of the LSP > protocol, it can use _any_ LSP language server; they do not have to be > provided by Emacs. We should definitely support LSP. We already do, albeit in third-party packages. We added native JSON support and jsonrpc for doing this better. If there's anything else we can do in that direction, people should speak up. But my point is that LSP is not necessarily the only game in town we should support. For example, font-lock doesn't use LSP, and probably never will, due to performance issues; should we improve font-lock using infrastructure that's based on language parsing? And there are other features that could benefit, I've mentioned them. If you are saying they all should just use LSP, then I don't think I agree.