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 21:54:38 +0200 Message-ID: <83y2unf14x.fsf@gnu.org> References: <83blrkj1o1.fsf@gnu.org> <86zhf4gwhl.fsf@stephe-leake.org> <83tv5cgvar.fsf@gnu.org> <86v9psgkqe.fsf@stephe-leake.org> <83mub3hao7.fsf@gnu.org> <86r20fgh01.fsf@stephe-leake.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="61800"; 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 20:54:46 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 1inpVW-000Fzc-9R for ged-emacs-devel@m.gmane.org; Sat, 04 Jan 2020 20:54:46 +0100 Original-Received: from localhost ([::1]:36424 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inpVV-0006m3-3G for ged-emacs-devel@m.gmane.org; Sat, 04 Jan 2020 14:54:45 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41735) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inpVP-0006lw-5z for emacs-devel@gnu.org; Sat, 04 Jan 2020 14:54:40 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1inpVO-0006mt-GZ; Sat, 04 Jan 2020 14:54:38 -0500 Original-Received: from [176.228.60.248] (port=2856 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1inpVN-0002Ce-Rc; Sat, 04 Jan 2020 14:54:38 -0500 In-reply-to: <86r20fgh01.fsf@stephe-leake.org> (message from Stephen Leake on Sat, 04 Jan 2020 11:26:38 -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:243935 Archived-At: > From: Stephen Leake > Date: Sat, 04 Jan 2020 11:26:38 -0800 > > My attempt at a summary, in the form of a description of how LSP is used > in a typical editing session: Thanks. > > 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. > > Ok. I did not follow that in detail. Do we have any speed comparisons > with other editors? I didn't see any. > > 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? > > No; lexing the actual text is not where the time is spent. the way we currently communicate with servers is to make a buffer substring and encode it, which in itself is an overhead. And then JSON adds to that. > ada-mode builds on the current font-lock infrastructure; the font-lock > timer triggers a parse on a range, and the parse actions set > font-lock-face text properties. Font-lock by default doesn't use any timers, so what you do in Ada mode is not exactly how Emacs fontifies buffers. Or at least it sounds like that. > I don't think you are objecting to LSP in principle, but do have a > problem with the speed penalty due to using JSON. Using JSON is one thing; talking to an external program is another. > Since other editors are succeeding with that, perhaps there is more > Emacs could do here. Other editors don't need to go through Lisp, so they can do more stuff faster, and also off-load some of the work to threads. We need to find our own ways of being efficient, which might be different from what other editors do. It's like with the bidi support: I needed to write an entirely different implementation of the UBA to make it fit into the Emacs display engine's design. No other implementation of the UBA I know of works like our bidi.c and presents interfaces like it does.