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]