Bright black color issue #449

Closed
opened 6 months ago by cglogic · 13 comments
cglogic commented 6 months ago

I have xterm and foot configured with the same color scheme. But in ncmpcpp with default colors elements with bright black foreground showed as black in foot.

I have xterm and foot configured with the same color scheme. But in ncmpcpp with default colors elements with bright black foreground showed as black in foot.
Owner

Step one, manually test the escape sequence: echo -e '\e[90mbright black\e[m', in both xterm and foot. Do they look the same?

If so, it may be terminfo related. What's your TERM set to? If foot, does ncmpcpp work better if you instead use xterm-256color (you can test this without editing foot.ini by simply doing TERM=xterm-256color ncmpcpp)?

Step one, manually test the escape sequence: `echo -e '\e[90mbright black\e[m'`, in both xterm and foot. Do they look the same? If so, it may be terminfo related. What's your `TERM` set to? If `foot`, does ncmpcpp work better if you instead use `xterm-256color` (you can test this without editing foot.ini by simply doing `TERM=xterm-256color ncmpcpp`)?
Poster

Step one, manually test the escape sequence: echo -e '\e[90mbright black\e[m', in both xterm and foot. Do they look the same?

Yes, they look the same, bright black foreground as it should be.

If so, it may be terminfo related. What's your TERM set to? If foot, does ncmpcpp work better if you instead use xterm-256color (you can test this without editing foot.ini by simply doing TERM=xterm-256color ncmpcpp)?

I have term=xterm-256color in foot.ini and echo $TERM shows
xterm-256color.

I run foot under FreeBSD 13, so can't use TERM=foot.

> Step one, manually test the escape sequence: echo -e '\e[90mbright black\e[m', in both xterm and foot. Do they look the same? Yes, they look the same, bright black foreground as it should be. > If so, it may be terminfo related. What's your TERM set to? If foot, does ncmpcpp work better if you instead use xterm-256color (you can test this without editing foot.ini by simply doing TERM=xterm-256color ncmpcpp)? I have `term=xterm-256color` in `foot.ini` and `echo $TERM` shows `xterm-256color`. I run `foot` under FreeBSD 13, so can't use `TERM=foot`.
Owner

Ok, then this is both a bit surprising, and also hard to debug.

ncurses is known to check the name of the terminfo (and not just the term capabilities defined by it). But you're already using xterm-256color so that shouldn't be the problem.

I don't use, or have access to a FreeBSD machine so can't really test this myself.

I assume you are using foot-1.7.1?

I'll try to get a trace of the escapes emitted by ncmpcpp on my Linux box. That might help narrow this down.

Ok, then this is both a bit surprising, and also hard to debug. ncurses is known to check the **name** of the terminfo (and not _just_ the term capabilities defined by it). But you're already using `xterm-256color` so that shouldn't be the problem. I don't use, or have access to a FreeBSD machine so can't really test this myself. I assume you are using foot-1.7.1? I'll try to get a trace of the escapes emitted by ncmpcpp on my Linux box. That might help narrow this down.
Poster

I assume you are using foot-1.7.1?

Yes, but also tried fresh development branch.

Unfortunately, I can't test ncmpcpp in foot on Linux for now.

I think if you don't see this issue with ncmpcpp in foot on Linux the issue should be closed. Because it hard to debug and fix.

Recently FreeBSD switched from termcap to terminfo but only for development branch, so after this there are should be no differencess with Linux. But new FreeBSD release with these changes will be in 2 years or so.

Thanks.

> I assume you are using foot-1.7.1? Yes, but also tried fresh development branch. Unfortunately, I can't test `ncmpcpp` in `foot` on Linux for now. I think if you don't see this issue with `ncmpcpp` in `foot` on Linux the issue should be closed. Because it hard to debug and fix. Recently FreeBSD switched from `termcap` to `terminfo` but only for development branch, so after this there are should be no differencess with Linux. But new FreeBSD release with these changes will be in 2 years or so. Thanks.
Owner

There's still a couple of checks I'd like to do, before closing this.

Can you post your ncmpcpp config? I know you said "default colors", but I'm not sure I see any "bright black" elements in my config at all, and your config looks slightly different than mine.

