Skip to content
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

Colors #58

Closed
Sbozzolo opened this issue Jan 13, 2019 · 29 comments
Closed

Colors #58

Sbozzolo opened this issue Jan 13, 2019 · 29 comments

Comments

@Sbozzolo
Copy link
Collaborator

Sbozzolo commented Jan 13, 2019

The following screenshot is how ansi-term (top left) with eterm-256colors, vterm (top right) and xterm look like on my machine.

2019-01-12 17 59 16

Also comparing other programs, e.g. htop, it seems that vterm produces output only with (probably) 8 colors.
However, tput colors reports the number 256, and also other scripts to print the complete palette successfully show all the colors.

(I am using zsh, if it's relevant)

Why is that?

@akermu
Copy link
Owner

akermu commented Jan 27, 2019

Might be because we set $TERM to xterm instead of xterm-256color here. Can you modify vterm.el and try it out?

In general emacs-libvterm supports 256 colors.

@Sbozzolo
Copy link
Collaborator Author

Nothing changes when I set xterm-256color instead of xterm. Also, my xterm sets TERM to xterm.

@akermu
Copy link
Owner

akermu commented Jan 27, 2019

Mhm currently the module should break, if you encounter a color from the 256 palette. The issue above might be related to the ansi-colors, where you can define 8 normal colors and 8 high intensity colors. The module currently don't differentiate between them, so this might lead to the differences in the output above.

@akermu
Copy link
Owner

akermu commented Jan 28, 2019

So I fixed a lot regarding color handling in 920d847. Does your issue still persist?

@Sbozzolo
Copy link
Collaborator Author

Sbozzolo commented Jan 28, 2019

I pulled, recompiled, restarted emacs. This is what I see now:

2019-01-28 16 41 42

Not only the issue persists, but not also the background is messed up.

@akermu
Copy link
Owner

akermu commented Jan 29, 2019

Did you adjust your color configuration according to the changes? There are new variables.

@Sbozzolo
Copy link
Collaborator Author

No, I wasn't setting those variables before, nor I was expecting that I had to set them. Shouldn't they default to the values the theme sets?

@akermu
Copy link
Owner

akermu commented Jan 29, 2019

Themes have to support each package individually, if they define their own faces (Have a look at zenburn.

Anyway with 976c3f2, I think I finally nailed color handling. No more faces, and your themes color theme should be picked up automatically :)

@Sbozzolo
Copy link
Collaborator Author

This is what I see now:
2019-01-29 15 44 04

It seems much better, but the background is still off.
I'm using solarized, which sets ansi-color-vector-names and ansi-color-vector-faces.

(Thanks for your amazing work, by the way!)

@akermu
Copy link
Owner

akermu commented Jan 30, 2019

Thanks :) What's the value of ansi-color-vector-names? For me it seems to work:

image

@Sbozzolo
Copy link
Collaborator Author

This is what I have in the .el file:

(ansi-color-names-vector (vector ,normal ,red ,green ,yellow ,blue ,magenta ,cyan ,background))

where:

;; name     sRGB      Gen RGB   256       16              8
(base03  (if srgb "#002b36" "#042028")) ; (0.0159 0.1265 0.1597)
(base02  (if srgb "#073642" "#0a2832")) ; (0.0394 0.1601 0.1983)
(base01  (if srgb "#586e75" "#465a61")) ; (0.2767 0.3567 0.3830)
(base00  (if srgb "#657b83" "#52676f")) ; (0.3244 0.4072 0.4385)
(base0   (if srgb "#839496" "#708183")) ; (0.4406 0.5096 0.5169)
(base1   (if srgb "#93a1a1" "#81908f")) ; (0.5060 0.5649 0.5636)
(base2   (if srgb "#eee8d5" "#e9e2cb")) ; (0.9161 0.8900 0.7978)
(base3   (if srgb "#fdf6e3" "#fcf4dc")) ; (0.9894 0.9579 0.8641)
(yellow  (if srgb "#b58900" "#a57705")) ; (0.6475 0.4675 0.0235)
(orange  (if srgb "#cb4b16" "#bd3612")) ; (0.7418 0.2133 0.0735)
(red     (if srgb "#dc322f" "#c60007")) ; (0.7770 0.0000 0.0290)
(magenta (if srgb "#d33682" "#c61b6e")) ; (0.7774 0.1080 0.4352)
(violet  (if srgb "#6c71c4" "#5859b7")) ; (0.3479 0.3514 0.7179)
(blue    (if srgb "#268bd2" "#2075c7")) ; (0.1275 0.4627 0.7823)
(cyan    (if srgb "#2aa198" "#259185")) ; (0.1468 0.5708 0.5250)
(green   (if srgb "#859900" "#728a05")) ; (0.4498 0.5412 0.0202)
(foregrounds (list base1 base0 base00 base01))
(backgrounds (list base03 base02))

