[Top][All Lists]

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

Re: State of the overlay tree branch?

From: Sebastian Sturm
Subject: Re: State of the overlay tree branch?
Date: Fri, 23 Mar 2018 11:15:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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

reply via email to

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