From: Sebastian Sturm <s.sturm@arkona-technologies.de>
To: emacs-devel@gnu.org
Subject: Re: State of the overlay tree branch?
Date: Fri, 23 Mar 2018 11:15:48 +0100 [thread overview]
Message-ID: <3098c9f6-31c4-e611-22af-865ba810f860@arkona-technologies.de> (raw)
In-Reply-To: <83efkbi2hb.fsf@gnu.org>
On 03/23/2018 10:08 AM, Eli Zaretskii wrote:
>> Date: Fri, 23 Mar 2018 11:07:26 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>>
>> 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
next prev parent reply other threads:[~2018-03-23 10:15 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-18 20:14 State of the overlay tree branch? Sebastian Sturm
2018-03-18 20:39 ` Eli Zaretskii
2018-03-18 21:04 ` Sebastian Sturm
2018-03-18 23:03 ` Sebastian Sturm
2018-03-18 23:20 ` Sebastian Sturm
2018-03-19 6:43 ` Eli Zaretskii
2018-03-19 9:53 ` Sebastian Sturm
2018-03-19 12:57 ` Eli Zaretskii
2018-03-19 14:56 ` Stefan Monnier
2018-03-19 15:07 ` Sebastian Sturm
2018-03-19 15:13 ` Stefan Monnier
2018-03-20 1:23 ` Sebastian Sturm
2018-03-20 6:30 ` Eli Zaretskii
2018-03-21 0:36 ` Sebastian Sturm
2018-03-21 6:47 ` Eli Zaretskii
2018-03-22 13:16 ` Stefan Monnier
2018-03-22 19:54 ` Sebastian Sturm
2018-03-22 20:04 ` Sebastian Sturm
2018-03-22 20:52 ` Stefan Monnier
2018-03-22 23:11 ` Sebastian Sturm
2018-03-23 5:03 ` Stefan Monnier
2018-03-23 12:25 ` Sebastian Sturm
2018-03-23 12:47 ` Eli Zaretskii
2018-03-23 13:19 ` Stefan Monnier
2018-03-23 13:37 ` Noam Postavsky
2018-03-23 13:55 ` Stefan Monnier
2018-03-23 14:22 ` Eli Zaretskii
2018-03-23 14:39 ` Stefan Monnier
2018-03-23 19:39 ` Stefan Monnier
2018-03-25 15:11 ` Stefan Monnier
2018-03-25 16:39 ` Eli Zaretskii
2018-03-25 17:35 ` Stefan Monnier
2018-03-23 8:07 ` Eli Zaretskii
2018-03-23 9:08 ` Eli Zaretskii
2018-03-23 10:15 ` Sebastian Sturm [this message]
2018-03-23 12:39 ` Eli Zaretskii
2018-03-23 12:12 ` Stefan Monnier
2018-03-23 12:40 ` Eli Zaretskii
2018-03-23 12:55 ` Stefan Monnier
2018-03-19 6:36 ` Eli Zaretskii
2018-03-19 6:28 ` Eli Zaretskii
2018-03-21 14:14 ` Sebastien Chapuis
2018-03-21 15:35 ` Eli Zaretskii
2018-03-26 13:06 ` Stefan Monnier
2018-03-27 20:59 ` Sebastian Sturm
[not found] <<c24f8534-5245-026e-da18-f6be7b9702bf@arkona-technologies.de>
[not found] ` <<834lldp18f.fsf@gnu.org>
2018-03-18 21:37 ` Drew Adams
2018-03-19 1:33 ` Stefan Monnier
2018-03-19 6:50 ` Eli Zaretskii
2018-03-19 12:29 ` Stefan Monnier
2018-03-19 13:02 ` Eli Zaretskii
2018-03-19 13:43 ` Stefan Monnier
2018-03-19 14:28 ` Eli Zaretskii
2018-03-19 14:39 ` Stefan Monnier
2018-03-19 6:33 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3098c9f6-31c4-e611-22af-865ba810f860@arkona-technologies.de \
--to=s.sturm@arkona-technologies.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.