helix
helix copied to clipboard
enable true-color support by default
On the latest master (commit 6da2174e14576ff07a0a2a28074fac5276b23d79
), when I start helix
and try to select a theme, I get the following error: Unsupported theme: theme requires true color support
.
When using commit 178cd5ecfc75280ae12810cf3c0aeb22284bfdf2
everything works fine.
Environment
- Platform: Linux
- Helix version: v0.5.0-243-g6da2174
~/.cache/helix/helix.log
Empty log after trying to set the theme.
Which theme, any of them, or a particular one? Could you try running helix with -vvv
and look at the helix log then?
It probably can't detect whether your terminal is true-color after a recent PR that added a check for it. Until it gets fixed, you can add true-color = true
to your config.toml
What terminal are you using?
And what's the value of the COLORTERM env variable?
@dead10ck after adding -vvv
here are the logs
2021-12-15T07:10:07.879 mio::poll [TRACE] registering event source with poller: token=Token(1), interests=READABLE | WRITABLE
2021-12-15T07:10:07.879 mio::poll [TRACE] registering event source with poller: token=Token(2), interests=READABLE | WRITABLE
2021-12-15T07:10:07.879 mio::poll [TRACE] registering event source with poller: token=Token(0), interests=READABLE
2021-12-15T07:10:07.879 mio::poll [TRACE] registering event source with poller: token=Token(1), interests=READABLE
2021-12-15T07:10:13.938 mio::poll [TRACE] deregistering event source from poller
2021-12-15T07:10:13.938 mio::poll [TRACE] deregistering event source from poller
@kirawi thanks, but I just came back to the version that worked for now 😛
@archseer I'm running bash with starship in tmux through ssh from iTerm2 on a macbook pro. The COLORTERM
seems to be empty... My configuration is pretty much "all by default" so I'd expect it to work by default as well 🤔 I don't have the technical requirements in mind so I might be wrong 😉
I'm running bash with starship in tmux through ssh from iTerm2 on a macbook pro.
Refer to this: https://gist.github.com/XVilka/8346728#checking-for-colorterm
Here is a single note: Having an extra environment variable (separate from TERM) is not ideal: by default it is not forwarded via sudo, ssh, etc, and so it may still be unreliable even where support is available in programs.
Maybe this is why COLORTERM
seems to be compty although iterm2 support truecolor
The commit in question that changed the behavior: https://github.com/helix-editor/helix/commit/98ce2a301da25152563137047377026d72fd644c
I'm a bit skeptical that checking COLORTERM is the right solution here, since it has so many limitations as @WindSoilder notes.
I took a look at what neovim does, and it's much more complicated - checking tmux
settings in some cases, or docs instructing users to put complex checks in config.
There may not be a "right answer" here, but at the very least I think the error could be improved. Perhaps you could instruct users to add "true-color = true" to their Config.toml to override the check? Or it could just be a warning message, like: "Warning: Theme requires true color support which does not appear to be provided by your terminal."
What was the original reason we chose not to use terminfo
?
From what I understand terminfo
wouldn't fix the problem either since you'd be checking the terminfo files stored on the server.
Detection is going to always be problematic: either we'll have false positives or false negatives. Perhaps we should enable truecolor by default (we're targetting modern terminals afterall) and allow disabling it if the user is using a terminal without truecolor support.
Detection is going to always be problematic: either we'll have false positives or false negatives. Perhaps we should enable truecolor by default (we're targetting modern terminals afterall) and allow disabling it if the user is using a terminal without truecolor support.
What about providing a new command named theme-base16
, and it only prompt and allows user to activate non truecolor, base16 themes;
To handle this efficiently, without looking into the theme itself to detect if it's true color theme. We can make a name convention for the name of theme:
-
non-truecolor
theme namedbase16-xxxx.toml
. - else they are
truecolor
theme. - a special case: true color base16 theme, we can rename it as
base16-xxx-256.toml
(just like these base16 themes for iterm2: https://github.com/martinlindhe/base16-iterm2/tree/master/itermcolors). It will involve renaming base16_default_dark and base16_default_light.
Same issue here with MacOS Terminal Version 2.12
MacOS terminal doesn't support truecolor
(https://github.com/termstandard/colors#not-supporting-truecolor). You either need to use a truecolor-compatible terminal, or use a theme that uses the limited color range.
I'm having this issue when ssh to a headless Linux host from iTerm2 on macOS. No issues at all locally on my mac. Edit: setting true-color = true in the config on the remote host solves the issue.
Just throwing in another new user experience, not looking for support. I use tmux and in all three terminals I use; alacriTTY, cool-retro-term, and gnometerm, with COLORTERM set it gets unset inside of tmux. I have truecolor overrides set as shown below in my tmux config, which made tc themes work in vim but not in hx.
7 set-option -g default-shell $SHELL
8 set -g default-terminal "tmux-256color"
9
10 # Technically this next line should be the commented "RGB" version
11 # below, as a 256color terminal only guaranties 16 bit support (RGB)
12 # rather than 24-bit (Tc or true color) but there don't seem to be
13 # appropriate TERM names for tc support so I set Tc whenever 256color
14 # is in the TERM name and just hope for the best
15 set -ga terminal-overrides ",*256col*:Tc"
16 # set -ga terminal-overrides ",*256col*:RGB"
17
18 # alacritty on the other hand sets TERM to alacritty, and definitely
19 # does support true color
20 set -ga terminal-overrides ",*alacritty*:Tc"
I'll just set COLORTERM manually but this is possibly a stumbling block for SSH/tmux/etc. users as mentioned above.
I have the same issue on Windows Terminal, WSL2 and tmux. Truecolor themes work in vim with the same setup
Looks like you scoped your override only to alacritty? This works for me: https://github.com/archseer/snowflake/blob/47620e0828fe4d3e7a83dd40f86351f52b800f47/profiles/develop/tmux/tmux.conf#L1-L2
It probably can't detect whether your terminal is true-color after a recent PR that added a check for it. Until it gets fixed, you can add
true-color = true
to yourconfig.toml
hx says this setting is not recognized
It's under the editor key:
# ~/.config/helix/config.toml
[editor]
true-color = true
It's under the editor key:
# ~/.config/helix/config.toml [editor] true-color = true
Thank you!
I am going to close this since there is already the editor.true-color
setting for cases where automatic detection failed.
For detecting true-color using term-info #5319 contains more details although as @archseer mentioned that will not fix all issues either.
@pascalkuthe Hi is this pr shipped with 24.03? because with 24.03 i have same issue using windows terminal and remote my helix editor on remote server
this is not a pr? This is an issue we decided to not go forward with, its not always possible to detect true-color support automatically. In that case use the setting to overwrite