Bram Moolenaar wrote:
> 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?
not really - I posted a summary recently on comp.os.linux.x July 7.
google is filtering out most of my postings however - here's the
text fwiw:
>From dickey Sat Jul 7 12:00:11 2007
From: Thomas Dickey <[EMAIL PROTECTED]>
Subject: Re: X graphics
Newsgroups: comp.os.linux.x
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Organization: RadixNet Internet Services
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (SunOS/
5.8 (sun4u))
Status: RO
Content-Length: 937
Lines: 23
Dances With Crows <[EMAIL PROTECTED]> wrote:
> xterm shouldn't be difficult to compile from source. It's very strange
> that Ubuntu didn't turn on 256-color support. Google for 256colors2.pl
Since it's an option, it's up to the packager.
> and run that in your xterm, you should see a definite difference in the
> 6 color squares. (konsole now seems to support 256 colors, something
> that wasn't true a few years ago....)
They added xterm 256-color support a year ago (it's incomplete - uses
a
hardcoded palette - but is usable if you're not picky).
The same comment applies to pterm (which - looking at ps's output -
uses
about 60% more memory than xterm configured for 256-colors).
gnome-terminal implements a hardcoded 88-color palette (still based on
xterm).
Like konsole, it uses (even) more memory but comes with prettier
menus.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
> > + 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
-~----------~----~----~----~------~----~------~--~---
