[vim/vim] Background color detection for terminals (#869)

[Josh Triplett]

Vim's automatic background color detection works in GUI mode, but not in a terminal.

On any xterm-compatible terminal, vim could detect the background color via terminal escapes (documented in http://invisible-island.net/xterm/ctlseqs/ctlseqs.html) and use that to automatically detect whether to use bg=dark or bg=light (by default or with :set bg&).

To detect the background color:

• Include `\e]11;?\a' during terminal initialization.
• Asynchronously, when processing input, watch for the escape sequence \e]11;COLOR\a (or equivalent using OSC instead of \e] for the escape, and ST or \e\\ instead of \a for the terminator). If the COLOR portion matches rgb:RRRR/GGGG/BBBB where R, G, and B are hex digits, then compute the luminance of the RGB color and classify it as light/dark accordingly.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Josh Triplett]

Looks like vim already handles this to set the background at startup, just not the default background (for :set bg&). It'd be nice to set the default background, too; a call to set_string_default from term.c at the same point it sets the background should work for that.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, .

[Christian Brabandt]

would you mind creating a patch for that?

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, .

[Kevin Lawler]

Would also like to see this fixed

[damnskippy]

Currently noticing that no matter whether the terminal has dark or light background, vim sets the background to light. i.e. $ vim -u NONE followed by :set bg?
Is that because of this issue reported by @joshtriplett?
I was trying to set a dark or light color theme based on terminal scheme, using vim's auto detection and setting of 'background'. But perhaps that is not working due to this issue?

[Petr Kubánek]

I am battling the same issue, as I have a light terminal at work and dark at home. Will try to fork and look for a patch.

[John Starich]

I would also love to see this. Unfortunately, the last time I looked at macOS's built-in Terminal, it didn't support this form of color code return 😞

I did come up with a work-around for macOS if anyone is interested. It runs this vim script, which uses AppleScript under the hood: https://github.com/JohnStarich/dotfiles/blob/8d15945ca764048a228b1df6e4038c574494e9f5/vim/vimrc#L77-L88

https://github.com/JohnStarich/dotfiles/blob/8d15945ca764048a228b1df6e4038c574494e9f5/bin/mac-term-dark-background#L4-L18

[Adam Stankiewicz]

@JohnStarich Maybe iTerm2? I think it's more popular than built-in one

[John Starich]

I think I prefer to use my work-around rather than installing another app, but thanks for the suggestion @sheerun!

[097115]

Okay, this is quite an old one but may be there was some progress?

May be I'm wrong but a command like this:

vi -u NONE +'if &background == "dark" | echom "dark" | 
    elseif &background == "light" | echom "light" | 
    else | echom "what" | endif'

seems to always return 'light', no matter what the actual terminal emulator's background is (tested in Linux / macOS with Alacritty / iTerm / Roxterm / Tilix).

But may be some workaround exists [for Unix-like systems]?

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Kevin Lawler]

in the intervening time the issue has moved, and the skew solution now emerging is to detect the system conception of darkmode versus actually detecting the background color

as of macOS 11.1, date 2021.01.14

 let light_not_dark=1

" on macvim same as v:os_appearance as of 2020.12.17
let output =  system("defaults read -g AppleInterfaceStyle")
if v:shell_error != 0
    let light_not_dark=1
else    
    let light_not_dark=0
endif

if light_not_dark
    colorscheme solarized
    set background=light
else
    colorscheme solarized
    set background=dark
endif

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[097115]

Thanks for your comment, Kevin, but it's not really the same (that is, OS darkmode ON/OFF vs terminal background color) :(

But thank you for your help and interest nonetheless!

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Tony Mechelynck]

@097115 : on Linux it does not always default to "light" but maybe I hit on one of your "corner cases". I used the following:

vim --clean
:set bg?

• In the non-X console (after Ctrl-Alt-F1 to Ctrl-Alt-F6 possibly followed by a text-mode login; come back to X by Ctrl-Alt-F7) the answer is dark. (In that console, 'term' is set to linux)
• In xterm and konsole (where 'term' is set to xterm) and in mlterm (where 'term' is set to mlterm), the answer is light.
• In all cases, the background setting agrees with the actual setting (black in the non-X console, white in xterm and mlterm, a very pale shade of yellow in konsole).

Best regards,
Tony.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Tony Mechelynck]

P.S. And with gvim instead of vim, background is light, the background is actually white, and term is builtin_gui.

't_Co' is 8 in the non-X console and 256 in all tested console emulators.

Best regards,
Tony.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[097115]

Thank you for your comments, @tonymec! As I've said, :help 'background' agrees with you:

For MS-Windows the default is "dark".
For other systems "dark" is used when 'term' is "linux",
"screen.linux", "cygwin" or "putty", or $COLORFGBG suggests a dark
background.  Otherwise the default is "light".

May be calling those 'corner cases' wasn't the best possible word choice on my side but $TERM is mostly xterm and its variations (and sometimes screen-256color, too) around me nowadays :) (and only iTerm seems to set $COLORFGBG but it still doesn't update it if I change the palette for an open session).

So, given all that, I can't think of the way how to programatically set Vim's colorscheme based on the terminal's background unless somehow forcing it. I mean, it looks like we have all the necessary means for ages but either I'm missing something, or we still can't really use them here.

Anyway, thanks again, Tony!

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Tony Mechelynck]

Thanks @097115 for pointing out that paragraph in the help for 'background'. However, a little higher up there is another paragraph which might be of interest:

When the |t_RB| option is set, Vim will use it to request the background
color from the terminal. If the returned RGB value is dark/light and
'background' is not dark/light, 'background' will be set and the
screen is redrawn. This may have side effects, make t_BG empty in
your .vimrc if you suspect this problem. The response to |t_RB| can
be found in |v:termrbgresp|.

Best regards,
Tony.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[097115]

Thanks again, Tony!

Unfortunately, I tried experimenting with it before (like, vim -u NONE +'set t_RB&' +'set bg?', or vim -u NONE +'set t_RB=' +'set bg?', or vim -u NONE +'set t_RB=^[]11;rgb:fb/^G' +'set bg?') but the result was always 'light'.

So, either I'm just doing it wrong :), or may be it somehow fails detecting...

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Mike Boruta]

I can confirm that on a fresh Ubuntu 20.04 install, vim (8.1.2269) does not properly detect the background as dark and redraw the screen as described in the help message posted above by tonymec. Same behavior with the latest code from master. As the OP (joshtriplett) mentioned, vim seems to only use the $TERM or $COLORFGBG ENVs to determine what the terminal's background color is when executing set background&.

The funny thing is that vim does indeed have support for OSC11, and does fetch the terminal background color in this way (:echo v:termrbgresp shows the expected results), it just never seems to be used and is most certainly not called when executing set background& (tested inside a modified tmux with print statements). I may have narrowed it down to the term_bg_color() function never being called in do_highlight() due to is_normal_group always being false, but have not dug further.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Danek Duvall]

I've found that some (most?) of the time calling echoraw(&t_RB) does what we all seem to want set bg& to do. This is with 8.1.3450, on MacOS, in iTerm2. In fact, I'm using it with reasonable success to adapt to the light/dark changes of the terminal which happen (due to a script) when the system theme changes:

autocmd VimResume   * call echoraw(&t_RB)
autocmd FocusGained * call echoraw(&t_RB)

In my setup, vim does seem to take the result of OSC11 and set bg appropriately, but it happens pretty late in the startup. To the point where I have to do

autocmd TermResponse * colorscheme solarized8

in order for bg to be correct when the color scheme sets itself up, rather than just set it directly in .vimrc.

I don't really understand why it doesn't always work, though. For instance, I have a terminal that's definitely light, and v:termrbgresp is ^[]11;rgb:fdfd/f6f6/e3e3^G, which is clearly light, and yet re-sending t_RB doesn't change bg to light. But it works in most of my other terminals. Maybe there's some sort of timing issue; I haven't dived into the terminal handling code again to figure it out. (I do also sometimes see some sort of race between the color scheme and airline where the latter ends up with the wrong colors and I have to colorscheme solarized8 again, but I'm not sure if it's related.)

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.

[Rezart Qelibari]

For anyone who came here from a search engine and is looking for how to use an initialised background value on macOS in .vimrc:
On macOS Monterey (12.1) with vim 8.2 background detection seems to work quite nice, at least when I tried the different profiles of the default Terminal.app. The calculated value is not initialised during .vimrc run though, so to use it there nonetheless, I had to make use of autocmd OptionSet like this:

function! SetColorColumnColor()
  if &background ==# 'dark'
    " some code here
  endif
endfunction
autocmd OptionSet background call SetColorColumnColor()

—

Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/869/1059967090@github.com>

[John Sebastian Peterson]

john-peterson left a comment (vim/vim#869)

the last comment only works in dark mode. can someone add this patch

neovim/neovim#26677

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/869/2992477098@github.com>