And I believe it is also relevant to point out that normal and background are set as:

(background (nth 0 backgrounds))
(normal (nth 1 foregrounds))

You can have a look at the whole file here.

@suonlight
Copy link
Contributor

Themes have to support each package individually, if they define their own faces (Have a look at zenburn.

Anyway with 976c3f2, I think I finally nailed color handling. No more faces, and your themes color theme should be picked up automatically :)

It does not work for me. I'm using doom-nord.

screenshot 2019-01-30 23 49 42

@deadtrickster
Copy link

TBH I'm greatly confused after moving to 'ansi-color-names-vector - seems like custom backgrounds aren't supported anymore?

@Bee-Mar
Copy link

Bee-Mar commented Mar 12, 2019

I've been attempting to fix the colors on my theme as well. Some of them don't appear to be getting picked up. Also, setting the faces, mentioned on the README, doesn't seem to have any affect whatsoever.

This is how htop should be rendering the colors, when run within gnome-terminal:

bpm@AMD:~_003

This is how htop renders the colors within vterm inside Emacs:

term bpm@AMD:~-2-_004

The extra colors that would normally be used to indicate the CPU and RAM usage are being picked up as black, rather than gray (it might be hard to initially tell what's missing from the second photo). It's definitely not a deal breaker, but it's not working correctly.

Changing the ansi-color-names-vector seems to be the only thing that works.

This is currently what I have:

'(ansi-color-names-vector
   ["#000000" "red" "#00FF00" "yellow" "#003CFF" "#FF00FF" "#00FFFF" "#FFFFFF"])

Edit:

Also, i happened to open up emacs inside of terminal, and ran htop within, and it picked up all the colors correctly. This isn't me saying "huh, I wonder why that happened", but more of an observation.

@jixiuf jixiuf mentioned this issue Apr 23, 2019
@akermu
Copy link
Owner

akermu commented Jul 30, 2019

@Sbozzolo @Bee-Mar Could you please recheck, now that #82 is merged?

@Sbozzolo
Copy link
Collaborator Author

My comments in #82 still apply. It's a massive improvement, but there are still minor problems, the biggest one being that autosuggestions provided by my shell are not readable as they are rendered with the wrong color. However, I want to stress that #82 made the difference for me, effectively making the package usable as a daily driver. What is left to be fixed are smaller details

@akermu
Copy link
Owner

akermu commented Jul 31, 2019

Could you please post the settings for your terminal, where the colors are working as expected? Thanks!

@Sbozzolo
Copy link
Collaborator Author

I am attaching my Xresources, which powers my xterm.

Alternatively, I use eterm-256color, and ansi-term.

I use the color-theme-sanityinc-solarized theme.

Xresources.txt

@akermu
Copy link
Owner

akermu commented Jul 31, 2019

So if you ran this code:

