Christoph Wedler <wedler(a)fmi.uni-passau.de&gt; writes: Look at what the font-lock does in the end: it ataches faces to regions of the buffer. That sounds like extents to me. That may be implemented now as "regions of chars with certain properties". (Note that the 'add-non-duplicable-text-properties' in questions is called on regions!) That is just an implementation detail. It could very well just be that each of the two codes keeps its own extent. Note at the typical font lock example "A lisp format %s with %s escapes" Now the syntactical view of this is a string with escape chars. This is very clearly expressed with extents "A lisp format %s with %s escapes" [------string-face---------------] [] [] Where [] = is "[scape char face]", or a TeX example $ a = \alpha + \int d f $ [ -- math face --- ] [ sy ] [sy] The XEmacs redisplay code can handle such layering quite well. It is also cheap to insert (it is removing and maybe editing that is difficult). The text-properties view of this is $ a = \alpha + \int d f $ MMMMMMSSSSSSMMMMSSSSMMMMMM which XEmacs implements as $ a = \alpha + \int d f $ [ M ][ S ][ M][ S][ M ] the famous non-overlapping extents. My point is that this non-overlapping stuff is making the code inefficient 1. Finding all extents overlapping a certian region is inefficient outside of redisplay in the current implementation. 2. It is doing unneeded double work. The redisplay code already transforms stacked extents in non-overlapping extent fragments. It can do so much more efficiently since it can work linearly through the extents. I am a bit worried about being able to support the 'append keywords efficiently. Neither c-mode nor elisp-mode has them but font-latex has a whole lot. However it you look at the call-counts you see that it is almost never used on the real files. Jan P.S. If I am not mistaken font-lock is origionally a lucid Emacs thing and predates tex-properties. How did it work back then?