There's still a couple of checks I'd like to do, before closing this. Can you post your ncmpcpp config? I know you said "default colors", but I'm not sure I see any "bright black" elements in my config at all, and your config looks slightly different than mine.
Poster

Can you post your ncmpcpp config?

See progressbar_color = black:b and alternative_ui_separator_color = black:b. :b is bright. They are commented but it seems their default values is the same. Uncomment these settings change nothing, but other colors works.

UPD:
I tried other bright colors and it seems all of them works as not bright. In xterm they showed as bright.

> Can you post your ncmpcpp config? See `progressbar_color = black:b` and `alternative_ui_separator_color = black:b`. `:b` is bright. They are commented but it seems their default values is the same. Uncomment these settings change nothing, but other colors works. UPD: I tried other bright colors and it seems all of them works as not bright. In xterm they showed as bright.
16 KiB
Owner

Ah, I think I know what it may be. It is probably not actually using the bright black color, but makes it bold, and expects the terminal to also brighten the color.

Try enabling bold-text-in-bright in foot.ini

Ah, I think I know what it may be. It is probably not actually using the bright black color, but makes it bold, and expects the terminal to also brighten the color. Try enabling `bold-text-in-bright` in foot.ini
Poster

Ah, I think I know what it may be. It is probably not actually using the bright black color, but makes it bold, and expects the terminal to also brighten the color.

Very strange decision from ncmpcpp.

Try enabling bold-text-in-bright in foot.ini

Now all bold text looks very bright. Lines with black:b color almost visible. I think resulting color is not bright black from palette.

> Ah, I think I know what it may be. It is probably not actually using the bright black color, but makes it bold, and expects the terminal to also brighten the color. Very strange decision from `ncmpcpp`. > Try enabling bold-text-in-bright in foot.ini Now all bold text looks very bright. Lines with `black:b` color almost visible. I think resulting color is not bright black from palette.
Poster

Looks like with bold-text-in-bright foot increases color intencity for bold attribute despite of color index. In the same case xterm shifts 0-7 colors to brighter 8-15 colors and does nothing for other.

Looks like with `bold-text-in-bright` foot increases color intencity for bold attribute despite of color index. In the same case xterm shifts 0-7 colors to brighter 8-15 colors and does nothing for other.
Owner

Correct. Foot has a generic "brighten" function that is used regardless if whether the color being brightened is from the palette, or a custom RGB color.

We could fairly easy modify it to recognize palette colors and use the corresponding bright color. See #360

Correct. Foot has a generic "brighten" function that is used regardless if whether the color being brightened is from the palette, or a custom RGB color. We could fairly easy modify it to recognize palette colors and use the corresponding bright color. See https://codeberg.org/dnkl/foot/issues/360#issuecomment-177792
Owner

Very strange decision from ncmpcpp.

It's the old way of doing it.

Modern terminals have opted to separate "bold" from "bright", to enable bold fonts being used without also brightening them.

Some applications (and users!) still rely on the old method.

> Very strange decision from ncmpcpp. It's the old way of doing it. Modern terminals have opted to separate "bold" from "bright", to enable bold fonts being used **without** also brightening them. Some applications (and users!) still rely on the old method.
Poster

We could fairly easy modify it to recognize palette colors and use the corresponding bright color. See #360

Sounds good.

I changed ncmpcpp config to use color codes and now it looks almost as it should. Album title in alternative mode has no config option to change color.

Feel free to close the issue or leave it to track.

Thanks for your assistance and your time.

> We could fairly easy modify it to recognize palette colors and use the corresponding bright color. See #360 Sounds good. I changed ncmpcpp config to use color codes and now it looks almost as it should. Album title in alternative mode has no config option to change color. Feel free to close the issue or leave it to track. Thanks for your assistance and your time.
Owner

I plan on partially fixing #360, by trying to map colors-being-brightened to the palette colors, and using the corresponding bright palette color when there's a match.

Let's keep this issue open until then.

I plan on partially fixing #360, by trying to map colors-being-brightened to the palette colors, and using the corresponding bright palette color when there's a match. Let's keep this issue open until then.
dnkl closed this issue 6 months ago
dnkl added the
enhancement
label 6 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.