Until now, "gui=reverse" was translated to "ctermbg=fg ctermfg=bg", but
Will Gray (graywh) pointed out to me that this is wrong, since there are
many terminal emulators that do properly handle reverse video.
Whenever you change the Normal highlight group, vim always changes 'bg'
to light; try:
vim -u NONE -N -c 'set bg=dark' -c 'hi Normal ctermbg=16 ctermfg=255'
This change just makes CSApprox save/restore 'bg' before/after changing
the highlight groups.
Suggestion made by Kris Malfettone (and I'm sure that someone else
pointed this issue out to me in the past, but I didn't act on it then
and forgot who you are, so I'm sorry for not crediting you).
Before, this test would be short-circuited only if gvim was running.
This caused vim to still complain when run as "vim -r" (which apparently
loads plugins, presumably to set up the proper 'directory' path...).
So, I've changed the short circuiting to happen whenever t_Co is the
empty string, which happens to be true both for gvim (which
understandably doesn't do the terminal initialization stuff) and for vim
-r (which largely inexplicably skips terminal initialization).
This was causing problems when running in Vim 7.0 or 7.1. graywh
bisected down to the commit introducing it for me, (d2c906) making it
easy to spot the problem.
Not useful to keep it in one file anymore, since we already rely upon
multiple, and this will make later extending easier by giving us some
library functions for approximators.
Some colors are used by name in the default colorschemes. Duplicate these in
their own table, to avoid loading entire rgb.txt list unless it's really
necessary.
Before, each call to s:attr_map() would make sure that the things being
mapped from and to were valid. Optimize this by making sure all at once
that all things being mapped from, and all things being mapped to, are
valid, before using any attributes.
Instead of sorting the entire list of all highlight groups in order to
make sure that Normal is handled first, just pluck out the Normal group
from the list and move it to the front. Seems to be slightly better for
speed, and yields slightly more readable code anyway.
Modify s:Highlights() to only check modes it's explicitly told to.
s:CSApproxImpl() needs only gui colors, s:CSApproxSnapshot() needs gui,
cterm, and term.
After 4091aca090 dumping colors with
CSApproxSnapshot was completely broken. That commit stopped changing
&t_Co from reverting changes to colors not made by the colorscheme by
preventing the colorscheme from being re-sourced every time &t_Co
changed. Unfortunately, that stopped the ColorScheme autocmd from
firing, which stopped s:CSApprox() from calculating the colors, which
meant we would dump the same colors regardless of &t_Co, and regardless
of {xterm,konsole,eterm}.
Fix this problem by calling s:CSApprox() explicitly after changing &t_Co
Replace the logic of searching for an rgb.txt file on the system with
making a call to the 'showrgb' binary on the system and parsing its
output. This should be available on all X11 systems, regardless of
whether or not the system has rgb.txt.
This bug would stop CSApprox from ever choosing #080808 (or the lowest
color on the greyscale ramp of another palette) as the closest match for
any color.
CSApproxSnapshot should make a snapshot of the currently used colors,
rather than the colors defined in the colorscheme. But, when
CSApproxSnapshot() changed &t_Co, the scheme was reloaded, causing :hi
clear to run and delete all colors. Definitely not desired. Stop that
from happening in the same way as it is prevented in CSApprox().
Bump version numbers and timestamps.
Massive documentation update to make CSApproxSnapshot well-documented,
rather than just a side-note.
Add a slight tweak to the plugin to match the updated docs: it's no
longer enough for g:CSApprox_eterm or g:CSApprox_konsole to simply
exist, they must also evaluate as True.
Before, snapshotted schemes could contain guisp= attributes, or
term=undercurl, which caused errors when used with vim 6. Now, if the
colorscheme detects that vim 6 is running, it will strip those from the
:highlight commands that get used. More incompatibilities might exist
that I can't think of, though...
And, add logic to snapshotted schemes to make them recognize konsole and
eterm in the same way as CSApprox proper, and, if they're found, use the
appropriate colors.
Before, snapshots wouldn't work right for high color schemes, since
CSApproxImpl aborted early when a high color was found. If the user
wanted this, though, they wouldn't have called CSApproxSnapshot. So,
skip this logic in that case.
This was set up to allow CSApproxImpl() to run if either t_Co was set to
88 or 256, or if we were running in gui vim. Presumably this was added
for CSApproxSnapshot, but that sets t_Co to something sane even in gvim.
This was causing errors slightly later when t_Co was unset.
Thank goodness I caught this before releasing CSApprox 2.0! Two
misplaced lines meant that it would crap all over already 256 color
themes, like inkpot.vim and vividchalk.vim, because they cleared the old
cterm colors before the test that made sure that none of the old cterm
colors were over 15.
Now it's much less hacky, and looks much more like a well-designed
feature. I doubt it's perfect, but it seems to work well in every test
case I have, as long as it's run from gvim. I've discovered that it
doesn't work when run from terminal vim, and it seems unlikely that it
ever will - it's capable of spitting out the right cterm colors in that
case, but can't reproduce the proper gui colors.
Docs are updated to reference the required patch number (7.2.052) and
the code is updated to test based on the existence of that patch, rather
than brute forcing.
Added a new function, CSApproxSnapshot(filename [, force=0]). This
function will take the current colors and dump them out to a new
colorscheme script stored at `filename', unless that file already exists
and `force' is not set. This may still have some bugs to work out, I'm
surprised it was this easy... Not surprisingly, it falls apart if the
colorscheme didn't set g:colors_name... And it doesn't handle
highlights the user made himself, outside of the scheme. Still, it's
a good first draft.