(set-face-attribute 'vterm-color-default nil :foreground "#839496" :background "#002b36")
(set-face-attribute 'vterm-color-black nil :foreground "#073642" :background "#002b36")
(set-face-attribute 'vterm-color-red nil :foreground "#dc322f" :background "#cb4b16")
(set-face-attribute 'vterm-color-green nil :foreground "#859900" :background "#586e75")
(set-face-attribute 'vterm-color-yellow nil :foreground "#b58900" :background "#657b83")
(set-face-attribute 'vterm-color-blue nil :foreground "#268bd2" :background "#839496")
(set-face-attribute 'vterm-color-magenta nil :foreground "#d33682" :background "#6c71c4")
(set-face-attribute 'vterm-color-cyan nil :foreground "#2aa198" :background "#93a1a1")
(set-face-attribute 'vterm-color-white nil :foreground "#eee8d5" :background "#fdf6e3")

the colors are still not correct?

@Sbozzolo
Copy link
Collaborator Author

Exactly, the colors are still not correct. I mean, the problem with the autosuggestion is still there.

@akermu
Copy link
Owner

akermu commented Jul 31, 2019

How do you get those autosuggestions? With zsh-autosuggestions or do you use the fish shell? And if you use the first one, have you set ZSH_AUTOSUGGEST_HIGHLIGHT_STYLE anywhere?

@Sbozzolo
Copy link
Collaborator Author

I use zsh-autosuggestions with no custom configuration at all.

Thanks for looking into this

@akermu
Copy link
Owner

akermu commented Jul 31, 2019

Okay by default it chooses the black light variant for the autosuggestion, see https://github.com/zsh-users/zsh-autosuggestions/blob/43f3bc4010b2c697d2252fdd8b36a577ea125881/src/config.zsh#L10. So this is equivalent the :background attribute of vterm-color-black. Could you please set this face attribute to different values and look if the rendered autosuggestion is affected?

@Sbozzolo
Copy link
Collaborator Author

I set it to 10 and it looks beautiful.

@akermu
Copy link
Owner

akermu commented Aug 1, 2019

Could you confirm that emacs-libvterm renders the color according to ZSH_AUTOSUGGEST_HIGHLIGHT_STYLE, so there's no error in its color selection?

@Sbozzolo
Copy link
Collaborator Author

Sbozzolo commented Aug 1, 2019

I am using this page as reference: https://coderwall.com/p/pb1uzq/z-shell-colors

This is what I get
2019-08-01:11:30:57

To be compared with:

Screen_Shot_2012-09-01_at_10 46 11_PM

I think that there is still something off in the first 8 colors. For instance, color 0 and color 16 looks the same in the correct screenshot (the second), but not on mine.

@jixiuf
Copy link
Collaborator

jixiuf commented Aug 2, 2019

this should be the problem of solarized theme
related links:
mbadolato/iTerm2-Color-Schemes#62

the default solarized theme for iterm2 has same problem
can be fixed with this :
altercation/solarized#220 (comment)
altercation/solarized#220 (comment)

@Sbozzolo
Copy link
Collaborator Author

Sbozzolo commented Aug 2, 2019

That's interesting. Hence, I think that this issue can be closed!

@akermu akermu closed this as completed Aug 3, 2019
@akagr
Copy link

akagr commented Aug 20, 2024

So if you ran this code:

(set-face-attribute 'vterm-color-default nil :foreground "#839496" :background "#002b36")
(set-face-attribute 'vterm-color-black nil :foreground "#073642" :background "#002b36")
(set-face-attribute 'vterm-color-red nil :foreground "#dc322f" :background "#cb4b16")
(set-face-attribute 'vterm-color-green nil :foreground "#859900" :background "#586e75")
(set-face-attribute 'vterm-color-yellow nil :foreground "#b58900" :background "#657b83")
(set-face-attribute 'vterm-color-blue nil :foreground "#268bd2" :background "#839496")
(set-face-attribute 'vterm-color-magenta nil :foreground "#d33682" :background "#6c71c4")
(set-face-attribute 'vterm-color-cyan nil :foreground "#2aa198" :background "#93a1a1")
(set-face-attribute 'vterm-color-white nil :foreground "#eee8d5" :background "#fdf6e3")

the colors are still not correct?

Thanks for teaching me about this. The variable vterm-color-black was set to a light shade of gray for some reason, and it looked weird on a couple of applications (k9s being one of them). I've set it to proper black for now and don't notice anything breaking.

(set-face-attribute 'vterm-color-black nil :foreground "#000000" :background "#000000")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants