emacs icon indicating copy to clipboard operation
emacs copied to clipboard

Weird terminal color in version 1.7

Open feng-li opened this issue 4 years ago • 20 comments

I was thrilled with 1.51 version of the emacs theme, both under the gnome-terminal (xterm-256 color) and GTK3. Then I updated to 1.7, the color looks a bit weird. See the attached screenshot with the start_emacs_test.sh.

top left: version 1.51, gnome-terminal 256 color; 
top right: version 1.7, gnome terminal 256 color (the weird version); 
bottomleft: version 1.51, GTK3;  
bottom right: version 1.7, GTK3  

Screenshot from 2020-03-23 17-04-47 Anything I am missing?

feng-li avatar Mar 23 '20 09:03 feng-li

Hi!

I think there are two problems here.

  1. it seems that your terminal is configured to display white colors as orange. I don't use gnome-terminal, thus I cannot help more there, but this orange tone comes from your terminal.
  2. the grey-ish tone of the comment are the new colors setting of the dracula theme for terminal. I must admit I force the terminal color even for 256-color capable terms. I'll push an update to only use them on 255 and less capable terms.

milouse avatar Mar 23 '20 10:03 milouse

In fact, I correct myself. After a quick review, I didn't do anything wrong. The new 256 colors variant of the dracula theme is right. The fact is that your terminal support more than 256 colors, but advertize itself as a 256 colors capable one is the problem.

However, you're right that a lot of them are doing so in the wild. Thus, as I've add a setting system to the theme, I'll add one to force 24bit colors even for 256 colors terms if necessary.

milouse avatar Mar 23 '20 10:03 milouse

Can you test my latest commit? You should put the following line in your emacs init file before loading the theme:

(setq dracula-use-24-bit-colors-on-256-colors-terms t)

milouse avatar Mar 23 '20 13:03 milouse

Can you test my latest commit? You should put the following line in your emacs init file before loading the theme:

(setq dracula-use-24-bit-colors-on-256-colors-terms t)

Many thanks. Now within the terminal, the foreground color seems right. But the background is blue. Screenshot from 2020-03-24 09-09-35

BTW, the terminal color scheme I am using is Dracula . It does mark white as orange (#EFA554) in the palette. Screenshot from 2020-03-24 09-12-37

feng-li avatar Mar 24 '20 01:03 feng-li

So, I'm happy to see that you just have the exact same behavior than #2 #19 #20 #32 #57 … We have long history of tests on this one. That's why we take the decision to support a specific 256 colors theme to work around terminals limitations.

So if you really really really want to use risky colors not fully understood by your terminal, you can keep the new setting I created above, and, in order to avoid the blue background, you should set a specific color for the background, after having load the dracula theme. Something like :

(unless (display-graphic-p)
  (set-face-background 'default "black" nil))

This will force the background to black only for terminals. I let you discover which color is better for you. Some people reported that nil was better than "black".

BTW, the terminal color scheme I am using is Dracula . It does mark white as orange (#EFA554) in the palette.

So, nothing I can do for you here. Please see with them why they put orange on white.

milouse avatar Mar 24 '20 16:03 milouse

Same issue here after upgraded to the latest version. I am using macOS and its Terminal. Changing TERM=xterm-16color or TERM=xterm-88color can fix.

kwunlyou avatar Mar 24 '20 22:03 kwunlyou

Thank you for the update.

feng-li avatar Mar 25 '20 01:03 feng-li

Same issue here after upgraded to the latest version. I am using macOS and its Terminal. Changing TERM=xterm-16color or TERM=xterm-88color can fix.

What issue are you refering to @kwunlyou ? The blue screen or the grey-ish colors? Have you a problem with or without the (now hidden) dracula-use-24-bit-colors-on-256-colors-terms preference?

In none of these situation you should lower your terminal capacities… Maybe you can send a screenshot of the « issue » you have before any new customization? Can you tell us the result of the following command (before your changes obviously):

echo $TERM

Thank you very much

milouse avatar Mar 25 '20 11:03 milouse

Hi @feng-li I just found out a new 256-color palette for dracula, which tends to better respect the blue-ish aspect, even on terminal. If you have time, I would appreciate your comments on this new test : https://raw.githubusercontent.com/dracula/emacs/new-256/dracula-theme.el

Here is how it looks like for me:

Capture du 2020-04-04 16-21-26

Thank you very much!

milouse avatar Apr 04 '20 14:04 milouse

Thank you for your work. I just tried your proposal. I think the foreground and other faces are all fine by setting $TERM as xterm, xterm-16color, xterm-88color, xterm-256color, and screen, except the background was not effective, which is exactly the same as my terminal color (#000000).

I did some investigation as well. I notice that the Dracula background "#282a36" was not properly displayed with Emacs. When Emacs could not find the exact color "#282a36", it looks for the closest one that it could find, and it either takes blue as the closest one or does nothing. Setting

(unless (display-graphic-p)                                                                                 
      (set-face-background 'default  "black" nil))      

is not practical neither. Because when emacs is running on daemon mode and you want to start a GUI client, that will make the background a real "black". I suggest making this setting color as "#292929" or "#2b2b2b".

from left to right:

  1. terminal with your default color
  2. terminal with but (set-face-background 'default "#292929" nil)
  3. terminal with but (set-face-background 'default "#2b2b2b" nil)
  4. GTK with your default color

Hope that could help.

Screenshot from 2020-04-04 23-38-28

feng-li avatar Apr 04 '20 15:04 feng-li

#292929 and #2b2b2b are not available in the X11 256 colors palette (used by terminals). Only #262626 is available. It was the previous chosen background color, which I replace by nil (thus, normally it should take the terminal background). I may revert it to #262626 if it's better than black or nil. What do you think?

milouse avatar Apr 04 '20 16:04 milouse

I think you cannot make it nil. Emacs Lisp (26.3) would complain that it could not find color nil. Otherwise, any color is doable.

feng-li avatar Apr 05 '20 08:04 feng-li

You're right. It seems that we must use "unspecified-fg"/"unspecified-bg" instead, since at least 2012: emacs-mirror/emacs@bccffa83747

That way, color won't be handled by emacs, relying on the support to draw it. It'll works fine on TTY. The only drawback may be on terminals, which have a light default background. But I think it's easy to ask people to adjust their terminal background?

milouse avatar Apr 10 '20 09:04 milouse

That's a fair solution.

feng-li avatar Apr 11 '20 01:04 feng-li

Ok, I'll go for it

milouse avatar Apr 12 '20 11:04 milouse

Just commenting here, I am using Emacs on Mac OSX and since this change I am getting: Unable to load color "unspecified-fg" Using: GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.2.0, NS appkit-1671.20 Version 10.14.3 (Build 18D109)) of 2019-09-02from https://emacsformacosx.com/

Also, after this change region is black on gray so it is hard to read (there might be something else involved). It looks like the "inherit" on "match" is not working.

mfcabrera avatar Jun 02 '20 19:06 mfcabrera

Very strange… can you do a M-x describe-function and enter color-defined-p and copy/paste here the result of the doc? It should speak about unspecified-fg/-bg.

In any case, can you add (setq debug-on-error t) to your init file and copy paste the complete stack trace of your error? Thank you very much.

milouse avatar Jun 03 '20 19:06 milouse

(Note for myself) I should investigate on bbatsov/solarized-emacs#18 too.

milouse avatar Jun 09 '20 08:06 milouse

@milouse thanks for your reply.

Very strange… can you do a M-x describe-function and enter color-defined-p and copy/paste here the result of the doc? It should speak about unspecified-fg/-bg.

In any case, can you add (setq debug-on-error t) to your init file and copy paste the complete stack trace of your error? Thank you very much.

color-defined-p is a compiled Lisp function in ‘faces.el’.

(color-defined-p COLOR &optional FRAME)

Return non-nil if COLOR is supported on frame FRAME.
COLOR should be a string naming a color (e.g. "white"), or a
string specifying a color’s RGB components (e.g. "#ff12ec"), or
the symbol ‘unspecified’.

This function returns nil if COLOR is the symbol ‘unspecified’,
or one of the strings "unspecified-fg" or "unspecified-bg".

If FRAME is omitted or nil, use the selected frame.

I set up (setq debug-on-error t) I don't set any errors.

In order to fix it I had to manually modify the theme definition like this:

--- dracula-theme.el	2020-06-09 10:41:48.000000000 +0200
+++ dracula-theme.el.modified	2020-06-09 10:46:47.000000000 +0200
@@ -78,7 +78,7 @@

 ;; Assigment form: VARIABLE COLOR [256-COLOR [TTY-COLOR]]
 (let ((colors '(;; Upstream theme color
-                (dracula-bg      "#282a36" "unspecified-bg" "unspecified-bg") ; official background
+                (dracula-bg      "#282a36" nil nil) ; official background
                 (dracula-fg      "#f8f8f2" "#ffffff" "brightwhite") ; official foreground
                 (dracula-current "#44475a" "#303030" "brightblack") ; official current-line/selection
                 (dracula-comment "#6272a4" "#5f5faf" "blue")        ; official comment
@@ -118,8 +118,8 @@
                       (list :weight 'normal :foreground dracula-fg)
                     (list :weight 'bold :foreground dracula-pink)))
                (read-multiple-choice-face :inherit completions-first-difference)
-               (region :inherit match :extend t)
-               (trailing-whitespace :foreground "unspecified-fg" :background ,dracula-orange)
+               (region :background ,dracula-yellow :foreground ,dracula-bg)
+               (trailing-whitespace :foreground nil :background ,dracula-orange)
                (vertical-border :foreground ,bg2)
                (success :foreground ,dracula-green)
                (warning :foreground ,dracula-orange)
@@ -296,7 +296,7 @@
                (helm-grep-file :foreground ,dracula-fg :background ,dracula-bg)
                (helm-grep-finish :foreground ,fg2 :background ,dracula-bg)
                (helm-grep-lineno :foreground ,dracula-fg :background ,dracula-bg)
-               (helm-grep-match :foreground "unspecified-fg" :background "unspecified-bg" :inherit helm-match)
+               (helm-grep-match :foreground nil :background nil :inherit helm-match)
                (helm-grep-running :foreground ,dracula-green :background ,dracula-bg)
                (helm-header :foreground ,fg2 :background ,dracula-bg :underline nil :box nil)
                (helm-moccur-buffer :foreground ,dracula-green :background ,dracula-bg)
@@ -483,7 +483,7 @@
                           :box ,dracula-current :inverse-video nil
                           ,@(if dracula-alternate-mode-line-and-minibuffer
                                 (list :foreground fg3)
-                              (list :foreground "unspecified-fg")))
+                              (list :foreground nil)))
                (mode-line-inactive
                 :inverse-video nil
                 ,@(if dracula-alternate-mode-line-and-minibuffer

This is how the active mark looks without modifying the theme

grafik

mfcabrera avatar Jun 09 '20 08:06 mfcabrera

@mfcabrera your fix also worked for me.

wmealing avatar Aug 25 '21 06:08 wmealing