[Top][All Lists]
[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.
- Re: font-lock-add-keywords in hi-lock.el, (continued)
- Re: font-lock-add-keywords in hi-lock.el, Bill Wohler, 2005/12/30
- Re: font-lock-add-keywords in hi-lock.el, Luc Teirlinck, 2005/12/30
- Re: font-lock-add-keywords in hi-lock.el, Luc Teirlinck, 2005/12/30
- Re: font-lock-add-keywords in hi-lock.el, Bill Wohler, 2005/12/30
- Re: font-lock-add-keywords in hi-lock.el, Stefan Monnier, 2005/12/30
- Re: font-lock-add-keywords in hi-lock.el, Bill Wohler, 2005/12/30
- Re: font-lock-add-keywords in hi-lock.el, Stefan Monnier, 2005/12/30
- Re: font-lock-add-keywords in hi-lock.el, Bill Wohler, 2005/12/30
- Re: font-lock-add-keywords in hi-lock.el,
Bill Wohler <=