hi-lock mode and special buffers

hi-lock mode and special buffers

[Romain Francoise]

Hi,

This change:

2005-11-12  Chong Yidong  <cyd@stupidchicken.com>

	* hi-lock.el (hi-lock-mode): Set the default value of
	font-lock-defaults.

breaks fontification in special buffers if hi-lock mode is enabled.
This affects Gnus and ERC, among others; see Bill's report about Gnus
(<9993.1131326507@olgas.newt.com>) and the following Debian bug:

    <URL: http://bugs.debian.org/339920>

What was this change supposed to fix?  Is there a better way?

Thanks,

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: hi-lock mode and special buffers

[Chong Yidong]

Romain Francoise <romain@orebokech.com> writes:

> This change:
>
> 2005-11-12  Chong Yidong  <cyd@stupidchicken.com>
>
> 	* hi-lock.el (hi-lock-mode): Set the default value of
> 	font-lock-defaults.
>
> breaks fontification in special buffers if hi-lock mode is enabled.
> This affects Gnus and ERC, among others; see Bill's report about Gnus
> (<9993.1131326507@olgas.newt.com>) and the following Debian bug:
>
>     <URL: http://bugs.debian.org/339920>
>
> What was this change supposed to fix?  Is there a better way?

The bug is "No highlight in compilation-minor-mode when hi-lock-mode
is on", at

http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-11/msg00173.html

The old behavior of hi-lock mode is that it sets the
font-lock-defaults to '(nil) when it is turned on.  However,
font-lock-defaults is buffer-local, so the value for other buffers is
unchanged, even though hi-lock-mode applies to them as well.  That was
the source of the incompatibility with compilation-minor-mode.

Re: hi-lock mode and special buffers

[Chong Yidong]

Romain Francoise <romain@orebokech.com> writes:

> This change:
>
> 2005-11-12  Chong Yidong  <cyd@stupidchicken.com>
>
> 	* hi-lock.el (hi-lock-mode): Set the default value of
> 	font-lock-defaults.
>
> breaks fontification in special buffers if hi-lock mode is enabled.
> This affects Gnus and ERC, among others; see Bill's report about Gnus
> (<9993.1131326507@olgas.newt.com>) and the following Debian bug:
>
>     <URL: http://bugs.debian.org/339920>

By the way, I can reproduce this bug even after reverting my
2005-11-12 change, using the recipe given in
http://bugs.debian.org/339920:

M-x gnus
M-x highlight-regexp RET gnu RET RET
 => gnus-group face highlighting dies

Re: hi-lock mode and special buffers

[Chong Yidong]

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?

Re: hi-lock mode and special buffers

[Romain Francoise]

Chong Yidong <cyd@stupidchicken.com> writes:

> The bug is "No highlight in compilation-minor-mode when hi-lock-mode
> is on", at

> http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-11/msg00173.html

Thanks.

> The old behavior of hi-lock mode is that it sets the
> font-lock-defaults to '(nil) when it is turned on.

Two questions come to mind:

1. Why does it touch font-lock-defaults since it uses the
   self-sufficient function `font-lock-add-keywords'?

2. Why does it set font-lock-defaults to that value if it has no
   patterns to add anyway?

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: hi-lock mode and special buffers

[Romain Francoise]

Chong Yidong <cyd@stupidchicken.com> writes:

> By the way, I can reproduce this bug even after reverting my
> 2005-11-12 change, using the recipe given in
> http://bugs.debian.org/339920:

> M-x gnus
> M-x highlight-regexp RET gnu RET RET
>  => gnus-group face highlighting dies

It's always been like that, even in Emacs 21.  What your change does is
that it makes the problem global to all special buffers, not just the
buffer where `highlight-regexp' is called.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: hi-lock mode and special buffers

[Romain Francoise]

Chong Yidong <cyd@stupidchicken.com> writes:

> After studying hi-lock.el more closely, I think there is more than one
> problem at work here.

[...]

> Sound like a plan?

If you think you can fix hi-lock mode in time for the release, then
please do so.  I wouldn't mind leaving things as they were in Emacs 21
(by just reverting your patch).

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter