Directory colors are too dim by default

[flw-cn]

lf is really a great idea! I really like it. But it looks very dim on my terminal. So I hope that please to support TrueColor if possible.

[gokcehan]

@flw-cn Thank you for your interest in lf and also for reporting this issue as I was meaning to write something about this for a while.

Unfortunately, lf uses termbox-go for its ui which does not support 24-bit colors so we are unlikely to support 24-bit colors in lf as well. However, this should not be limiting as one can always configure the basic 8 colors used by the terminal most likely from a 24-bit color palette and lf can then use those colors automatically. More information about this can be found under 'Colorschemes' section in the documentation.

If you ask me, this issue is more about having dim colors as defaults rather than supporting 24-bit colors. Normally lf uses the same colors as ls so one would expect ls to have the same problem as well. However, this does not seem to be the case due to the way some terminals interpret ansi escapes differently (e.g. vte based terminals like gnome-terminal). On these terminals, running a multiplexer like tmux can eliminate this difference but this is not an ideal solution.

This difference between lf and ls started happening once we switched the output mode from 8 colors to 256 colors in lf. More specifically, for the basic 8 colors, termbox uses sgr 3-bit color escapes in 8-color mode (e.g. \033[34m), and sgr 8-bit color escapes in 256-color mode (e.g. \033[38;5;4m). On the other hand, ls uses 3-bit color escapes by default, and whatever color escape the user provided to support 256-colors. More information about ansi escape codes can be found in wikipedia.

On the other side of this issue, terminals interpret the 'bold' attribute (i.e. \033[1m) differently which is relevant to this issue since directories are bold blue by default. Some terminals use a bold font when this attribute is set, while others use a more intense brighter color instead. Sometimes they combine both approaches and use a bold font with an intense color. The problem occurs when they use different methods for 3-bit and 8-bit color codes.

I use the following script to test this behavior:

#!/bin/sh
printf "ansi sgr 3-bit codes (8 colors)  ansi sgr 8-bit codes (256 colors)\n"
printf "\033[34mblue ([34m)\033[m                      \033[38;5;4mblue ([38;5;4m)\033[m\n"
printf "\033[1;34mbold blue ([1;34m)\033[m               \033[1;38;5;4mbold blue ([1;38;5;4)\033[m\n"
printf "\033[94mintense blue ([94m)\033[m              \033[38;5;12mintense blue ([38;5;12m)\033[m\n"
printf "\033[1;94mbold intense blue ([1;94m)\033[m       \033[1;38;5;12mbold intense blue ([1;38;5;12m)\033[m\n"

When the left column is matched with the right column, lf and ls should use the same colors. When two columns are not matched, lf and ls may use different colors. For example, followings are from a vte based terminal with and without tmux:

In my opinion, the most reasonable solution to this issue is to ask terminal developers to use the same method for 3-bit and 8-bit color codes. Since this is not an option, the easiest workaround for now is to either use tmux or set brighter colors for regular colors in your terminal. On the long term, we should solve this issue on the lf side to not bother people with terminal configurations. I was thinking of switching back to 8-color mode in termbox by default and add an option for 256-color mode for people who wants to deal with these issues. Another possibility is to patch termbox to use 3-bit codes for the basic 8 colors even in 256-color display mode. On the bright side, I think now there is a tendency for terminal developers to use brighter colors by default, windows being one of them (link), so this issue may not happen in the future.

I'm changing the title to something more appropriate to track this issue here.

[flw-cn]

@gokcehan Thank you for explaining patiently to me. I have found a way under your guidance.
I understand that my problem is the blue color does look good when it is reversed.
The contrast of black on blue is not obvious enough.
So I just made a shell alias to avoid this problem simply:

alias lf='LSCOLORS=GxfxcxdxCxegedabagacad lf'

[gokcehan]

@flw-cn That sounds like a simple solution. I'm glad to hear it worked out for you. Sorry for my long response by the way. I had taken a look at this a few times before and I keep forgetting why this happens. So I wanted to document this somewhere to work on it later on.

[seifferth]

Thank you @gokcehan for explaining the problem so well. Apparently the mapping between 3-bit colour codes in LS_COLORS and 8-bit colour codes used by termbox-go is less then ideal on some (or even many?) terminals – at least on the ones I use (tty, xfce4-terminal).

The workaround I came up with was to use a custom mapping between 3-bit colour codes (as used by ls) and 8-bit colour codes. I got a basic LS_COLORS via dircolors command and changed some of the 3-bit colour codes to 8-bit colour codes as follows:

# ANSI 8-bit Format Example:
#   di=01;38;5;12
# Explanation: 
#   01      bold
#   38;5    use 8-bit code 
#   12      8-bit code
# 
# Colour map: 
# human    3-bit   8-bit 
# blue      34      12 
# cyan      36      14 
# green     32      10 

LS_COLORS='rs=0:di=01;38;5;12:ln=01;38;5;14:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=38;5;12;42:st=37;44:ex=01;38;5;10:'
export LS_COLORS

Using this form of LS_COLORS (by including the snippet in .bashrc) works ok for me, which is why I want to share it in case anyone else might find it useful. Effectively what I did is simply to define high-intensity 8-bit colour codes for blue, cyan and green. The only problem with this workaround is that inverting colours on selected lines will invert default background colour (which is black or semi-transparent black in my case) to default foreground colour (which is white).

In the long run it might be a good idea to do some sort of custom 3-bit / 8-bit mapping by default in order to get nice default colours on most terminals (e. g. by defaulting to high-intesity colours for bold text). This might be convenient for users who don't want or need custom colours, just sensible / readable defaults. Just a thought, though.

[gokcehan]

@seifferth Thanks for the solution and pinging me again for this issue. I fully agree with sensible/readable defaults. It seems to me that the easiest solution for now is to use 8-bit mode in termbox and hide 256 color mode behind an option. In 8-bit mode lf should behave mostly like ls and most terminals can't afford to make ls output unreadable so we should be fine. People who wants to spare time configuring colors can simply turn on 256 color mode option before they start tweaking.

[gokcehan]

I have now changed the ui to use 8 colors by default (i.e. sgr 3-bit codes). There is now an option named color256 which is disabled by default to change this to 256 colors (i.e. sgr 8-bit codes). If you already customized the colorscheme previously and don't want any changes you can set color256 option to get the old behavior. For new users, lf should now use the same escape codes by ls which is likely readable in most terminals.

Closing this issue now. Feel free to report here any issues you have.

[roachsinai]

Hi, @gokcehan I got same issue this time (maybe be different reason):

But seems the reason is the terminal colorscheme I used, I'm on Konsole using Gruvbox Dark colorscheme from here: https://github.com/morhetz/gruvbox-contrib/blob/master/konsole/Gruvbox_dark.colorscheme

The error message is very hard to figure out.

After change to another colorscheme Darcula for example the text message is distinct, but I prefer to gruvbox in daily using.

Any suggestion will be appreciated!!!

[gokcehan]

@roachsinai You should be able to customize error message colors with errorfmt option without changing the terminal colorscheme.

[roachsinai]

@gokcehan thanks for quick reply, I'll check it!

[roachsinai]

Change it by set errorfmt "\033[1;37;41m%s\033[0m", thanks again.