Bending Emacs - Episode 6: Overlays

i once spent an inordinate amount of time trying to optimize beacon.el (once i'd gotten it to play nice with collapsed org-mode headers). i was desperate for a way to get pixel-perfect information about windows/frames/lines/point without eg. creating excess overlays (keeping a pool?), paying to populate the whole data-structure returned by position-at-point -- in practice, caching to the maximum extent. Custom blending modes was fun. But it got hairy for a bunch of reasons!

• Emacs decides when/where to break lines in the C core, while rendering the "glyph matrix" (xdisp.c). I thought anything was possible with elisp? /j
• "Text regions" are just sequential characters with shared properties. Multiple properties (at least overlay, display, and composition) can change how regions are rendered, and i think each of those 3 can replace a region with new text that has it's own properties, which may or may not allow nesting.
• How wide any given glyph is depends on uncountable build/run-time circumstances, global/buffer-local variables, etc., and again there's no performant way to tell without patching C or re-impl'ing logic from within both emacs and it's uncountable major modes. Haven't even touched on terminal vs gui mode, or proportional fonts!

Every time I see someone using beacon afk i promise myself i'll find my old checkout(s), straighten them out, build vm/snapshot tests, and publish it, but i'm not sure i will >u< Might try re-writing it an 8th+ time as a C "extension" though, for speed and robustness

i usually tell this story to poke fun at the limits of elisp