>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 <eliz@gnu.org> wrote:
> From: RDS <rds1944@gmail.com>
> 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?