From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Sebastian Sturm Newsgroups: gmane.emacs.devel Subject: Re: State of the overlay tree branch? Date: Fri, 23 Mar 2018 11:15:48 +0100 Message-ID: <3098c9f6-31c4-e611-22af-865ba810f860@arkona-technologies.de> References: <834lldp18f.fsf@gnu.org> <9646341d-700b-4240-216b-8c0e753fa79f@arkona-technologies.de> <86d03e78-9984-f33e-a3f3-3faa4b34d78b@arkona-technologies.de> <83vadso9ad.fsf@gnu.org> <5155d5e2-6b5c-581e-89fe-4f3af717304f@arkona-technologies.de> <4c82fcbd-961a-c6ca-b1f0-6b85665cb339@arkona-technologies.de> <83o9jfi5a9.fsf@gnu.org> <83efkbi2hb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1521800043 28203 195.159.176.226 (23 Mar 2018 10:14:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Mar 2018 10:14:03 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 23 11:13:59 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ezJhv-0007Al-Ax for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 11:13:59 +0100 Original-Received: from localhost ([::1]:36984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezJjw-00031P-QX for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2018 06:16:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ezJjn-00030O-3u for emacs-devel@gnu.org; Fri, 23 Mar 2018 06:15:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ezJjj-0006KT-3j for emacs-devel@gnu.org; Fri, 23 Mar 2018 06:15:55 -0400 Original-Received: from smtp-out002.kontent.com ([81.88.40.216]:50122) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ezJji-0006KB-T1 for emacs-devel@gnu.org; Fri, 23 Mar 2018 06:15:51 -0400 Original-Received: from [172.16.222.49] (unknown [213.157.6.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: arkona-technologies_de_22@smtp-out002.kontent.com) by smtp-out002.kontent.com (Postfix) with ESMTPSA id 1F2C6C003F464 for ; Fri, 23 Mar 2018 11:15:49 +0100 (CET) In-Reply-To: <83efkbi2hb.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 81.88.40.216 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223951 Archived-At: On 03/23/2018 10:08 AM, Eli Zaretskii wrote: >> Date: Fri, 23 Mar 2018 11:07:26 +0300 >> From: Eli Zaretskii >> 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