RE: Using incremental parsing in Emacs

[arthur miller <arthur.miller@live.com>]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

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 configuration options that are usually passed via configure & co.

Various lsp implementations like ycmd and lsp-mode can use "compile database" produced by tools like bear, compiledb and similar. 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 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 maybe it would be possible to use share memory for 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ån min Samsung Galaxy-smartphone.



-------- Originalmeddelande --------
Från: 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
Ämne: 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,
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.


[-- Attachment #2: Type: text/html, Size: 3547 bytes --]