font-lock-fontify-buffer is an interactive command and when it is invoked as a buffer not intended for font-lock fontification, this breaks highlighting in all other non font-lock buffers.
A simple way to reproduce: C-h i M-x font-lock-fontify-buffer RET and after this to see that highlighting is broken in all other buffers: M-x list-colors-display RET M-x list-faces-display RET ... That's because font-lock-default-fontify-buffer doesn't make the variable font-lock-keywords buffer-local, and its global value gets compiled to `(t nil)'. After creating new buffers, font-lock-default-function checks font-lock-keywords for nil, and since its global value is now `(t nil)', it calls font-lock-mode-internal which removes all highlighting from every non font-lock buffer. This bug was responsible for removing highlighting from Gnus buffers, and now it is avoided but not calling font-lock-fontify-buffer from hi-lock mode. But I think it should be fixed no matter if it called from hi-lock or not. I see at least three solutions: * check font-lock-keywords in font-lock-default-function for the compiled empty value `(t nil)' and don't call font-lock-mode-internal for this value; * make the variable font-lock-keywords automatically buffer-local; * in font-lock-default-fontify-buffer call font-lock-set-defaults regardless of the value of font-lock-mode, or depending on some other condition, e.g. if (local-variable-p 'font-lock-keywords). -- Juri Linkov http://www.jurta.org/emacs/ _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
