The "noverlay" branch was merged to master. This should speed up overlays in emacs

As mentioned [here](https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01774.html): > For those who're not familiar with this branch, it changes the way > overlays are stored in a buffer: instead of keeping them in naïve > singly-linked lists, it keeps them in balanced binary trees, so as to > replace an O(N) complexity with O(log N). This way Emacs should not get > sluggish even with millions of overlays (of course, if a given buffer > position is covered by a million overlays, it'll still be sluggish when > operating around that position).

That is pretty cool. But here I am retaining support for 24.4.

Wonder if that will help with those terrifyingly huge json or xml (etc) files..

Why 24.4? I stay on Ubuntu LTS so I am stuck with 27.1 but [Ubuntu 18.04 ships 25.2](https://packages.ubuntu.com/bionic/emacs), too.

Emacs 25.x and 26.x had a lot of regressions. 24.4 is the Snow Leopard of Emacs. What's Ubunto? Edit: sorry I will need to remember that Ubuntu users are very sensitive.

Oh, I didn't know that. > What's Ubunto? [It's a Linux distribution.](https://en.wikipedia.org/wiki/Ubuntu) (Possibly the most popular but I'm unsure?) Just as you don't know Ubuntu, I also don't understand your MacOS reference. :) Emacs reaches far and wide.

Lol jk.

It could, but only if those modes tend to create a lot of overlays. That is an implementation detail that you wouldn't normally know about unless you looked into the lisp source.

Lol what?

I think that huge json files with long lines have been addressed earlier when long-line branch has been merged. ;)

Nice, more avy and inline eval !

AFAIR org-mode makes heavy use of overlays, and so this can be expected to improve performance in large org buffers. (I don't much use org-mode, so I don't have any large files to test with; but this particular benefit may be of more interest to other readers.)

Ubuntu users are a tough crowd.

I was more confused by the snow leopard comment.

Snow Leopard is like the "good old days" version of OS X, widely considered Apple's high point. The analogy isn't precise because I think Emacs 28.x is an improvement on 24.x. I think maybe 26.x was the Windows Vista version.

Ihor posted a comparison somewhere in the discussion that showed the noverlay code was as fast as the newly added text property code for folding in org buffers for large files. IIRC, the noverlay code is a second shy of the text property pathway.

Cool, yes please.

It's so incredible how Emacs just keeps getting better. I'm in awe with the work you good folks are doing, in spite of the code base being a non-trivial one to navigate for the non-inducted (that's me, can read some C and Lisp but the emacs source still makes my head spin at times). So grateful. 😻

[deleted]

What's an overlay?

https://www.gnu.org/software/emacs/manual/html_node/elisp/Overlays.html

Ah, so it's distinct from the text face, but overrides the appearance of the text for a specific range. emacs-langtool I guess uses an overlay to highlight ranges that need some grammar addressed.

[deleted]

sounds great, anyone have some benchmarks? or video with comparison?

I guess hs-minor-mode uses overlays a lot, so this shoul see a huge improvent?

I tested the [build](https://github.com/kiennq/emacs-build/tree/v29.166.20221101.c618a22) and couldn't perceive any performance gain. What I did: * Open a large json file (3_605_000 lines, pretty-printed, 73Mb) * `C-u 3 C-c @ C-l` * Hideshow takes about 50 seconds. If I use the [previous build](https://github.com/kiennq/emacs-build/tree/v29.162.20221017.1251342) it's about the same time. So hide-show doesn't seem to profit?

Out of curiosity, what are some common packages/modes that use a lot of overlays? /u/7890yulop mentioned org-mode, so that's neat. I might also guess that eglot and/or lsp-mode probably use overlays for symbol highlighting and stuff, but can someone confirm that?