bug#50462: 27.2; emacsclient syntax highlight failure

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1.1: Type: text/plain, Size: 5104 bytes --]

I have been using emacs-lucid as a server for a few months & encountered
repeated sporadic annoyances. What follows is somewhat vague because I
cannot give a precise repeatable sequence of operations which lead to the
particular fault. Nevertheless, what I describe has occurred on far too
instances. The machine is a Lenovo P15v Gen 1 with an i7 8c/16t CPU using
Intel UHD graphics. I have Slackware-current on one partition & Fedore 34
on another. While this report is from the former, the *identical* results
happen on the Fedora machine. Furthermore, it makes *no* difference whether
it runs in console or xterm.

Launch emacs as a server. A buffer has a bash or elisp script with
font-lock-mode enabled (syntax highlighting). It looks just fine. Then, I
switch to another buffer & when I return, part of the file is not visible.
Close inspection shows that only text encoded as strings is rendered
black-on-black or white-on-white. Disabling font-lock-mode shows nothing is
missing! Again enabling font-lock-mode & the same text is missing. Killing
the buffer & reloading does not fix the problem. At this point opening any
new bash or elisp file with strings is futile. The only way to correct all
is a restart of the daemon! Of course, any setup of screens / consoles is
lost. However, no data is ever lost or damaged.

Here is the general scenario

tty1> launch a server
emacs --daemon
or
emacs --fg-daemon
or
emacs  M-x server mode

tty2> run Midnight Commander
mc
navigate -> .bashrc (for example)
emacsclient -t .bashrc

tty3>
mc
navigate -> file1
emacsclient -t file1
navigate -> file2
emacsclient -t file2
.
.
.

Initially everything behaves as expected in console & X. Then on time
scales ranging from minutes to hours with the various emacsclients,
randomly switching among tty's & killing / loading buffers, I eventually
see that .bashrc is displayed with "missing" chars.

Attached are two screenshots (before & after failure) of my .bashrc from an
xterm.


In GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll
bars)
 of 2021-03-26 built on p15v.rr.net
System Description: Slackware 15.0 x86_64

Recent messages:
Loading smtpmail...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/man
 --infodir=/usr/info --localstatedir=/var --with-x
 --with-x-toolkit=lucid --with-mailutils --without-selinux --without-xim
 --without-libsystemd --disable-acl 'CFLAGS=-O2 -fPIC''

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY GNUTLS LIBXML2 FREETYPE HARFBUZZ XFT ZLIB TOOLKIT_SCROLL_BARS
LUCID X11 XDBE XIM MODULES THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  gpm-mouse-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
easymenu mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader dired dired-loaddefs t-mouse
term/linux derived edmacro kmacro paren smtpmail auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs cl-loaddefs cl-lib
password-cache json subr-x map seq byte-opt gv bytecomp byte-compile
cconv sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 53706 9734)
 (symbols 48 6947 1)
 (strings 32 18362 889)
 (string-bytes 1 604547)
 (vectors 16 9632)
 (vector-slots 8 108586 7664)
 (floats 8 20 299)
 (intervals 56 375 0)
 (buffers 1000 12))

