Re: State of the overlay tree branch?

[Sebastian Sturm]

On 03/23/2018 10:08 AM, Eli Zaretskii wrote:
> > Date: Fri, 23 Mar 2018 11:07:26 +0300
> > From: Eli Zaretskii <address@hidden>
> > Cc: address@hidden
> >
> > Btw, why do you have so many overlays in these buffers?  Is this part
> > of lsp-mode implementation, or is the reason unrelated?

this is not related to lsp-mode itself, but to the semantic highlighter 
implemented by emacs-cquery (which is built on top of lsp-mode but 
implements additional features offered by the cquery backend). When set 
to use overlays (which provides a better visual experience than 
font-lock, as font-lock tends to get out of sync with the buffer during 
editing), the semantic highlighter retrieves a list of symbols within 
the current buffer and creates overlays to provide semantically 
meaningful syntax highlighting. It's not a feature I couldn't live 
without, but it's very precise and in principle could probably be faster 
than the syntax highlighting provided by cc-mode as C++ parsing is 
handled asynchronously by the clang-based native backend.

> Also, what about my suggestion to count lines in a relative manner,
> using count-lines from a line with a known number?  You never replied
> to that suggestion.

you're right, sorry. In my opinion, a caching mechanism might be a very 
useful thing to have if it provides further performance benefits on top 
of what the noverlay branch has to offer. However, since count-lines may 
not be the only function that has to convert between char and byte 
positions (or is it?), and since the noverlay branch seems to resolve 
the overlay issue without having to introduce additional complexity in 
the elisp layer, implementing a caching mechanism before noverlay is 
merged into the master branch seems like a premature optimization to me.
Of course this is a layman's opinion (and maybe the case of "few 
overlays but many markers" is not as pathological as it appears to me); 
if you think a line number cache should be implemented, I'll go and 
discuss that with the lsp-mode maintainers (assuming that they are among 
the heaviest users of line-number-at-pos).
Sebastian