Bill Wohler <[EMAIL PROTECTED]> writes: > signal(error ("Font-lock trying to use keywords before setting them up")) > error("Font-lock trying to use keywords before setting them up") > font-lock-compile-keywords(nil t) > font-lock-fontify-keywords-region(1 81 nil) > font-lock-default-fontify-region(1 80 nil) > font-lock-fontify-region(1 80) > mh-add-sequence-notation(1 t) ...
I think the bug is in font-lock, not in MH-E. I see that font-lock-default-fontify-buffer calls font-lock-set-defaults. It seems that font-lock-fontify-region is a perfectly good entry point to font-lock so that font-lock-default-fontify-region might as well call font-lock-set-default too. When I added a call to font-lock-set-default to to the top of font-lock-default-fontify-region, the bug went away. Does this sound right? Are the modes responsible for calling this seemingly internal function. It certainly isn't documented. I do see that dig.el, sh-script.el, and vhdl-mode.el call this function, but maybe these were added to work around this bug. I'd appreciate it if someone who was more familiar with this code inserted the call to font-lock-set-default in the correct place (I had just inserted it blindly at the top). Also, it would be a good idea to check the other functions and see if there are other entry points that are missing this call. There is one inconsistent call to font-lock-set-default. font-lock-fontify-block checks for (not font-lock-mode) first before calling font-lock-set-default. The rest just go ahead and call font-lock-set-default. Maybe all these calls to font-lock-set-defaults can be replaced with a single call to font-lock-set-defaults in font-lock-compile-keywords to replace this code: (if (not font-lock-set-defaults) ;; This should never happen. But some external packages sometimes ;; call font-lock in unexpected and incorrect ways. It's important to ;; stop processing at this point, otherwise we may end up changing the ;; global value of font-lock-keywords and break highlighting in many ;; other buffers. (error "Font-lock trying to use keywords before setting them up")) > OK, that's better, thanks! I still need to check the other calls on the > stack, but mh-visit-folder contains this: > > (make-local-variable 'font-lock-defaults) > (setq font-lock-defaults '(mh-folder-font-lock-keywords t)) > > Is this the usual way of injecting one's keywords? > > Will also RTFM. The manual seems to indicate that setting font-lock-defaults in this fashion is exactly the right way to proceed. It also implies that font-lock-defaults is already buffer local so we should be able to delete the make-local-variable call above, right? -- Bill Wohler <[EMAIL PROTECTED]> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug