Spacemacs does not highlight trailing whitespace when started in daemon mode

[marienz]

Description :octocat:

Spacemacs does not highlight trailing whitespace when started in daemon mode

Reproduction guide :beetle:

• Make sure dotspacemacs-show-trailing-whitespace is t
• Start Emacs with --fg-daemon
• Open a file containing trailing whitespace

Observed behaviour: :eyes: :broken_heart: Trailing whitespace is not highlighted

Expected behaviour: :heart: :smile: Trailing whitespace is highlighted, like it is without --fg-daemon

System Info :computer:

• OS: gnu/linux
• Emacs: 27.1
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. 138d6329e)
• Graphic display: t
• Distribution: spacemacs
• Editing style: hybrid
• Completion: ivy
• Layers:

  (ivy
  (auto-completion :variables auto-completion-idle-delay nil)
  better-defaults
  (ibuffer :variables ibuffer-group-buffers-by nil)
  (keyboard-layout :variables kl-layout 'dvorak kl-enabled-configurations
                '(ace-window avy))
  c-c++ emacs-lisp
  (go :variables go-format-before-save t go-tab-width 4 go-backend 'lsp go-use-golangci-lint t)
  html
  (javascript :variables javascript-backend nil)
  typescript lua markdown nginx perl5 protobuf python rust shell-scripts sql systemd yaml git github
  (shell :variables shell-default-shell 'eshell shell-default-height 30 shell-default-position 'bottom)
  syntax-checking
  (version-control :variables version-control-diff-tool 'diff-hl)
  (lsp :variables lsp-rust-server 'rust-analyzer)
  dap)

• System configuration features: XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON PDUMPER GMP

Details

It looks like the problem is how Spacemacs overrides the background color of the trailing-whitespace face in spacemacs-defaults/init-whitespace to be the font-lock-comment-face foreground color. When I start Emacs with --fg-daemon, :background for trailing-whitespace ends up nil. I think that happens because the code runs too early, before Emacs has a frame that supports colors: face-attribute is getting the value for the current frame, which is probably nil if that frame doesn't support colors.

If I remove that bit of code from Spacemacs, trailing-whitespace works correctly.

In addition to not working with --fg-daemon, Spacemacs overrides my custom theme here, which I'd prefer it didn't (if this is fixed I may still try to override Spacemacs's override). Maybe it's sufficient to change trailing-whitespace only in Spacemacs' default theme, allowing other themes to customize it as they see fit?

[dalanicolai]

Have you restarted the server after setting dotspacemacs-show-trailing-whitespace to t? I can not reproduce this (i.e. works fine here)

[marienz]

Gah, I likely screwed something up when I was testing this before.

After some more testing: I'm getting a different trailing-whitespace face in frames after the first one. That is:

• Quit Emacs.
• Start Emacs with emacs --fg-daemon
• Open a frame with emacsclient -n -c
• C-x C-f and find a file with trailing whitespace. Observe it is highlighted. Alternatively, press SPC h d F trailing-whitespace RET (describe-face) and observe that "Background" is not "unspecified".
• Close the frame with C-x C-c
• Open a new frame with emacsclient -n -c
• Find the same file with trailing whitespace. Observe it is no longer highlighted. Alternatively, press SPC h d F trailing-whitespace RET and observe "Background" is now "unspecified".

Only the first frame works, the subsequent ones are bad.

I see the same thing if I don't close the original frame, just create a second one with SPC F n. That is: switching between the two frames and running SPC h d F trailing-whitespace RET produces different results depending on the frame I run it in. It's still good if I run it in the original frame.

I don't see the same problem if I start Emacs without --fg-daemon and create multiple frames (I also see a different background color, but that's possibly an unrelated bug).

I assume I screwed up my troubleshooting, but can't entirely rule out there's some other factor at work here I've missed. I did try this a few times and it seems to be reproducible (but I thought it was before, so yeah).

Can you (or someone else) see if they can reproduce it now? I'm happy to do some more troubleshooting on my end but it'd be useful to know if others can now reproduce. If not, I either still haven't found the actual trigger or it's something in my config (which I can bisect, but if it's reproducible for others I don't have to).

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!