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.
Add the most recent rgb.txt from upstream as part of the package,
installed to ~/.vim. Accordingly, CSApprox.vim will now search in all
dirs in &rtp, in order, before deciding that no rgb.txt could be found.
- Update "Last Changed", version number, and changelog
- Suggest installing larger vim packages as a workaround for no +gui
- Modify the way g:CSApprox_verbose_level works; now 'verbose' is set to
the max of that variable and &verbose
- Fix a minor bug causing a complaint that not enough colors are
available when changing colorschemes after a :gui
- Fix some comments
As reported by A. S. Budden, CSApprox caused the set GUI colors to be
overwritten when the cterm colors were set. This happened because vim
attempts to reset some colors back to their defaults whenever the colors
for the Normal group change by calling syntax/syncolor.vim (I couldn't
find any documentation that explained this behavior). The global
syncolor.vim allows any syncolor.vim before it in the runtimepath to
override its behavior by setting the variable g:syntax_cmd to something
not recognized, so I now work around this problem by doing exactly that
for the duration of the run.
See http://groups.google.com/group/vim_use/msg/2c6a7f5917f76057
Before, we would break the loop if we hit a highlight group with an
empty name. In that case, we should actually continue the loop.
I moved the loop index increment to the beginning of the loop to make
this easier.
The default approximator has been modified to cache both the sorted list
of all possible components and the closest cterm color to a given rgb
color - drops execution time by about one quarter.
Vim allows highlight groups with no name to be created; but doesn't
support getting any information for them. Two commas in a row in a
"syn match" creates a new highlight group that's named "". This bug is
triggered by the distributed doxygen.vim.
syn match doxygenStartSkip2 +^\s*\*$+ contained
\ nextgroup=doxygenBody,doxygenStartSpecial,,doxygenStartSkip skipwhite skipnl
^^
