XEmacs font-lock has a "feature" where it refuses to start in buffers whose name begins with SPC. The idea begind the feature is to prevent accidental fontification of various temporary buffers. As accidental fontification goes, the argument stands. But I consider it really evil that it refuses to work even when turned on *explicitly*, and the same even when its own code turns it on. Here is a weird bug I've been seeing: Gnus tries to fontify part of the buffer by effectively doing the following: (insert (with-temp-buffer (funcall desired-major-mode) (font-lock-fontify-buffer) ... some code that forces all text-prop extents to be duplicable ... (buffer-string))) This works, but leaves everything except strings and comments unfontified. This bug had me baffled for a long time, because all my attempts to repeat it in "laboratory conditions" failed. Finally I tracked down the problem to this: font-lock-fontify-buffer temporarily sets font-lock-mode because some of its magic depends on font-lock-mode being on. But since the buffer name begins with SPC, font-lock-mode silently (which is evil!) refuses to turn itself on, and fontification fails in a random way. I think the optimization should be changed to only affect turning on font-lock with font-lock-auto-fontify and friends. If somebody explicitly turns on font-lock, either through `font-lock-fontify-buffer' or otherwise, it has to just work, regardless of what the buffer happens to be named! If that is for whatever reason undesirable, we should at least implement a `force' argument for font-lock-mode which you can call and be sure that font-lock will be used.