>OK, so please describe again, in as much detail as you can, what do >you do with Emacs between correct display and incorrect display. You >said you switch to another buffer and return, but could you tell more? >Just switching to another buffer and back immediately triggers that? >Or something else is needed? That is indeed the tough part. I have yet to find a definite repeatable pattern that induces the bug. But, I now usually arrive there in a few minutes of activity with two emacsclients -t in use. Switching back & forth immediately will not do it. At least one client is loading / unloading various files before switching back to other client. Take a look again at the original post for more of these general actions I use. On Wed, Sep 8, 2021 at 12:25 PM Eli Zaretskii wrote: > > From: RDS > > Date: Wed, 8 Sep 2021 12:21:09 -0700 > > Cc: larsi@gnus.org, 50462@debbugs.gnu.org > > > > >So it sounds like the faces lost their color definitions for some > > >reason? > > Yes. Something overwrote the setting returning it to default state = > black. > > > > >When this happens, and you invoke "M-x customize-face" on a > > >problematic face, what does Emacs show for the color attributes of the > > >face in the Customize buffer? > > black. > > I then entered green & voila, all was well. > > OK, so please describe again, in as much detail as you can, what do > you do with Emacs between correct display and incorrect display. You > said you switch to another buffer and return, but could you tell more? > Just switching to another buffer and back immediately triggers that? > Or something else is needed? >