diff options
author | Gregory Anders <8965202+gpanders@users.noreply.github.com> | 2024-06-05 08:27:56 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-06-05 08:27:56 -0500 |
commit | d7651b27d54a87c5783c0a579af11da9a16a39aa (patch) | |
tree | 20f2ead81b001fabce872f0471219ac218bd6706 /runtime/lua/vim | |
parent | 43bd9c9c1cacb2f069c7e84330a608623c874d74 (diff) | |
download | rneovim-d7651b27d54a87c5783c0a579af11da9a16a39aa.tar.gz rneovim-d7651b27d54a87c5783c0a579af11da9a16a39aa.tar.bz2 rneovim-d7651b27d54a87c5783c0a579af11da9a16a39aa.zip |
fix(tui): move $COLORTERM check to _defaults.lua (#29197)
We currently check $COLORTERM in the TUI process to determine if the
terminal supports 24 bit color (truecolor). If $COLORTERM is "truecolor"
or "24bit" then we automatically assume that the terminal supports
truecolor, but if $COLORTERM is set to any other value we still query
the terminal.
The `rgb` flag of the UI struct is a boolean which only indicates
whether the UI supports truecolor, but does not have a 3rd state that we
can use to represent "we don't know if the UI supports truecolor". We
currently use `rgb=false` to represent this "we don't know" state, and
we use XTGETTCAP and DECRQSS queries to determine at runtime if the
terminal supports truecolor. However, if $COLORTERM is set to a value
besides "truecolor" or "24bit" (e.g. "256" or "16) that is a clear
indication that the terminal _does not_ support truecolor, so it is
incorrect to treat `rgb=false` as "we don't know" in that case.
Instead, in the TUI process we only check for the terminfo capabilities.
This must be done in the TUI process because we do not have access to
this information in the core Neovim process when `_defaults.lua` runs.
If the TUI cannot determine truecolor support from terminfo alone, we
set `rgb=false` to indicate "we don't know if the terminal supports
truecolor yet, keep checking". When we get to `_defaults.lua`, we can
then check $COLORTERM and only query the terminal if it is unset.
This means that users can explicitly opt out of truecolor determination
by setting `COLORTERM=256` (or similar) in their environment.
Diffstat (limited to 'runtime/lua/vim')
-rw-r--r-- | runtime/lua/vim/_defaults.lua | 10 |
1 files changed, 7 insertions, 3 deletions
diff --git a/runtime/lua/vim/_defaults.lua b/runtime/lua/vim/_defaults.lua index 79fe5a8513..01dcd4bf74 100644 --- a/runtime/lua/vim/_defaults.lua +++ b/runtime/lua/vim/_defaults.lua @@ -470,10 +470,14 @@ do --- response indicates that it does support truecolor enable 'termguicolors', --- but only if the user has not already disabled it. do - if tty.rgb then - -- The TUI was able to determine truecolor support + local colorterm = os.getenv('COLORTERM') + if tty.rgb or colorterm == 'truecolor' or colorterm == '24bit' then + -- The TUI was able to determine truecolor support or $COLORTERM explicitly indicates + -- truecolor support setoption('termguicolors', true) - else + elseif colorterm == nil or colorterm == '' then + -- Neither the TUI nor $COLORTERM indicate that truecolor is supported, so query the + -- terminal local caps = {} ---@type table<string, boolean> require('vim.termcap').query({ 'Tc', 'RGB', 'setrgbf', 'setrgbb' }, function(cap, found) if not found then |