Closed dustdfg closed 8 months ago
Is the environment variable MICRO_TRUECOLOR=1
set?
MICRO_TRUECOLOR=1
No. I just tried to enable it and it doesn't have any influence... And it also doesn't affect gnome-terminal
that works without this bug
I do not know much about terminals but I think another color was used because 24-bit color was disabled. The 8th color (regular7
in foot) is usually white in terminal themes so it will probably be a color that looks like the default one if not set.
24-bit color was probably disabled because foot is not in the terminfo database in micro, but I think other programs usually use the system database. There is an isuse about the terminfo database being included: #2543
I tried reading "TRUECOLOR" section in the manpage of foot and I do not know if the terminfo entries have to be used, but I think it is related. 24-bit colors is just disabled if MICRO_TRUECOLOR
is not 1
so nothing would change when setting it but I think it will probably be enabled when setting TERM
environment variable with xterm-truecolor
:
https://github.com/zyedidia/micro/blob/2d82362a6695a7e898455ce016449167ac439ddd/internal/screen/screen.go#L144-L149
So you mean to try: MICRO_TRUECOLOR=1
with TERM=xterm-truecolor
? I just tried it and it didn't help. Tell you more, COLORTERM=truecolor
was at the same time
But i just found one fun thing. TERM=xterm-truecolor
as likeTERM=xterm-256color
gives bug but TERM=xterm-color
works normally.
EDIT: it looked like it is without bug. Just because I opened plain micro and saw white as expected... What is wrong? Idk I can say that colors are loosed but not more before further research
P.S Happy New Year
Sorry, I realized there is probably something wrong with what I thought about MICRO_TRUECOLOR
but it is late here so I cannot check again and explain properly at this time. I think it would at least be surprising if 24-bit color is enabled when TERM
is xterm-color
even though MICRO_TRUECOLOR
is not 1
, but I still have not checked.
Happy new year also.
No, I was only thinking about trying to run with TERM=xterm-truecolor
but I realized MICRO_TRUECOLOR
has to be 1
. I was also wrong about terminfo.
I did not say that I thought the included terminfo database only is used, but entries in files are also used so the entries of foot are used. I do not think TERM
usually has to be changed because COLORTERM
(not manually set) only is probably checked when it is being checked if 24-bit color is supported.
MICRO_TRUECOLOR
has to be 1
when enabling it but I do not know why it was disabled when you set it and I think it is weird. I tried looking at the manpage of foot and I think TERM
can tried being set as foot-direct
so that it will be enabled.
I have not used Wayland before so I tried copying the terminfo entry of foot in Debian 12 and using a terminal emulator where 24-bit color is enabled, but it was enabled when MICRO_TRUECOLOR
is 1
and TERM
is foot
. I used another terminal emulator so it was just bugged when TERM
is foot-direct
.
I think this script can be used when testing and changing TERM
. MICRO_TRUECOLOR
is set as 1
when arguments are passed.
#!/bin/sh
set -u -e
[ $# -gt 0 ] && export MICRO_TRUECOLOR=1
echo "COLORTERM ${COLORTERM:--} MICRO_TRUECOLOR ${MICRO_TRUECOLOR:--}"
# opening micro takes a while when using other terminal emulators and
# TERM is foot-direct, not tested
for t in xterm xterm-color xterm-256color xterm-truecolor foot; do
printf %s $t
read _
TERM=$t micro -colorscheme monokai
done
This is what it was like when I used the terminal emulator I was using: https://github.com/zyedidia/micro/assets/127052329/0e285b64-d3cc-45fb-a8d9-4008c3586af3
I apologize that what I have said was confusing and that I was not able to answer properly.
I tried testing using foot and GNOME Terminal in Debian 12 but 24-bit color was only enabled when I set MICRO_TRUECOLOR
as 1
and ran micro even if I did not do something else. I do not know how did you set it but I think the variable was not exported when running micro probably because MICRO_TRUECOLOR=1
only was entered in a line when you were setting it in the shell.
The variable can be set like this when running micro:
MICRO_TRUECOLOR=1 micro
micro # running again, variable is not set
The variable can also be set and exported in another line like this so that it will be set when it is not set in a command:
export MICRO_TRUECOLOR=1
micro
You are right it wasn't exported. My habit is to put ;
between commands usually gives me problems with variable exporting. It usually happens like export ; command
. "Hmm it didn't work I should try two lines form (without export). Hmm it also didn't work so the variable doesn't work."
Foot works as expected when the MICRO_TRUECOLOR
is 1
but it is still strange that it doesn't work without it because gnome terminal works normally
24-bit color is disabled when MICRO_TRUECOLOR
is not 1
even when using GNOME Terminal but the colors in monokai
in micro and the default color scheme in GNOME Terminal (Tango) are similar so it can look like it is enabled. I used LMDE 6 when testing but packages are based on the packages in Debian 12 so I think there is at least not much differences.
It can be seen in this video that the colors are different when MICRO_TRUECOLOR
is not 1
:
https://github.com/zyedidia/micro/assets/127052329/2c83d192-5285-4d41-b402-a5bbf5672814
Yeah. It is correct. I just changed the color in gnome terminal and so that micro uses it as like in foot. Thanks!
Description of the problem or steps to reproduce
I tried new theme for terminal and found a strange bug: micro uses foot's
bright7
color instead ofdefault
listed in color scheme file. Ifbright7
color isn't set, micro use default color as expected...Here you can see
monokai
theme that uses terminals red color instead of usual white:Monokai theme specifies two colors:
color-link default "#F8F8F2,#282828"
and it works in the terminals but foot for some reason behaves differently...Specifications
Commit hash: https://github.com/zyedidia/micro/commit/2d82362a6695a7e898455ce016449167ac439ddd OS: Debian12 Terminal: affects only foot!