Matthew Wozniski wrote:
> Now that 88 and 256 color terminals are so ubiquitous, I find it
> frustrating that very few colorschemes support 256 color terminals.
> Unfortunately, writing a colorscheme that properly supports gvim, 88
> color terminals, and 256 color terminals requires looking up the color
> cube number that you want on at least one colorcube and often
> including scripting logic in the colorscheme itself to handle
> converting to the other cube (a la desert256 and inkpot).
>
> This patch intends to make it much easier to write 88 and 256 color
> schemes. This will allow a colorscheme author to write, for instance
> hi Normal cterm=none ctermfg=black ctermbg=#fffdfa
> and have vim behave as though the user had typed
> hi Normal cterm=none ctermfg=0 ctermbg=231
> (or, for 88 colors, hi Normal cterm=none ctermfg=0 ctermbg=79)
> based on the value of the t_Co setting.
>
> Not only does this take out the entire intermediate step of looking up
> colorcube values, it also will report the color that it chose as
> a cterm colorcube number when queried, making it very easy to tweak
> a single value to something the author feels more appropriate.
>
> Also, it is quite easy to convert an existing colorscheme to work with
> this patch; it usually is as simple as running a substitute:
> :%s/cterm.\{-}=.\{-}\>//g
> :%s/gui\zs\(fg\|bg\)\?=.\{-}\>/& cterm&/g
>
> I hope that others find this useful enough to include in future Vim
> releases. To that end, it also includes a patch to the relevant
> documentation, as well as a patch to the vim.vim syntax file to no
> longer highlight ctermfg=#rrggbb as an error.
>
> Feedback greatly appreciated.
Interesting idea. It's certainly more convenient to use the #rrggbb
value than looking up the number. Especially since the number depends
on the terminal, 88 or 256 colors.
Taking this a step further: We could also make it work for 8 and 16
color terminals. Instead of "blue" you would use #0000ff. Not sure how
complicated this will get though. And for an 8 color terminal one would
still need to tune the colors.
Do all the terminals supporting 88 and 256 colors really use the same
color values?
> + This works by attempting to gracefully degrade the specified color to
> + a similar available color. In practice, you will likely not get
> + exactly the color you ask for; you will get the closest color that
> + your terminal emulator supports. If your terminal emulator does not
> + report supporting at least 88 colors, this will fail. If you are
> + certain that your terminal emulator does support 88 or more colors,
> + a possible workaround might be to set t_Co in your .vimrc, for
> + instance: >
> + if $TERM =~ 'xterm'
> + set t_Co=256
> + endif
If the xterm was compiled properly Vim can request it to send the number
of colors being used. See ":help xterm-codes". Unfortunately
termcap/terminfo are totally useless for these things.
The stuff to haneld grey and non-grey colors looks like a bit of a hack.
Isn't there a more consistent solution?
> + if (hex[i] >= '0' && hex[i] <= '9')
> + *(rgb+i/2) += (hex[i] - '0') * order;
> + else if (hex[i] >= 'A' && hex[i] <= 'F')
> + *(rgb+i/2) += (hex[i] - 'A' + 10) * order;
> + else if (hex[i] >= 'a' && hex[i] <= 'f')
> + *(rgb+i/2) += (hex[i] - 'a' + 10) * order;
You can use hexhex2nr() here.
I would appreciate some people trying this on various terminals to check
that it really works. Perhaps you can write a color scheme that uses
the RGB values for people to try out?
--
>From "know your smileys":
|-( Contact lenses, but has lost them
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
