Emacs lisp docstring too dark in doom-molokai theme

[benfrankel]

It looks like this, on line 108:

It's even worse when flycheck highlights it with a warning:

The text becomes readable when it's in a marked region, however.

[benfrankel]

Along the same lines, I noticed that text becomes black on black in helm find files when simultaneously marked and active.

Before (Makefile is active and unmarked):

After (log is active and marked):

[benfrankel]

It seems that the docstring issue is resolved for me when I run emacs not as a daemon, for some reason:

I'm not sure what the cause for that is.

The second issue is still there, in either case.

[hlissner]

I've pushed fixes for these issues. Let me know if they persist.

[benfrankel]

The second issue is solved, but the first one hasn't changed. It's still unreadable in daemon emacs but ok in non-daemon emacs. This may just be an issue on my side. Do you get the same behavior?

[hlissner]

Yes, I could reproduce it, and I've found the culprit. It had to do with terminal-emacs translating the 24-bit color of font-lock-doc-face to an 8-bit color (for the terminal) incorrectly. A slight change nudged it in the right direction. It should be fixed now.

[hlissner]

The more I tussle with this issue, the more it seems to not be doom-themes' fault.

There are four workflow scenarios with Emacs:

1. You start GUI Emacs and use it: emacs
2. You start terminal emacs and use it: emacs -nw
3. From GUI Emacs you start a server with (server-start), then:
   a. Open a GUI frame with emacsclient -c
   b. Or open a tty frame with emacsclient -nw
4. You spawn an emacs daemon (emacs --daemon) and:
   a. Open a GUI frame with emacsclient -c
   b. Or open a tty frame with emacsclient -nw

What I've discovered is scenarios 1, 2 and 3a/3b work just fine with doom-themes, but 4a/4b do not.

In 4a/4b new frames seem to forget whether they are tty or a GUI frames, confusing Emacs' theme display engine and causing it to treat all frames as tty frames. Thus, you get 8-bit colors in GUI frames (some 24-bit colors bleed through because I specify no 8-bit fallbacks for them). This is what causes the problems you're seeing.

TL;DR to fix this I had to add something like this to my emacs.d:

(defun my-init-theme (&optional _frame)
  (load-theme 'doom-one t))

(defun my-reload-theme-in-daemon (frame)
  (when (or (daemonp) (not (display-graphic-p)))
    (with-selected-frame frame
      (run-with-timer 0.1 nil #'my-init-theme))))

(add-hook 'after-make-frame-functions #'my-init-theme)
(add-hook 'after-make-frame-functions #'my-reload-theme-in-daemon)

;; for GUI sessions
(my-init-theme)

What it does is forcibly reload the theme when a new frame is created from a daemon or in the terminal. It isn't ideal, but it works.

Give that snippet a try and see if that fixes the problem.

[benfrankel]

Ah, that does it. Thank you so much! 👍

Note: Any settings that override doom-theme's settings must be put in my-init-theme after (load-theme 'doom-xxx t) in order for them to take effect. I put some linum-related settings in there.

[dmille]

For anyone like myself who's been dealing with this issue, and falls under workflow scenario 4a like myself, I finally found a solution which addresses the load-on-every-frame issue by using the solution from this comment. I hope this helps someone. I, for one, can now sleep at night.