Romain Francoise <[EMAIL PROTECTED]> wrote:

> Oh, I think I managed to reproduce this: browsing Michael's config (yay
> for .emacs sharing) I noticed that he uses hi-lock-mode.  And indeed,
> enabling hi-lock-mode makes fontification disappear from some buffers in
> Gnus.
>
> Jay, are you using hi-lock-mode as well?  (If not, can you send me your
> config files?)

I'm not using hi-lock-mode.  I'd be glad to send you my config files.
They are old and big, and I haven't yet gone through the exercise of
adjusting them for emacs 22, though it is relatively high on my
personal to-do list.  There are probably fragments of my startup
environment that have existed since emacs 18.something.  With emacs 21
being the only version I ran for so long though, some of my very
careful version-specific code has decayed somewhat.  There are also
lots of functions in my emacs configuration that I wrote at a time
when they didn't exist in a standard way but that are no longer
necessary.

I'll send you my files separately not attached to the bug.  Thanks for
looking into it.  I'll simultaneously work on reproducing this with a
minimal configuration.  I'm not sure whether it's a question of time,
some specific action, some number of operations, or what.

Here are a few other things I've noticed:

 * This first time this ever happened, I was running an emacs-snapshot
   that had just been replaced by apt-get dist-upgrade.  When it
   started misbehaving, I immediately exited and restarted since I
   expected it to go south under the condition of being upgrade while
   being run.  (While running apt-get dist-upgrade and seeing that
   emacs-snapshot is in the list, I continue to use emacs but am
   cautious not to do something while emacs itself is in the process
   of being upgraded.)  It's hard for me to think of what could cause
   this behavior change in an already-running emacs.  I didn't
   unfortunately think to check the *Messages* buffer -- I didn't do
   any diagnosis at all, fully expecting to restart right away
   anyway.  It's also possible that it's coincidental and that the
   problem may have existed before and I just never happened to trip
   over it.

 * The second time it happened was fairly soon after restarting
   emacs.  That was when I sent the bug report.

 * The third time it happened, I had been running for a few hours
   before it happened.

 * Once the fontification stops, it remains working in any existing
   gnus buffer but doesn't work in any new gnus buffer.  For example,
   my *Group* buffer remains fontified, and getting new mail that
   causes new groups to show up results in those new groups being
   rendered in the proper color.  New summary buffers do not show
   color.  Messages displayed from the summary buffers are properly
   fontified as are all other buffers, new and old.  M-x
   font-lock-fontify-buffer has no effect on the gnus buffers.  If I
   quit gnus and restart it, the new *Group* buffer shows up without
   fontification.

Note that my original bug report mentioned lack of color and didn't
tie this to font-lock.  That's because I'm not aware of whether the
coloring in gnus is related to font-lock mode or not.  I was actually
under the impression that gnus did its own font implementation.

My gnus setup is very heavily customized.  I use it only for mail (I
don't read news anymore), and I have written lots of code to make it
behave in a more mailreaderly fashion in spite of cautions in the
documentation.

Rather than sending you my entire elisp directory consisting of almost
8,000 lines of elisp code, I'll try to boil it down to the minimal
required for my configuration to load.  My main startup file itself is
about 650 lines.  It also loads 400 lines of hooks and 2,000 lines of
other functions.  The other functions are almost certain to be
completely irrelevant.  My gnus configuration is also about 400 lines
not including mail splitting rules.  (If you were to map my brain, you
would find a large region dedicated to emacs.  I've been using it for
more than half my life.)

I'm also going to continue to search for some specific way to
reproduce this problem.

--Jay


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to