[EMAIL PROTECTED] wrote:
Hi Vimmers,
Recently, I've been thinking what this option is designed for.
The document saids that:
when 'background' is set Vim will adjust the default color groups for the
new value. But the colors used for syntax highlighting will not change.
But in fact, I had tested and found that when I set the 'background'
option, Vim will source the color scheme script again. The idea seems to be
good, if the color scheme script reads the 'background' option and set a
different color according to the option everything should work...
However, we could imagine... what will happen if I set background=light
while the color scheme set background=dark inside the script? When we set
background=light in command line, the script will be launched, and the
background set to dark. then we will never be able to set background=light.
Then, if another color scheme wants the value, it will always get
background=dark even if the user set background=light. (Okay the "System"
will try to set the 'background' option too, and that will more more
confusing...)
So, is 'background' option designed so that the color scheme should not
read or write it at all? In my opinion it is introducing more confusing
than good if it works this way.
Could anyone explains what this option "exactly" means and what it is
designed to and how should we use it? I've been quite confused now.
--
Sincerely, Pan, Shi Zhu. ext: 2606
'background' _tells_ vim whether the current default background is _currently_
dark or light.
When gvim starts, it sets the default colors (for the Normal group and for any
other group not having guibg= guifg= ) to guibg=white guifg=black, and
'backgound' to "light".
When console Vim starts, it's not so easy. The current background and
foreground are set by the underlying OS or terminal-emulator, and Vim tries to
find out what they are set to. Depending on the underlying OS and terminal, it
may or may not be possible to determine exactly what the current background is
set to. If it cannot find out, Console Vim assumes that it is loaded in what
used to be the "hardware" default colors of text terminals -- light grey on
black for a color console, amber or green or grey on black for a monochrome
console -- and sets 'background' to "dark".
When creating a colorscheme, the following philosophies are possible:
a) Set the Normal group to always the same defaults, and set 'background'
accordingly. This is the simplest possibility, but it does _not_ let the user
choose between "dark" and "light" versions of a single colorscheme, and it may
look ugly on some console displays, depending on how the author's choices
"marry" with the terminal's capabilities.
b) Accept the current user-set setting of 'background' (and possibly the
user-set highlight for the Normal group), and define the highlight groups
accordingly:
- some highlight groups may have both ctermbg/guibg and ctermfg/guifg set
- if setting ctermbg/guibg for the Normal group, it should be set to a
"brighter" colour if 'background' is "light", and to a "darker" colour if
'background' is "dark".
- when not setting ctermbg/guibg for some group, ctermfg/guifg should be set
to a relatively "darker" colour if 'background' is set to "light", or to a
relatively "brighter" colour if 'background' is set to "dark".
This second method is the most versatile, but in effect it doubles the
workload of the colorscheme author, since the single colorscheme script must
contain two sets of settings for cterm and also two sets for gui.
c) Start the colorscheme with
hi clear Normal
set bg&
hi clear
to reset every color not set by the colorscheme to the program-startup
defaults. Then proceed as in (b) above. When used in a cterm, this third
method assumes that when "set bg&" 'guesses' whether the current Normal
background is light or dark, the result can be accepted. This is what the
"default" colorscheme does (and some others like my "almost-default" which has
been circulated as an attachment to some of my posts in this list); it may be
off on some terminal emulators, if they start with a dark-on-bright setting
and don't (or can't) respond properly to a program's query about "what are the
current display colors set to?".
This third method is less versatile than the second but less frozen than the
first one. It lies more or less halfway between them in terms of workload for
the colorscheme author, since in most cases it must take into account the
possibilities cterm/dark cterm/light and gui/light (and possibly term/dark if
it wants compatibility with monochrome text displays). The user has no choice
over whether a dark or light background is used, except by changing the cterm
colours before starting console Vim. This third method is also the only one of
the three where Vim may have to "guess" what the system colours are set to,
and this introduces the risk of guessing wrong.
If the colorscheme you are using uses this third method, and makes the wrong
guess on the terminal you are using, then your possibilities are as follows:
- c1) Select another predefined colorscheme, either one of those distributed
with Vim (in $VIMRUNTIME/colors) or one which you may have downloaded
separately (e.g. from vim-online or from some user site) into the colors/
subdirectory of a directory mentioned in 'runtimepath' but other than $VIMRUNTIME.
- c2) Copy your current colorscheme under a new name to ~/.vim/colors (on
Unix) or ~/vimfiles/colors (on Windows), and edit it there until you"re
content with what it produces.
- c3) Write your own colorscheme from scratch, and put it (with a filename
ending in .vim) in the directory mentioned in (c2) above. After you test it
thoroughly, you can make it available for all users on your system by moving
it to $VIM/vimfiles/colors (if you have file-creation permissions there)
and/or make it available for all Vim users by (c3a) uploading it on your user
website, (c3b) uploading it at vim-online, and/or (c3c) sending it to Bram for
inclusion into the "official" Vim distributions.
Notes:
- ":highlight clear", when used without a highlight group name, resets all
default colours to predominantly bright-on-dark or dark-on-bright colours,
depending on the current setting of 'background'. These are what I call the
"Vim default" colors for all predefined groups. It also undefines all
highlight groups "invented" by the user or by syntax scripts.
- ":set bg&" tries to guess whether the current terminal default are
bright-on-dark or dark-on-bright. IIUC, this always gives "light" for the GUI,
whose default colors are black on white. As said above, in a console the guess
is usually right, but in some cases it may go wrong.
- IIUC, the following commands
hi clear {group-name}
and
hi {group-name} term=NONE cterm=NONE gui=NONE guibg=NONE guifg=NONE
are equivalent; they reset the colors for {group-name} to the OS or
terminal-emulator defaults (which may or may not be the same as the Vim
defaults for {group-name}). (I "think" I read the help correctly in
understanding that ctermbg=NONE and ctermfg=NONE are not syntactically valid
settings, but I'm not 100% sure that I understood it correctly.)
Best regards,
Tony.
