emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bill Wohler
Subject: Re: font-lock-add-keywords in hi-lock.el
Date: Fri, 30 Dec 2005 15:46:31 -0800
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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?

-- 
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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]