[-- Attachment #1.2: Type: text/html, Size: 5699 bytes --]

[-- Attachment #2: emacsclient.0.jpg --]
[-- Type: image/jpeg, Size: 311791 bytes --]

[-- Attachment #3: emacsclient.1.jpg --]
[-- Type: image/jpeg, Size: 129005 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

> From: RDS <rds1944@gmail.com>
> Date: Tue, 7 Sep 2021 11:11:20 -0700
> 
> Initially everything behaves as expected in console & X. Then on time scales ranging from minutes to hours
> with the various emacsclients, randomly switching among tty's & killing / loading buffers, I eventually see
> that .bashrc is displayed with "missing" chars.

Are they really missing, or just displayed with the same foreground
and background colors?  What happens if you move the cursor (with C-f
or C-b) across the "missing" text?

Also, do you see any error messages in the *Messages* buffer when this
happens?

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

[Please use Reply All to keep the bug address on the CC list.]

> From: RDS <rds1944@gmail.com>
> Date: Tue, 7 Sep 2021 12:51:16 -0700
> 
> Eli
> 
> Read further into my bug post:
> 
> "Launch emacs as a server. A buffer has a bash or elisp script with font-lock-mode enabled (syntax
> highlighting). It looks just fine. Then, I switch to another buffer & when I return, part of the file is not visible.
> Close inspection shows that only text encoded as strings is rendered black-on-black or
> white-on-white. Disabling font-lock-mode shows nothing is missing! Again enabling font-lock-mode &
> the same text is missing. Killing the buffer & reloading does not fix the problem. At this point opening any new
> bash or elisp file with strings is futile. The only way to correct all is a restart of the daemon! Of course, any
> setup of screens / consoles is lost. However, no data is ever lost or damaged."
> 
> And yes, C-f, C-b are fine. ALL is fine except for string highlight! (.c are ok, org mode are ok, ...)
> 
> Nothing unusual in *Messages*.
> 
> Weird!

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?

bug#50462: 27.2; emacsclient syntax highlight failure

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> "Launch emacs as a server. A buffer has a bash or elisp script with
>> font-lock-mode enabled (syntax
>> highlighting). It looks just fine. Then, I switch to another buffer
>> & when I return, part of the file is not visible.

Is this with a terminal Emacs or a GUI Emacs?

> 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?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: RDS <rds1944@gmail.com>,  50462@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.

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

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@gnu.org> wrote:

> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: RDS <rds1944@gmail.com>,  50462@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.
>

[-- Attachment #2: Type: text/html, Size: 2430 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

>terminal Emacs

Sorry, I read wrong. This is using emacsclient -t (terminal emacs).


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

> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: RDS <rds1944@gmail.com>,  50462@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.
>

[-- Attachment #2: Type: text/html, Size: 1580 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

> From: RDS <rds1944@gmail.com>
> Date: Wed, 8 Sep 2021 09:46:38 -0700
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50462@debbugs.gnu.org
> 
> 1) Using standard agetty, not emacs terminal.

I'm not sure I understand what this means.  What is "agetty"?  And
what do you call "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 "

And what happens if you try to customize these faces to define the
colors they should have?  Or different colors?  Does that work, or do
these faces fail to display any colors, no matter what?

Btw, how many colors does this terminal support?  You can find the
answer like this:

  M-: (display-color-cells) RET

And finally, does "M-x list-colors-display RET" show some colors
incorrectly?

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

>I'm not sure I understand what this means.  What is "agetty"?
Linux console login utility.

> And what do you call "emacs terminal"?
emacsclient -t (terminal mode) as noted in original post. Not -c option.

>M-: (display-color-cells) RET
8 : console
256 : xterm

>And what happens if you try to customize these faces to define the
>colors they should have?
It works! Tried it from the menu bar.




On Wed, Sep 8, 2021 at 10:02 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: RDS <rds1944@gmail.com>
> > Date: Wed, 8 Sep 2021 09:46:38 -0700
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50462@debbugs.gnu.org
> >
> > 1) Using standard agetty, not emacs terminal.
>
> I'm not sure I understand what this means.  What is "agetty"?  And
> what do you call "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 "
>
> And what happens if you try to customize these faces to define the
> colors they should have?  Or different colors?  Does that work, or do
> these faces fail to display any colors, no matter what?
>
> Btw, how many colors does this terminal support?  You can find the
> answer like this:
>
>   M-: (display-color-cells) RET
>
> And finally, does "M-x list-colors-display RET" show some colors
> incorrectly?
>

[-- Attachment #2: Type: text/html, Size: 2918 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

>And finally, does "M-x list-colors-display RET" show some colors
>incorrectly?
It's all there as expected.


On Wed, Sep 8, 2021 at 10:02 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: RDS <rds1944@gmail.com>
> > Date: Wed, 8 Sep 2021 09:46:38 -0700
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50462@debbugs.gnu.org
> >
> > 1) Using standard agetty, not emacs terminal.
>
> I'm not sure I understand what this means.  What is "agetty"?  And
> what do you call "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 "
>
> And what happens if you try to customize these faces to define the
> colors they should have?  Or different colors?  Does that work, or do
> these faces fail to display any colors, no matter what?
>
> Btw, how many colors does this terminal support?  You can find the
> answer like this:
>
>   M-: (display-color-cells) RET
>
> And finally, does "M-x list-colors-display RET" show some colors
> incorrectly?
>

[-- Attachment #2: Type: text/html, Size: 1914 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

> From: RDS <rds1944@gmail.com>
> Date: Wed, 8 Sep 2021 10:28:01 -0700
> Cc: larsi@gnus.org, 50462@debbugs.gnu.org
> 
> >M-: (display-color-cells) RET
> 8 : console
> 256 : xterm
> 
> >And what happens if you try to customize these faces to define the
> >colors they should have?
> It works! Tried it from the menu bar.

So it sounds like the faces lost their color definitions for some
reason?

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?

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]

>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.







On Wed, Sep 8, 2021 at 10:02 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: RDS <rds1944@gmail.com>
> > Date: Wed, 8 Sep 2021 09:46:38 -0700
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50462@debbugs.gnu.org
> >
> > 1) Using standard agetty, not emacs terminal.
>
> I'm not sure I understand what this means.  What is "agetty"?  And
> what do you call "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 "
>
> And what happens if you try to customize these faces to define the
> colors they should have?  Or different colors?  Does that work, or do
> these faces fail to display any colors, no matter what?
>
> Btw, how many colors does this terminal support?  You can find the
> answer like this:
>
>   M-: (display-color-cells) RET
>
> And finally, does "M-x list-colors-display RET" show some colors
> incorrectly?
>

[-- Attachment #2: Type: text/html, Size: 2335 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

> 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?

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

>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?
>

[-- Attachment #2: Type: text/html, Size: 2735 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

> From: RDS <rds1944@gmail.com>
> Date: Wed, 8 Sep 2021 13:05:59 -0700
> Cc: larsi@gnus.org, 50462@debbugs.gnu.org
> 
> >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.

So two frames from two separate emacsclients are always involved?  And
you need to switch from one client to another and back?

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

>So two frames from two separate emacsclients are always involved?  And
>you need to switch from one client to another and back?
Two tty's & emacsclients or more are used:
(In X org, I open 2 workspaces. Each has an xterm.)
tty1> emacsclient -t /home/rds (showing dired)
visit .bashrc (it has lots of strings from aliases)
switch to tty2
tty2> mc (run Midnight Commander)
edit .Xesources ($EDITOR=emacsclient -t)
It looks fine.
switch to tty1.
.bashrc looks OK.
switch to tty2
edit more files in my tree randomly with emacsclient.
switch to tty1. All OK? yes. back to tty2.
keep repeating this cycle. Eventually, tty1 will lose its string display.










On Wed, Sep 8, 2021 at 1:17 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: RDS <rds1944@gmail.com>
> > Date: Wed, 8 Sep 2021 13:05:59 -0700
> > Cc: larsi@gnus.org, 50462@debbugs.gnu.org
> >
> > >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.
>
> So two frames from two separate emacsclients are always involved?  And
> you need to switch from one client to another and back?
>

[-- Attachment #2: Type: text/html, Size: 3729 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

> From: RDS <rds1944@gmail.com>
> Date: Wed, 8 Sep 2021 13:32:46 -0700
> Cc: larsi@gnus.org, 50462@debbugs.gnu.org
> 
> >So two frames from two separate emacsclients are always involved?  And
> >you need to switch from one client to another and back?
> Two tty's & emacsclients or more are used:
> (In X org, I open 2 workspaces. Each has an xterm.)
> tty1> emacsclient -t /home/rds (showing dired)
> visit .bashrc (it has lots of strings from aliases)
> switch to tty2
> tty2> mc (run Midnight Commander)
> edit .Xesources ($EDITOR=emacsclient -t)
> It looks fine.
> switch to tty1.
> .bashrc looks OK.
> switch to tty2
> edit more files in my tree randomly with emacsclient.
> switch to tty1. All OK? yes. back to tty2.
> keep repeating this cycle. Eventually, tty1 will lose its string display.

It's strange that only some faces get redefined to use different
colors.  Are all the problematic faces using the same foreground
color, and if so, what is that color on those terminals you are using?

bug#50462: 27.2; emacsclient syntax highlight failure

[Lars Ingebrigtsen]

RDS <rds1944@gmail.com> writes:

> 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 "

Hm...  you don't happen to have any packages installed that alters these
faces, by any chance?  (Grep your .el files for `font-lock-string-face',
for instance.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50462: 27.2; emacsclient syntax highlight failure

[RDS]

[-- Attachment #1: Type: text/plain, Size: 756 bytes --]

Very astute!!!

Found this in my init.el

      (set-face-attribute 'font-lock-string-face nil :foreground "black")

Thanks.


On Thu, Sep 9, 2021 at 6:56 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> RDS <rds1944@gmail.com> writes:
>
> > 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 "
>
> Hm...  you don't happen to have any packages installed that alters these
> faces, by any chance?  (Grep your .el files for `font-lock-string-face',
> for instance.)
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[-- Attachment #2: Type: text/html, Size: 1767 bytes --]

bug#50462: 27.2; emacsclient syntax highlight failure

[Lars Ingebrigtsen]

RDS <rds1944@gmail.com> writes:

> Found this in my init.el
>
>       (set-face-attribute 'font-lock-string-face nil :foreground "black")

:-)

I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50462: 27.2; emacsclient syntax highlight failure

[Eli Zaretskii]

> From: RDS <rds1944@gmail.com>
> Date: Thu, 9 Sep 2021 11:56:12 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, 50462@debbugs.gnu.org
> 
> Very astute!!!
> 
> Found this in my init.el
> 
>       (set-face-attribute 'font-lock-string-face nil :foreground "black")

Thanks, I'm therefore closing this bug.