Emanuel Berg <[email protected]> writes:
>> Or you can put your current `font-lock-add-keywords'
>> call into your ~/.gnus. Then it would be evaluated
>> before gnus-browse-mode was activated.
>
> It is in an init file and it is evaluated before the
> mode is set. For some reason it doesn't kick in
> without the explicit call to
> `font-lock-fontify-buffer'. That has never been needed
> elsewhere in my experience.
Ah, yeah, now I see it. I've thought you'd call
`font-lock-add-keywords' in the hook but you actually only call
`font-lock-fontify-buffer' there.
I think the reason why you need to trigger font-locking explicitly using
`font-lock-fontify-buffer' (or `font-lock-ensure') is that
`gnus-browse-mode' doesn't set `font-lock-defaults' which would be used
to initialize `font-lock-keywords'. And that says:
,----[ C-h v nil RET ]
| font-lock-keywords is a variable defined in `font-lock.el'.
| [...]
| A user-level keywords list is what a major mode or the user would
| set up. Normally the list would come from `font-lock-defaults'.
| through selection of a fontification level and evaluation of any
| contained expressions. You can also alter it by calling
| `font-lock-add-keywords' or `font-lock-remove-keywords' with MODE = nil.
| [...]
`----
So calling `font-lock-add-keywords' with MODE = nil will also trigger
font-lock, and indeed
--8<---------------cut here---------------start------------->8---
(defun th/gnus-browse-mode-init ()
(font-lock-add-keywords
nil
'(("^\\(.\\)[[:space:]]+\\([[:digit:]]+\\):[[:space:]]\\(.*\\)"
(1 font-lock-keyword-face)
(2 font-lock-variable-name-face)
(3 font-lock-function-name-face)))))
(add-hook 'gnus-browse-mode-hook #'th/gnus-browse-mode-init)
--8<---------------cut here---------------end--------------->8---
does work for me.
Bye,
Tassilo
_______________________________________________
info-gnus-english mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/info-gnus-english
