Users of 'dark' terminals know that 'vim' binary started remotely (over ssh) does not choose correct theme (light vs. dark). There exists variable $COLORFGBG (that env var is e.g. exported by KDE's 'konsole' terminal emulator). As long as the COLORFGBG variable is set (correctly) in environment, vim is able to choose right theme automatically. The problem is, however, that tools like 'su', 'runuser', 'sudo', 'ssh' do trim environment for security reasons; including $COLORFGBG (which is otherwise safe variable). Some of those tools allow "white-listing" of safe variables, some not (and maybe its even not desired feature). This bug is thus mentioned as tracker for particular config-changes for the tools that allow it.
util-linux does not seem to have it implemented (yet?): https://github.com/karelzak/util-linux/issues/221
Pavel. You must have some special setup. Why does this work well with Gnome and dark terminals? What is special with KDE? Isn't it broken there? I never experienced such problem on any of systems I am connecting to. In ssh, we are sending and accepting only locale variables and XMODIFIERS. I don't think this report for KDE is enough to change default for whole distribution.
Jakub, you claim that vim is able to detect whether set 'bg=dark' or 'bg=light' based on XMODIFIERS? Can you please send me content of your $XMODIFIERS variable (to allow me to test it in KDE..)? Thanks.
I don't know how and if it is related to XMODIFIERS or how is it done, but I have different machines and under Gnome it never happened, to me to have problem with colours of vim. It looks (almost) the same with dark terminal and dark background everywhere. My XMODIFIERS variable looks like this: [root@rawhide ~]# echo $XMODIFIERS @im=ibus You report is quite vague. There is no test case and my knowledge about vim is not not so deep to know how to "vim is able to detect whether set 'bg=dark' or 'bg=light'". Can you be more specific?
(In reply to Jakub Jelen from comment #4) > I don't know how and if it is related to XMODIFIERS or how is it done, but I > have different machines and under Gnome it never happened, to me to have > problem with colours of vim. It looks (almost) the same with dark terminal > and dark background everywhere. > > My XMODIFIERS variable looks like this: > > [root@rawhide ~]# echo $XMODIFIERS > @im=ibus Its not related to XMODIFIERS. However I tried gnome-terminal installed in KDE, and it really works (for some reason). I thought the responsible code was term_bg_default(), but I bet it is unlikely. Let me look at it more carefuly. > You report is quite vague. There is no test case and my knowledge about vim > is not not so deep to know how to "vim is able to detect whether set > 'bg=dark' or 'bg=light'". Can you be more specific? Start vim and press: ":set bg<ENTER>", you'll get 'background=dark' or 'background=light'.
(In reply to Pavel Raiskup from comment #5) > Its not related to XMODIFIERS. However I tried gnome-terminal installed in > KDE, and it really works (for some reason). I thought the responsible code > was term_bg_default(), but I bet it is unlikely. Let me look at it more > carefuly. Ok, the reason why gnome-terminal works and konsole (KDE) not is because konsole is based on xterm, that does not understand the "background color request" (vim is able to read the response): echo -e "\033]11;?\a" vte291 (gnome-terminal's backend probably?) OTOH is able to give proper response. Dunno how realistic is hacking support for background RGB request in konsole/xterm -- I'll try to file a appropriate bugs.
Hmm, while trying to detect why fix for bug 1264682 did not help against {RHEL,CentOS}{6,7} vim, I realized that vim's background color detection is quite new feature (see also bug).
(In reply to Pavel Raiskup from comment #7) > Hmm, while trying to detect why fix for bug 1264682 did not help against > {RHEL,CentOS}{6,7} vim, I realized that vim's background color detection > is quite new feature (see also bug). By that I meant that forwarding COLORFGBG still makes sense. Even though patch for konsole was accepted by upstream. COLORFGBG should work against boxes with older vim. (In reply to Jakub Jelen from comment #4) > I don't know how and if it is related to XMODIFIERS or how is it done, but I > have different machines and under Gnome it never happened, to me to have > problem with colours of vim. This does not seem to be truth. Try to ssh to CentOS machine from gnome-terminal (with dark background). And the bug 1159920 sounds like this has been pain historically even on local box.
Please don't use COLORFGBG. It's a terrible hack that doesn't work when you change the settings at runtime. There's a xterm escape sequence that terminals use to communicate the color set. Problem is that some terminals don't support the "\033]11;?\007" sequence when they set TERM=xterm. VTE (gnome-terminal, xterm) however works well and other terminals should be fixed. See bug #1159920
(In reply to Lubomir Rintel from comment #9) > Please don't use COLORFGBG. Lubomir, I believed we could manage to make this work against older systems like CentOS 5/6 -- allowing ssh server accept COLORFGBG is much easier task than updating vim to know how to ask the terminal what background color is currently used. > It's a terrible hack that doesn't work when you change the settings at > runtime. There's a xterm escape sequence that terminals use to communicate > the color set. As long as vim is sensitive to COLORFGBG, it is absolutely harmless variable which may be passed through ssh. Who plans to change COLORFGBG at vim's runtime? It's inherited from shell environment and if konsole changes background, its not changed in vim. The fact is that 'konsole' already automatically exports COLORFGBG now. > Problem is that some terminals don't support the "\033]11;?\007" sequence > when they set TERM=xterm. VTE (gnome-terminal, xterm) however works well and > other terminals should be fixed. > > See bug #1159920 Other terminals might be fixed -- I payed attention to fix konsole if you read this bug carefully -- but sufficiently new vim won't be distributed on older boxes.
Pavel, can this be closed or reassigned to you ?
The important patch is now in RHEL7+ vim, and recent Fedora boxes. Konsole in KDE is fixed as well in Fedora. This is fixed from my POV.