Re: font-lock-add-keywords in hi-lock.el

[Bill Wohler]

Bill Wohler <address@hidden> writes:

> Bill Wohler <address@hidden> 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?

I haven't gotten any replies to this message.

I've been running the following patch for the past week which has
fixed the Gnus fontification bug. May I check it in?

Index: font-lock.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/font-lock.el,v
retrieving revision 1.290
diff -u -r1.290 font-lock.el
--- font-lock.el        3 Jan 2006 17:00:35 -0000       1.290
+++ font-lock.el        5 Jan 2006 22:50:10 -0000
@@ -1028,6 +1028,8 @@
 a very meaningful entity to highlight.")
 
 (defun font-lock-default-fontify-region (beg end loudly)
+  ;; Make sure we have the right `font-lock-keywords' etc.
+  (font-lock-set-defaults)
   (save-buffer-state
       ((parse-sexp-lookup-properties
         (or parse-sexp-lookup-properties font-lock-syntactic-keywords))

-- 
Bill Wohler <address@hidden>  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.