From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: arthur miller Newsgroups: gmane.emacs.devel Subject: RE: Using incremental parsing in Emacs Date: Fri, 3 Jan 2020 22:21:16 +0000 Message-ID: References: <83blrkj1o1.fsf@gnu.org> <86zhf4gwhl.fsf@stephe-leake.org>,<83tv5cgvar.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_VI1P194MB0429581A1642341DD121F32296230VI1P194MB0429EURP_" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="137568"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "emacs-devel@gnu.org" To: Eli Zaretskii , Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 03 23:30:33 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 1inVSi-000Zeh-SB for ged-emacs-devel@m.gmane.org; Fri, 03 Jan 2020 23:30:33 +0100 Original-Received: from localhost ([::1]:57462 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inVSh-0004Kt-O6 for ged-emacs-devel@m.gmane.org; Fri, 03 Jan 2020 17:30:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42434) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inVJs-0001TD-Rs for emacs-devel@gnu.org; Fri, 03 Jan 2020 17:21:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1inVJq-0005g0-MF for emacs-devel@gnu.org; Fri, 03 Jan 2020 17:21:24 -0500 Original-Received: from mail-oln040092068070.outbound.protection.outlook.com ([40.92.68.70]:12263 helo=EUR02-HE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1inVJn-0005ON-75; Fri, 03 Jan 2020 17:21:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fLz+g9azwSD5+H1nOQss/a147KUTZSc6il1LSCAsO0dYXH2YJ/t12QQZFjRfNYN23TzGhX9S+er3kuDPFWKvwOuoPqNjX1HVGbVjQbkS+5VtCAQJQ7m0gJJdwV2eUXSnZdzl2/pjSAnNMmj6QSjhldCSQ7T0PxEeckjTmz0s/TgxPCIRtFc8ugACovV4Sda/7Vmj4ChLa+vGNQg81J8RPuohP+SFflV+Gt0m/PNpQ+Ln/b+phaLPIoMMBFJA3uT5t4IwxgXMszIlzIgP5xxPQY3LKFsAm38zQegCd6wEPPdNcL3x39Z604VKm4gTgAVV3uldIKpfxNoIkAe2Y8gRXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ImHAKt2JLCAshUjr/WInYGelMnhrkGmhfE1vj0S2aA=; b=G3t7rIXlqbXFH5yzyAH+CYqd/QZyGLJMQLOy5kZqWBCYqoRVcVKl5vD+rIdKRT7IH6o2wMtoIARD/RlI4iudILsTtmAoKqht4nzlnsBl58Anly+8CxIxIw0AhR/Zlm4MqwImysZ9UNkeWRIU5rt0ROYLoFS+D4RdvR3KMdXg+u0XQRcDpQFqOxDYkjhcY8HpxvP+1x0RLcdSx832cHU3ywkKD7k386j4GtvKeJ9Xo1DkPitJ9/nxbvsIICie299sMEuH5VKno2YnicIECkNuBjNDJuYd/UTOhNJIOn97lAdkS4poFTAhFEabWf/kWPinCbwFGrC5uo45ZCaosqIuxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ImHAKt2JLCAshUjr/WInYGelMnhrkGmhfE1vj0S2aA=; b=uSOQsIW6+QDyP1OZ6P/M2niCb1uTQQHtuGIOkIRSwyaGMKCJ9b8oztwjbGc1XGp96ln09rfTpSRDs5KsBGsN6BLnrgTbdKPU5MOKjd8itLD8Ji67Di+Uw/ANNmJ0tEiJGUgBZllNLgUh0+wvemNd8oVVlTFFfzbXBlhX1eglThISqa54Ippo691KXbi8lJNaQtHNAiogTLTLvqvQ6qM11yqmLuzZCATohx+F/alBQ+jUAO0yb+s8b6hauII2JfQwFiFjfeh4KZOHlwTVr2jYkPEvDtAVhMw/GnJlthBySgrvXEXdMBSUL1rVr2AFT9aRVijUe+0B627RnH4CVn/65g== Original-Received: from VE1EUR02FT025.eop-EUR02.prod.protection.outlook.com (10.152.12.55) by VE1EUR02HT143.eop-EUR02.prod.protection.outlook.com (10.152.13.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11; Fri, 3 Jan 2020 22:21:16 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM (10.152.12.54) by VE1EUR02FT025.mail.protection.outlook.com (10.152.12.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Fri, 3 Jan 2020 22:21:16 +0000 Original-Received: from VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::35f2:9ea2:efd6:1d46]) by VI1P194MB0429.EURP194.PROD.OUTLOOK.COM ([fe80::35f2:9ea2:efd6:1d46%5]) with mapi id 15.20.2602.015; Fri, 3 Jan 2020 22:21:16 +0000 Thread-Topic: Using incremental parsing in Emacs Thread-Index: AQHVwh1Uy8tVxqoXLEaWXDDoUSKGMKfZVx2ygAAHRHuAACWe+g== In-Reply-To: <83tv5cgvar.fsf@gnu.org> Accept-Language: sv-SE, en-US Content-Language: sv-SE x-incomingtopheadermarker: OriginalChecksum:60E120C0C283336EA483041F291DD39D1805E8B0216D75F68E51116A91F472EA; UpperCasedChecksum:C0F169704BC59FD7FA27629A410328833D67FEED57FBF1D912FF53830101FF5F; SizeAsReceived:6957; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [xNJ5emNgNsBoF+8LJmq+aByJN7zqkq0N] x-ms-publictraffictype: Email x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 5bce6662-f595-459b-dbb9-08d7909b3fdc x-ms-traffictypediagnostic: VE1EUR02HT143: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pdaNfEWbpXJRROsRNCABKwkGcE0ZFH/ux75Un1NGohl8qDu07jEsBbVlU2q4n79GBQjPr6ri5E49LiRroho6EJH/LGy5jhuURWQVxMyi5VkNTebzcKWLUH952oBP7+W/2ECVQt3XrsT1No1LoDo7PhhI6zEuVyGPC/kdSv1N9jn4SAPl/cBruVqoS19wdcYu x-ms-exchange-transport-forked: True X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 5bce6662-f595-459b-dbb9-08d7909b3fdc X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2020 22:21:16.0224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT143 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-Received-From: 40.92.68.70 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:243900 Archived-At: --_000_VI1P194MB0429581A1642341DD121F32296230VI1P194MB0429EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When it comes to tree-sitter which you linked to, I didn't understand from = their website how they deal with compile time dependencies and various conf= iguration options that are usually passed via configure & co. Various lsp implementations like ycmd and lsp-mode can use "compile databas= e" produced by tools like bear, compiledb and similar. As I see on teee-sit= ter they only speak about language grammars. I have though only read their = website tonight after you posted your mail. Can they understand library dependencies, compile flags and so on? Another thing is, about "speed-wise", if Enacs core implemented support for= creating language servers, or plugging in them, as well as clients, then m= aybe it would be possible to use share memory for passing round those big j= son files that lsp-mode like to play with. That might also let Emacs reuse = existing tools like lsp-mode. I think they are using sockets now, I am not = sure though. Skickat fr=E5n min Samsung Galaxy-smartphone. -------- Originalmeddelande -------- Fr=E5n: Eli Zaretskii Datum: 2020-01-03 21:06 (GMT+01:00) Till: Stephen Leake Kopia: emacs-devel@gnu.org =C4mne: Re: Using incremental parsing in Emacs > From: Stephen Leake > Date: Fri, 03 Jan 2020 11:39:50 -0800 > > Whether the language server is implemented as an external process, or as > a loadable module, is an implementation detail. That detail can be very important, though. E.g., direct access to buffer text is not possible from external programs, and likely will not be possible, at least not conveniently so, from modules. So I still think we should first consider how the interfaces supporting the various features should look, and only after that look around for packages that perhaps are already doing that. In general, with all due respect, I don't expect the existing packages to teach us TRT, because they are doing stuff in Lisp alone, and that is inherently limited and likely sub-optimal. But that's just MO; I started this thread to maybe inspire someone to have a second look on the related features and propose ways of improving what we do today, both feature-wise and speed-wise, as I see quite a few complaints about lack of features and slowness in stuff like font-lock. If people are happy with what we have, it's fine with me, even if I disagree with the approaches I see out there. --_000_VI1P194MB0429581A1642341DD121F32296230VI1P194MB0429EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When it comes to tree-sitter which you linked to, I didn'= t understand from their website how they deal with compile time dependencie= s and various configuration options that are usually passed via configure &= amp; co.

