A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00565.html below:

State of the overlay tree branch?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Sebastian Sturm Subject: State of the overlay tree branch? Date: Sun, 18 Mar 2018 21:14:53 +0100 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
Hi,

after finding that the feature/noverlay branch does wonders for my editing experience[1], I'd like to reinvigorate the discussion on its inclusion into master. Are there plans for a merge with the emacs-27 master branch? Any critical issues blocking such a merge?
If a recent Emacs 27 variant with the overlay branch feature was available, I'd be happy to evaluate that in my daily work. 
best regards,
Sebastian Sturm

[1] I'm using cquery for my C++ editing needs, which comes with an overlay-based semantic highlighting mechanism. With my emacs configuration, lsp-mode/lsp-ui emit 6 calls to line-number-at-pos per character insertion, which consume ~20 to 25 ms each when performing edits close to the bottom of a 66KB C++ file (measured using (benchmark-run 1000 (line-number-at-pos (point))) on a release build of emacs-27/git commit #9942734...). Using the noverlay branch, this figure drops to ~160us per call.





RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4