13

While trying to match up my terminal's colour palette and GVim's I noticed this:

  1. When I open GVim and Vim, I see: enter image description here (That's the same file, my vimrc.)
  2. If I do :set t_Co=256, nothing happens in GVim (except it blinks), whereas the colours in the terminal now look different. If I do :set bg=dark now, it makes no difference (again GVim blinks). If I then do :set bg=light and then :set bg=dark again, I get: enter image description here

Both :set bg=dark and :set t_Co=256 are present in my vimrc. Why aren't my :set bg and :set t_Co sticking, and why does setting :set bg=dark again after :set bg=light make a difference where it originally didn't?

I'm using Arch Linux, the terminal is GNOME Terminal, and I don't have a .gvimrc.

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Feb  4 2015 08:03:11)
Included patches: 1-617
Compiled by Arch Linux
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
+balloon_eval    +float           +mouse_urxvt     -tag_any_white
+browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         +gettext         -mzscheme        +textobjects
+clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      +toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       -python          +viminfo
+cscope          +lispindent      +python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con_gui  +lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      +X11
+dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     +xim
+emacs_tags      +mouseshape      -sniff           +xsmp_interact
+eval            +mouse_dec       +startuptime     +xterm_clipboard
+ex_extra        +mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "/etc/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz  -D_FORTIFY_SOURCE=2  -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE  -Wl,-O1,--sort-common,--as-needed,-z,relro -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype  -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm -lncurses -lelf -lnsl   -lacl -lattr -lgpm -ldl  -L/usr/lib -llua -Wl,-E -Wl,-rpath,/usr/lib/perl5/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro -fstack-protector -L/usr/local/lib  -L/usr/lib/perl5/core_perl/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc  -L/usr/lib/python3.4/config-3.4m -lpython3.4m -lpthread -ldl -lutil -lm  -lruby -lpthread -lgmp -ldl -lcrypt -lm  -L/usr/lib

1 Answer 1

10
  1. The elflord colorscheme does set background=dark. Since it is sourced after your set bg=light it will override it.

  2. set t_Co=256 is pointless. It doesn't do anything in GVim and you should set your terminal emulator up properly instead.

    Also, elflord only uses basic ANSI colors in color terminals so it doesn't really matter if you force Vim to see 256 colors or if you set your TERM to a 256colors value; your colorscheme won't use that extended palette anyway. What happens instead is that your original TERM is probably xterm or screen or some other value that restricts Vim to 8 colors. But Elflord uses both "dark" and "light" colors which need a TERM above 8. So, forcing 256 colors will alter your colors.

  3. Recommendations:

    • Don't change the value of 't_Co'.
    • Don't set background.
4
  • 1
    If elflord sets bg to dark, why does its appearance change if I set it to light and back again? Note that my vimrc does not do set bg=light.
    – muru
    Commented Feb 18, 2015 at 8:23
  • set bg changes the colors and attributes of some highlight groups so that they work better on dark or light background. It is mostly arbitrary and may or may not have an effect depending on the colorscheme you use. Messing with that option is not a good idea.
    – romainl
    Commented Feb 18, 2015 at 9:20
  • 1
    I followed your advice on bg and t_Co. I'm just wondering why elflord's set bg=dark and mine cause such differing (yet repeatable) results?
    – muru
    Commented Feb 18, 2015 at 9:24
  • 3
    It's the order in which they are applied. Because one is not the exact opposite of the other switching multiple times between "dark" and "light" is not a toggle between two definite and stable states.
    – romainl
    Commented Feb 18, 2015 at 9:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.