-
-
Notifications
You must be signed in to change notification settings - Fork 65
Using degraded color (avoid using color name) #54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sorry for the late reply ⌚ Unfortunately I can not completely follow your description about the problem. The I'd be nice to have a step-by-step reproduction guide including a minimal config. Maybe add a |
Thank you for your patience! 🙏🏼 I recently published the first "Northern Post — The state and roadmap of Nord" announcement which includes all details about the plans and future of the Nord project, including the goal of catching up with the backlog. This issue is part of the backlog and therefore I want to triage and process it to get one step closer to a "clean state". Read the announcement about reaching the "clean" contribution triage state in Nord's discussions for more details about the goal. Therefore it has been added for triage in the central and single-source-of-truth project board that is also described in more detail in the roadmap announcement. @DVN196 Thanks again for your contribution 🚀 |
I use emacsclient on both terminal and gui and I use after-make-frame-functions to reload nord-theme when open a new frame to correct the color. But if I have a GUI frame opened and tried to open emacsclient on terminal, it will crash immediately because there are no definition for bright colors on emacs GUI. Can we use something similar to solarized's solarized-term-color to avoid using "bright*" color name?
The text was updated successfully, but these errors were encountered: