--- Matt Tucker <tuck(a)whistlingfish.net&gt; wrote: In XEmacs, text properties are just a fancy way of interfacing to extents. This means that when you "apply one of these to a range of characters", the `put-text-property' code defines an extent behind the scenes. When you create two such regions that touch, the code notices it and merges the two adjacent extents. And so on. All of this code is implemented in Lisp (some stuff was converted to C for speed, though). Therefore, at Lisp level, you can use both interfaces (textprops have been provided as a convenience as well as a porting help). However, to in order to add a new low-level feature, it only makes sense to add it to the C implementation of extents. Extents, as well as text properties, are described in the XEmacs Lisp reference manual (Lispref) in depth. GNU Emacs has overlays, which are a parallel implementation of the same or very similar feature. Under XEmacs, text properties are implemented using extents. This is not the case with GNU Emacs. With GNU Emacs text properties, they're not. But in XEmacs, it's a bit different. I just wanted to remind you of the option. Yup. But I don't think syntactically-sectionize and friends in font-lock.c will be a problem to modify; they merely handle strings and comments anyway. The real beef is in the engine behind parse-partial-sexp. I'm not sure what caching mechanisms Emacs uses. It might well show that different optimization strategies will apply to XEmacs, due to a vastly different extents code. I have a feeling that under XEmacs it is much more expensive to search for an extent on a char-by-char bases, due to them being stored as a list, whereas under GNU Emacs, properties are a balanced tree. which thorn. Thanks. I wish you the best of luck. Then I might look into Tcl mode and making it suck less. :-) __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/