Chris Ball <chris(a)void.printf.net&gt; wrote: No. There is no such variable. Nor is there a global-font-lock-mode function. -- John Paul Wallington

Matt> This is a GNU Emacs thing. The XEmacs equivalent seems to be Matt> font-lock-auto-fontify, which by default is t. XEmacs doesn't have an equivalent. Presumably that's an oversight. Before you violate the Global Variable Antiproliferation Treaty by adding yet another, please consider whether maybe the right interface isn't to shit-can the "this-mode-font-lock-enabled" code in favor of (set-specifier enable-font-lock t (current-buffer)) etc. Then to get the effect you want, you do (set-specifier enable-font-lock t 'global) Unfortunately specifiers do not support modes as locales, but it should be possible to hack around that by testing whether the specifier's value is correct in the current buffer at mode startup, and if not setting the specifier in that buffer. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Matt> I'm not sure I agree with that. *shrug* The docstring for font-lock-auto-fontify says "fontify files as they are loaded." Matt> Without adding another global variable, would it be Matt> reasonable to try to use the GNU Emacs hack to enable Matt> font-lock for non-file buffers? Depends on what you mean by "weird hack." It seems to me that the logical thing to do is to admit that font-lock has nothing to do with files and everything to do with buffers, and move the font lock enabling hooks to the buffer creation code. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Matt> Good point. But I'd say Hrvoje beat you to it. :-) Matt> it has even more to do with modes than with buffers. I'm probably unusual; I do tend to have buffer-specific usage of font-lock (I turn it on when I'm worried about hairy syntax errors, otherwise off when I think I know what I'm doing). So I agree with you guys, especially since I don't see any way to implement my preferred behavior (requires reading my mind AFAICT :-). Matt> Perhaps the major-mode change is where the hooks should go? Yes. But wherever it goes, it should be transparent to the major-modes themselves. I don't know how easy that will be to implement, though. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: More precisely, with modes. Changing the mode using `M-x foo-mode' or even using `M-x normal-mode' should cause appropriate refontification.

Jeff Mincy <jeff(a)delphioutpost.com&gt; wrote: GNU Emacs has global-font-lock-mode. It automagically turns on fontification [*]. I think the closest XEmacs has is font-lock-auto-fontify, but this variable is concerned with turning on font-lock when visiting a file and doesn't turn on font-lock for ielm or ibuffer or modes which use font-lock but aren't about visiting files. * from the sources: ;; In a previous discussion the following hack came to mind. It is a gross ;; hack, but it generally works. We use the convention that major modes start ;; by calling the function `kill-all-local-variables', which in turn runs ;; functions on the hook variable `change-major-mode-hook'. We attach our ;; function `font-lock-change-major-mode' to that hook. Of course, when this ;; hook is run, the major mode is in the process of being changed and we do not ;; know what the final major mode will be. So, `font-lock-change-major-mode' ;; only (a) notes the name of the current buffer, and (b) adds our function ;; `turn-on-font-lock-if-enabled' to the hook variables `find-file-hooks' and ;; `post-command-hook' (for buffers that are not visiting files). By the time ;; the functions on the first of these hooks to be run are run, the new major ;; mode is assumed to be in place. This way we get a Font Lock function run ;; when a major mode is turned on, without knowing major modes or their hooks. ;; ;; Naturally this requires that (a) major modes run `kill-all-local-variables', ;; as they are supposed to do, and (b) the major mode is in place after the ;; file is visited or the command that ran `kill-all-local-variables' has ;; finished, whichever the sooner. Arguably, any major mode that does not ;; follow the convension (a) is broken, and I can't think of any reason why (b) ;; would not be met (except `gnudoit' on non-files). However, it is not clean. -- John Paul Wallington