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: Stephen Leake
Subject: Re: Using incremental parsing in Emacs
Date: Sun, 05 Jan 2020 09:05:07 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Stephen Leake <address@hidden>
>> Date: Sat, 04 Jan 2020 11:26:38 -0800
>>
>> > 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.

Right. The encode step is done when communicating with modules as well,
because the internal encoding is not exactly uff-8.

>> 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,

It does if you set jit-lock-defer-time, which I do (in my ~/.emacs, not in
ada-mode).

>> 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.

Ok.


I've configured eglot and ada_language_server (from AdaCore); it works,
but doesn't do everything ada-mode needs (yet; AdaCore labels this a
work in progress).

In particular, LSP does not currently support semantic highlighting (ie
font-lock). There is a proposal to add that
(https://github.com/microsoft/language-server-protocol/issues/18); it's
not at all clear when/if that will make it into the standard.

It appears LSP is not actually a "standard", just something Microsoft is
making available; it is totally controlled by Microsoft. I'd be happier
if they turned it over to some standards org (FSF, ISO, IEEE, ...).

So far, I have not noticed a speed problem (even on very large files),
but I haven't really pushed it yet.

ada_language_server does one thing better than current ada-mode; provide
cross reference information. Currently ada-mode uses some files output
by the compiler to get cross-references; processing that information is
noticeably slow, and the information gets out of date, so the user must
request a cache refresh. ada_language_server provides cross references
directly from the parsed sources, with no caching issues. So I'll work
on adding that as an alternative xref backend for ada-mode.

--
-- Stephe



reply via email to

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