Re: Using incremental parsing in Emacs

[Eli Zaretskii]

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