On 11.4.2013, at 19:30, Eli Zaretskii <e...@gnu.org> wrote: >> From: Carsten Dominik <carsten.domi...@gmail.com> >> Date: Thu, 11 Apr 2013 04:58:15 +0200 >> Cc: "emacs-orgmode@gnu.org List" <emacs-orgmode@gnu.org>, >> Eli Zaretskii <e...@gnu.org> >> >>> I guess Eli simply means, in a general way, that overlays do negatively >>> impact >>> display performance, as you said as well a couple of times: >> >> Yes, but Eli says that Org already severely tests the >> display engine, and he uses the word "mess", even though >> we mostly use text properties for faces and other >> display-related things. > > Well, don't interpret "mess" too literally ;-)
I will add an overlay that displays "mess" as "mix" :D > >> Of course, Org already uses overlays, for example for >> folding (as does outline.el), and for temporary marking >> of text like during src block editing. But as your digging >> shows, I ave avoided them in the past, and we are also not >> using them for org-indent.el, for example. >> >> The reason why I said "overlays would be better" is simply >> that they would allow to add display properties in a >> persistent way that would not interfere that our >> font-lock-unfontify-region function removes face and >> invisibility text properties. So they are "better" for >> implementing hand-made faces selection that should overrule >> font-lock. > > Overlays should be OK as long as they aren't too many, and as long as > you don't move them around too much, particularly in post-command-hook > or some such. This explanation sounds to me as if the display engine is building some kind of tree of overlays to find properties changes quickly. Too bad I don't have time to understand this stuff in more detail, it sounds interesting. - Carsten