emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using incremental parsing in Emacs


From: arthur miller
Subject: Re: Using incremental parsing in Emacs
Date: Sat, 4 Jan 2020 14:05:30 +0000

Eli Zaretskii <address@hidden> writes:

>> From: Stephen Leake <address@hidden>
>> 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.

Personally I dislike the idea that they used json at all, but lots of
tools work now with that json.

Maybe the slowness comes from the overhead to communicate that json?
Could it help if Emacs provided a way to put those json files into
a shared memory so that both server and client can use same file
without sending it over between processes and having two copies of
both source and analysis in RAM. Maybe server could use Emacs buffer
directly instead of sending source file to external process. But
yes generally I also think that json is horrible format as
interchange format but I can understand why MS choosed it for their
tool.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]