[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hi-lock mode and special buffers
From: |
Chong Yidong |
Subject: |
Re: hi-lock mode and special buffers |
Date: |
Thu, 24 Nov 2005 13:03:13 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
After studying hi-lock.el more closely, I think there is more than one
problem at work here.
First of all, `M-x highlight-regexp' turns on hi-lock-mode in all
buffers. This is unnecessary. I suggest the following fix:
1. Using define-minor-mode, define a buffer-local minor-mode
`hi-lock-buffer-mode' that does the same stuff as the current
`hi-lock-mode'.
2. Using define-global-minor-mode, define `hi-lock-mode' as a global
mode that turns on `hi-lock-buffer-mode'.
This will avoid having to set font-lock-defaults for all buffers, only
the local buffer. The global-minor-mode will turn on the local mode,
which can set font-lock-defaults just for that buffer. So the Gnus
group buffer won't lose when you use highlight-regexp elsewhere in
Emacs. (This was why my change made the bug surface -- it made
hi-lock-mode really take effect everywhere in Emacs.)
This does not address the incompatibility between the Gnus group
buffer and hi-lock-mode. The reason for *that* is that Gnus tweaks
the 'face property directly, instead of using font lock. On the other
hand, hi-lock works by adding the regexp that you want to highlight to
font-lock-keywords, and calling font-lock-fontify-buffer. This wipes
the existing face properties. (Incidentally, you don't need hi-lock
for this; go to the Gnus group and run M-x font-lock-fontify-buffer).
So we need another fix for this problem. I suggest making hi-lock
highlight faces on the first pass by altering the face properties in
the buffer directly. At the same time, it adds the desired regexp to
font-lock-keywords, but does *not* call font-lock-fontify-buffer.
When the buffer is subsequently changed, the changes will be fontified
by the font-lock engine.
Sound like a plan?