I've finally found a very short and easy recipe to reliably reproduce
this bug. It took a lot of widdling down, but I identified the
culprit as highlight-regexp. I haven't investigated what it is doing
that is causing the problem. More likely than not, you'll be able to
reproduce this problem by simply running M-x highlight-regexp anywhere
in emacs and then observing that gnus buffers created after that no
longer have colors in them. In case that's not sufficient, here's an
exact recipe to reproduce the bug.
Create an empty directory
cd to the directory
Create .emacs in that directory with the following contents:
==========
(setq
gnus-select-method '(nnfolder "")
mail-sources '((file :path "~/incoming"))
gnus-group-highlight '((t . gnus-group-news-1-face))
)
(defun break-gnus-colors ()
(interactive)
(save-excursion
(with-temp-buffer
(highlight-regexp "^Not: Found$" 'highlight)
)
)
)
==========
run
HOME=$PWD emacs &
M-x gnus
Observe that the list of groups are highlighted in a color. Hit enter
over nndoc+gnus-help:gnus-help. Hit ! a few times, observing that the
items change color. Hit "q" to exit summary mode and enter to get
back in a few times to observe that colors stay as expected.
>From the *Group* buffer, run
M-x break-gnus-colors
Now hit enter over nndoc+gnus-help:gnus-help again. This time,
observe that the colors are not present. Hit q to return to *Group*
and q again to exit gnus. Run M-x gnus. This time, observe that the
*Group* buffer is also not colored.
That's about it -- please let me know if you are able or not able to
reproduce this using this formula.
I finally figured this out by noticing that the operation I did before
colors stopped working was to load an rmail file. I have an
rmail-show-message-hook that calls highlight-regexp. At first, I just
observed that loading and killing an rmail file was sufficient to
cause the problem. I then widdled down my configuration until I
realized that this was what it was.
Below is the reply I originally started to compose before I managed to
figure out an exact formula.
------------------------------------------------
Finally this evening I've managed to get my emacs into a state where
this problem has occurred.
> * Going further
>
> As I still can't reproduce this, I need one of you guys to do the
> following: in a buffer where the bug occurs, send me the output of
> `C-u C-x =' on any of the characters of
> - a region where colorization is normal (the bug doesn't affect this
> region), we'll call this character X.
> - a region where there is no colorization (the bug affects the region),
> we'll call this char Y.
Here's a character from a buffer that has no coloration but should
(character Y):
======
character: R (0122, 82, 0x52, U+0052)
charset: [ascii] (ASCII (ISO646 IRV))
code point: [82]
syntax: w which means: word
category: a:ASCII l:Latin
buffer code: 0x52
file code: 0x52 (encoded by coding system mule-utf-8)
display: by this font (glyph code)
-Misc-Fixed-Medium-R-Normal--13-120-75-75-C-70-ISO10646-1 (0x52)
There is an overlay here:
From 14 to 15
face [gnus-summary-selected]
There are text properties here:
fontified nil
gnus-number 1749
mouse-face [highlight]
======
Here's a character from a buffer that has normal coloration.
(Character X) (It's an old buffer.)
======
character: m (0155, 109, 0x6d, U+006D)
charset: [ascii] (ASCII (ISO646 IRV))
code point: [109]
syntax: w which means: word
category: a:ASCII l:Latin
buffer code: 0x6D
file code: 0x6D (encoded by coding system mule-utf-8)
display: by this font (glyph code)
-Misc-Fixed-Medium-R-Normal--13-120-75-75-C-70-ISO10646-1 (0x6D)
There are text properties here:
face [gnus-group-mail-2-empty-face]
fontified nil
mouse-face [highlight]
======
> Hypothesis B:
>
> Char X has a valid `face' property, and
> Char Y doesn't have a `face' property, and optionally has a
> `fontified' property with value nil: this would mean that the bug is
> caused by code that removes the `face' text property from the
> character.
This is what is happening.
I'm going to exit and restart gnus so that the coloring disappears
from my group buffer as well and look at the character X again. Here
it is (character X'):
======
character: m (0155, 109, 0x6d, U+006D)
charset: [ascii] (ASCII (ISO646 IRV))
code point: [109]
syntax: w which means: word
category: a:ASCII l:Latin
buffer code: 0x6D
file code: 0x6D (encoded by coding system mule-utf-8)
display: by this font (glyph code)
-Misc-Fixed-Medium-R-Normal--13-120-75-75-C-70-ISO10646-1 (0x6D)
There are text properties here:
fontified nil
mouse-face [highlight]
======
The only difference between X and X' is that X' has no face property.
I have some vague guesses as to what I may have just done right before
this happened. I'm going to spend some time trying to reproduce this
bug.
/me tries to reproduce the bug
Ha! I seem to have found a reliable formula to reproduce the bug!
Now I'll try to simplify it.
Done....placing simplified formula at the top of the message.
--Jay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