Various lsp implementations like ycmd and lsp-mode can us= e "compile database" produced by tools like bear, compiledb and s= imilar. As I see on teee-sitter they only speak about language grammars. I = have though only read their website tonight after you posted your mail.

Can they understand library dependencies, compile flags a= nd so on?

Another thing is, about "speed-wise", if Enacs = core implemented support for creating language servers, or plugging in them= , as well as clients, then maybe it would be possible to use share memory f= or passing round those big json files that lsp-mode like to play with. That might also let Emacs reuse existing tools like lsp= -mode. I think they are using sockets now, I am not sure though.

Skickat fr=E5n min= Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Fr=E5n: Eli Zaretskii <eliz@gnu.org>
Datum: 2020-01-03 21:06 (GMT+01:00)
Till: Stephen Leake <stephen_leake@stephe-leake.org>
Kopia: emacs-devel@gnu.org
=C4mne: Re: Using incremental parsing in Emacs

> From: Stephen Leake <stephen_leake@stephe-= leake.org>
> Date: Fri, 03 Jan 2020 11:39:50 -0800
>
> Whether the language server is implemented as an external process, or = as
> a loadable module, is an implementation detail.

That detail can be very important, though.  E.g., direct access to
buffer text is not possible from external programs, and likely will
not be possible, at least not conveniently so, from modules.

So I still think we should first consider how the interfaces
supporting the various features should look, and only after that look
around for packages that perhaps are already doing that.  In general,<= br> with all due respect, I don't expect the existing packages to teach us
TRT, because they are doing stuff in Lisp alone, and that is
inherently limited and likely sub-optimal.

But that's just MO; I started this thread to maybe inspire someone to
have a second look on the related features and propose ways of
improving what we do today, both feature-wise and speed-wise, as I see
quite a few complaints about lack of features and slowness in stuff
like font-lock.  If people are happy with what we have, it's fine with=
me, even if I disagree with the approaches I see out there.

 --_000_VI1P194MB0429581A1642341DD121F32296230VI1P194MB0429EURP_--