GNU bug report logs - #50462
27.2; emacsclient syntax highlight failure

Previous Next

Full log

Message #20 received at 50462 <at> debbugs.gnu.org (full text, mbox):

From: RDS <rds1944 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50462 <at> debbugs.gnu.org
Subject: Re: bug#50462: 27.2; emacsclient syntax highlight failure
Date: Wed, 8 Sep 2021 09:46:38 -0700

[Message part 1 (text/plain, inline)]

1) Using standard agetty, not emacs terminal.

2) M-x list-faces-display (after fault)
All OK *except*
  font-lock-string-face (black-on-black)
  sh-escaped-newline "
  toolbar "
  window-divider-last-pixel "

Expected this, of course. Note that once the fault occurs, it is permanent
(until the daemon restarted.). Any new files loaded into buffers exhibit
the same loss of string highlight.




On Wed, Sep 8, 2021 at 12:51 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Cc: RDS <rds1944 <at> gmail.com>,  50462 <at> debbugs.gnu.org
> > Date: Wed, 08 Sep 2021 08:54:11 +0200
> >
> > > So it sounds like the faces lost their colors or something.  When the
> > > problem happens, what does "M-x list-faces-display RET" show for the
> > > font-lock faces: do they appear in their normal colors?
> >
> > If this is with a terminal Emacs, could this be related to the face
> > terminal bug you fixed the other day in Emacs 28?
>
> Unlikely: AFAIU, that bug only appeared once we switched to storing
> faces in a hash-table, and only when clone-frame was calling that
> code.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.