I'm cc'ing xemacs-beta on this one, since it includes some discussion about general design issues. I'm attaching the previous messages (which went to xemacs-review), for those who are interested in reading the discussion leading up to this. This is all based on a recently submitted patch which can be found at <http://www.xemacs.org/list-archives/xemacs-patches/200010/msg00077.htm l>. -- Hrvoje Niksic <hniksic(a)arsdigita.com&gt; spake thusly: Absolutely. In fact, it's next on my list of things to do. FSF supports it, but my impression is that that support might not be complete. (I've noticed there are a few places in the FSF code where they don't correctly lookup the syntax table property. My suspicion is that since this is not a heavily used feature, this hasn't ever been noticed. I'm trying to clean up these instances as I go.) Thanks for the suggestion. I'll take care of that. I can certainly see the value in it. I'm a bit concerned about the cost of having to calculate that each time through the parse (on top of lookup up all the extents in the first place). I suppose the right way to do it is instead of keeping a single syntax table, keep a list of all syntax tables (from innermost out to the buffer's) and when doing the lookup for a character run through this list until a match is hit. One question would be whether a specified code could be overridden by a more specific table. For example: This is some text with custom syntax tables. ^---- custom table ---------------^ ^-- whitespace --------------^ ^ -- custom table -^ Would "custom syntax tables" be whitespace, or would it use the second custom table for its lookups, and only be whitespace in the case of characters that don't have a match in the second table? I'll probably end up implementing overlappable extents in the next version, despite the fact that I don't see a need for it yet. (Perhaps someone else will, if the feature is there.) Thanks. I didn't realize either of these, but I'll make the necessary changes.