Patch to allow ctermfg or bg values as #rrggbb
Locked
12
12
Patch to allow ctermfg or bg values as #rrggbb
 
|
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. ~Matt Wozniski --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- Index: runtime/doc/syntax.txt =================================================================== --- runtime/doc/syntax.txt (revision 647) +++ runtime/doc/syntax.txt (working copy) @@ -3940,6 +3940,30 @@ Unfortunately this means that it's not possible to get the same colors for each user. See |xterm-color| for info about color xterms. + *E805* *ctermfg-hex* *ctermbg-hex* + Many modern terminals, including recent versions of XTerm, URxvt, + PuTTY, GNOME Terminal, and Konsole, support 88 or 256 colors. If + your terminal supports at least 88 colors, you can also specify + a color by its Red, Green and Blue values. + The format is "#rrggbb", where + "rr" is the Red value + "gg" is the Green value + "bb" is the Blue value + All values are hexadecimal, range from "00" to "ff". Example: > + :highlight Comment ctermfg=#11f0c3 ctermbg=#ff00ff +< *E804* + 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 +< The MSDOS standard colors are fixed (in a console window), so these have been used for the names. But the meaning of color names in X11 are fixed, so these color settings have been used, to make the Index: runtime/syntax/vim.vim =================================================================== --- runtime/syntax/vim.vim (revision 647) +++ runtime/syntax/vim.vim (working copy) @@ -437,10 +437,10 @@ syn case match syn match vimHiFontname contained "[a-zA-Z\-*]\+" syn match vimHiGuiFontname contained "'[a-zA-Z\-* ]\+'" -syn match vimHiGuiRgb contained "#\x\{6}" if !exists("g:vimsyntax_noerror") syn match vimHiCtermError contained "[^0-9]\i*" endif +syn match vimHiRgb contained "#\x\{6}" " Highlighting: hi group key=arg ... {{{2 syn cluster vimHiCluster contains=vimHiGroup,vimHiTerm,vimHiCTerm,vimHiStartStop,vimHiCtermFgBg,vimHiGui,vimHiGuiFont,vimHiGuiFgBg,vimHiKeyError,vimNotation @@ -451,10 +451,10 @@ syn match vimHiTerm contained "\cterm="he=e-1 nextgroup=vimHiAttribList syn match vimHiStartStop contained "\c\(start\|stop\)="he=e-1 nextgroup=vimHiTermcap,vimOption syn match vimHiCTerm contained "\ccterm="he=e-1 nextgroup=vimHiAttribList -syn match vimHiCtermFgBg contained "\ccterm[fb]g="he=e-1 nextgroup=vimNumber,vimHiCtermColor,vimFgBgAttrib,vimHiCtermError +syn match vimHiCtermFgBg contained "\ccterm[fb]g="he=e-1 nextgroup=vimNumber,vimHiCtermColor,vimHiRgb,vimFgBgAttrib,vimHiCtermError syn match vimHiGui contained "\cgui="he=e-1 nextgroup=vimHiAttribList syn match vimHiGuiFont contained "\cfont="he=e-1 nextgroup=vimHiFontname -syn match vimHiGuiFgBg contained "\cgui\%([fb]g\|sp\)="he=e-1 nextgroup=vimHiGroup,vimHiGuiFontname,vimHiGuiRgb,vimFgBgAttrib +syn match vimHiGuiFgBg contained "\cgui\%([fb]g\|sp\)="he=e-1 nextgroup=vimHiGroup,vimHiGuiFontname,vimHiRgb,vimFgBgAttrib syn match vimHiTermcap contained "\S\+" contains=vimNotation " Highlight: clear {{{2 @@ -602,7 +602,7 @@ hi def link vimHiGroup vimGroupName hi def link vimHiGuiFgBg vimHiTerm hi def link vimHiGuiFont vimHiTerm -hi def link vimHiGuiRgb vimNumber +hi def link vimHiRgb vimNumber hi def link vimHiGui vimHiTerm hi def link vimHiStartStop vimHiTerm hi def link vimHLGroup vimGroup Index: src/syntax.c =================================================================== --- src/syntax.c (revision 647) +++ src/syntax.c (working copy) @@ -448,6 +448,9 @@ static int get_id_list __ARGS((char_u **arg, int keylen, short **list)); static void syn_combine_list __ARGS((short **clstr1, short **clstr2, int list_op)); static void syn_incl_toplevel __ARGS((int id, int *flagsp)); +static int cube_nr_is_grey __ARGS((char_u nr)); +static char_u closest_cube_step __ARGS((short size, char_u component, int skip_grey)); +static int approximate_cterm_from_gui __ARGS((char_u* hex)); /* * Start the syntax recognition for a line. This function is normally called @@ -6952,6 +6955,13 @@ if (VIM_ISDIGIT(*arg)) color = atoi((char *)arg); + else if (*arg == '#') + { + if ((color = approximate_cterm_from_gui(arg)) == -1) { + error = TRUE; + break; + } + } else if (STRICMP(arg, "fg") == 0) { if (cterm_normal_fg_color) @@ -9118,6 +9128,186 @@ } #endif +/* + * The majority of colors in both the 256 color colorcube and the 88 color + * colorcube can only be used in greys. That is, even though 0xEE might be + * valid to use in a color, it can only be used as 0xEEEEEE. This function + * returns true if a particular r/g/b val can only be combined with itself. + */ + static int +cube_nr_is_grey(nr) + char_u nr; +{ + /* + * Only the 8 colors below can be used outside of greys, including both + * 256 color and 88 color cubes. There is no place where a grey-only color + * on one cube can be mix-and-matched on the other, so this simplistic + * solution works. + */ + return (nr != 0x00 && nr != 0x8B + && nr != 0xCD && nr != 0xFF + && nr != 0x5F && nr != 0x87 + && nr != 0xAF && nr != 0xD7); +} + +/* + * Given an r, g, or b component and a colorcube size to use, this function + * will return a number representing the closest colorcube value to that + * component. If skip_grey is true, it will not return a grey. If the return + * value is greater than or equal to 80, it is the colorcube value of a grey, + * otherwise it will be in the range [0-5] for a 256 color colorcube, and + * [0-3] for an 88 color colorcube; an index along a side of the cube. + */ + static char_u +closest_cube_step(size, component, skip_grey) + short size; + char_u component; + int skip_grey; +{ + /* All possible steps on an 88 color colorcube */ + static char_u vals_88[12] = { 0x00, 0x2E, 0x5C, 0x73, 0x8B, 0xA2, + 0xB9, 0xCD, 0xD0, 0xE7, 0xFF }; + + /* And on a 256 color colorcube */ + static char_u vals_256[30] = { 0x00, 0x08, 0x12, 0x1C, 0x26, 0x30, + 0x3A, 0x44, 0x4E, 0x58, 0x5F, 0x62, + 0x6C, 0x76, 0x80, 0x87, 0x8A, 0x94, + 0x9E, 0xA8, 0xAF, 0xB2, 0xBC, 0xC6, + 0xD0, 0xD7, 0xDA, 0xE4, 0xEE, 0xFF }; + + unsigned i, end, n_color, n_grey, grey; + char_u *list; + + n_color = n_grey = 0; + + if (size == 88) + { + end = 11; + list = vals_88; + } + else + { + end = 30; + list = vals_256; + } + + for (i = 0; i < end - 1; /*NOP*/) + { + int j = 1; + + if (cube_nr_is_grey(list[i])) + ++n_grey; + else + ++n_color; + + while (skip_grey && cube_nr_is_grey(list[i+j])) + { + ++n_grey; + ++j; + } + + /* The component is closest to list[i] if it is less than or equal to + * the midpt of list[i] and list[i+1] */ + if (component <= (list[i] + list[i+j]) / 2) { + grey = cube_nr_is_grey(list[i]); + break; + } + + i += j; + } + + + if (i == end - 1) + /* Last one is a color on both cubes, and it wasn't yet counted so we + * don't subtract 1 */ + return n_color; + else if (!grey) + return n_color - 1; + else + return (size == 88 ? 80 : 232) + n_grey - 1; +} + +/* + * Given a hex color of the form "#rrggbb", returns the closest cterm color on + * the currently available colorcube (based on &t_Co). This will only work if + * the current number of colors is greater than or equal to 88; it returns an + * error code of -1 upon failure. + */ + static int +approximate_cterm_from_gui(hex) + char_u* hex; +{ + int i; + char_u rgb[3] = { 0, 0, 0 }; // These each store { rr, gg, bb } + char_u vals[3]; + unsigned colors; + + colors = t_colors; +#ifdef FEAT_GUI + /* + * Don't ever give E805 error in gui, just pick a reasonable colorcube. + * Otherwise, colorschemes that set ctermfg=#rrggbb will give errors when + * used in the gui. + */ + if (colors < 88 && gui.in_use) + colors = 256; +#endif + + if (colors < 88) + { + EMSG(_("E804: Too few terminal colors")); + return -1; + } + + if (*hex == '#') + ++hex; + + for (i = 0; i < 6; ++i) { + int order = (i%2 ? 1 : 16); + + 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; + else + break; + } + + /* Too few characters, too many, or not all in [0-9A-Fa-f] */ + if (i != 6 || hex[6] != NUL) { + /* Should this get a new error number, or should I reuse E254? */ + EMSG(_("E805: Bad color spec provided.")); + return -1; + } + + vals[0] = closest_cube_step(colors, rgb[0], FALSE); + vals[1] = closest_cube_step(colors, rgb[1], FALSE); + vals[2] = closest_cube_step(colors, rgb[2], FALSE); + + if (vals[0] != vals[1] || vals[1] != vals[2]) + { + /* + * The author obviously didn't want a grey, and having #003000 rounded + * to #121212 rather than #005F00 bothers me. Search again, skipping + * grey-only values. This extra search just guarantees that unless the + * requested color is sufficiently close to a grey, we will use + * a color, even if it's further away. + */ + vals[0] = closest_cube_step(colors, rgb[0], TRUE); + vals[1] = closest_cube_step(colors, rgb[1], TRUE); + vals[2] = closest_cube_step(colors, rgb[2], TRUE); + } + + if (vals[0] == vals[1] && vals[1] == vals[2] && vals[0] >= 80) + return vals[0]; + else if (colors == 88) + return (vals[0] * 16 + vals[1] * 4 + vals[2] + 16); + else + return (vals[0] * 36 + vals[1] * 6 + vals[2] + 16); +} + #if defined(FEAT_GUI) || defined(PROTO) /* * Free all the highlight group fonts. |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
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 -- [hidden email] -- 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 -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
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 <[hidden email]> Subject: Re: X graphics Newsgroups: comp.os.linux.x References: <[hidden email]> <[hidden email].> 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 <[hidden email]> 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 -- [hidden email] -- 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 -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Bram Moolenaar
On Sun, Nov 11, 2007 at 01:24:11PM +0100, Bram Moolenaar wrote:
> > 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. That's a bit tough, since we would need to either be able to query the current value of each of the &t_Co colors from the terminal emulator (which AFAIK isn't portable across all TE's; see below) or make an assumption about what each of those colors are (which is a bad idea, since everyone I know who spends significant time in the terminal has tweaked those 16 colors to be good for his own eyes; not to mention that most TE's use different defaults, especially between those that default to a light background vs those that default to a dark one). Another hurdle with supporting this for 16 color terminals is that there are really *very* few colors available. Any colorscheme that tries to subtly vary colors, for instance using many shades of red, would just look awful when there are only 2 reds to choose from. Also, we already support color names for 8 and 16 color terminals. My humble opinion is that it is too much work with too many hurdles to bother implementing for 16 color terminals, especially since we can already use names rather than numbers. > Do all the terminals supporting 88 and 256 colors really use the same > color values? Well... As far as I can tell, they seem to _default_ to the same values. In the interest of researching this properly, I've source-dived a few to be sure. GNOME Terminal: same palette as xterm-256color (vte.c:2399) PuTTY (pterm): same palette as xterm-256color (gtkwin.c:1432) Mrxvt: same palette as xterm-256color (init.c:110) Rxvt-unicode: 88 colour palette (init.C:74). A quick scan through the Konsole sources didn't turn up the spot where they set up the default sources, but there is a note in README.moreColors saying "There is a predefined 256 color space compatible with his xterm sister", which I read as saying that colors 16 through 255 are compatible with those in xterm. Are there any other terminals supporting more than 16 colors that I should check out? Now, the patch I submitted used the simplifying assumption that the user did not _change_ the colors in the cube or greyscale ramp (which is possible in xterm through resources or control sequences, urxvt using at least control sequences, and through some means in konsole, I believe). I agree that it would be better if we could query for the current values, and work with those rather than the defaults. That's possible for xterm and urxvt, at least, using ESC ] 4;17;? BEL. It's slightly more complicated when running inside gnu screen, though, since you have to tell screen to output that sequence to the TE that it's running in directly, without interpreting it itself, using ESC P ESC ] 4;17;? BEL ESC \. So, then, the issue is.. How do we know when we can query, and what sequence to use to do it? Is there a standard idiom for this? As far as I know, this is still a very hairy issue, since we can't trust terminfo/termcap, and exported environment variables only get you so far... Also, perhaps more importantly, even if we can check, when should we do it? It doesn't seem that we can reasonably handle it if, for instance, the user enters Vim, suspends it, changes a color, and then foregrounds Vim again. Should we only check when Vim is started? If we decide that checking the current colors is reasonable, I would venture that the most reasonable time to check is on each :highlight command, since in the event that the user does something like changing a color while Vim is still running, it could be fixed by just redoing the :colorscheme command. Would checking once per :highlight be too expensive, though? And, while it's in my head: one *very* cool (albeit tangential) feature would be the ability to dynamically change the xterm colors to match the requested ones. This, however, would be pretty tough to do consistently: we would need to save the values when we start and restore them whenever we get a signal, or whenever we execute a command with :! when using an xterm with altscreen support, and it would need to be controlled by an option, since it would affect, for instance, all screens in gnu screen, not just the current one. Off topic at the moment, but it might be worth some more consideration in the future, especially since it would mean that we could even make very pretty colorschemes in 16 color terminals that support dynamically changing those colors. > > + 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. problem as above. I don't know that it's sufficiently generic, and a pointer in the help seems like a better idea... > The stuff to haneld grey and non-grey colors looks like a bit of a hack. > Isn't there a more consistent solution? I'm open to suggestions. A better solution might be to figure out if the author probably wanted a grey, by saying for instance, abs(r-b) < 16 && abs(b-g) < 16 && abs(g-r) < 16 and then filtering for lowest Euclidean distance in rgb space, excluding greys if necessary. Either way, it's not worth focusing on if we plan to support customized, as opposed to default, palettes. The algorithm will need complete retooling; the current algorithm does revolve quite tightly around the standard values. > > + 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 figured there was a utility function around for this and I just couldn't find it. Looking at the #if defined()'s around hexhex2nr, what #defines are paired with this cterm[fb]g=#rrggbb feature? Is it just #ifndef ALWAYS_USE_GUI, or is there something else that needs to be considered? Is this useful in windows builds, for instance? > 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? Absolutely. I've attached copies of my two favorite colorschemes, brookstream for dark terminals and autumnleaf for light terminals, each modified to work with cterm[fb]g=#rrggbb values. They'll work in a patched vim, in both an 88 or 256 color terminal or in gvim, but they won't work in an 8 or 16 color terminal. ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- " Vim color file " Maintainer: Anders Korte " Last Change: 17 Oct 2004 " AutumnLeaf color scheme 1.0 set background=light hi clear if exists("syntax_on") syntax reset endif let colors_name="autumnleaf-rgb" " Colors for the User Interface. hi Cursor ctermbg=#aa7733 guibg=#aa7733 ctermfg=#ffeebb guifg=#ffeebb cterm=bold gui=bold hi Normal ctermbg=#fffdfa guibg=#fffdfa ctermfg=black guifg=black cterm=none gui=none hi NonText ctermbg=#eafaea guibg=#eafaea ctermfg=#000099 guifg=#000099 cterm=bold gui=bold hi Visual ctermbg=#fff8cc guibg=#fff8cc ctermfg=black guifg=black cterm=none gui=none " hi VisualNOS hi Linenr ctermbg=bg guibg=bg ctermfg=#999999 guifg=#999999 cterm=none gui=none " Uncomment these if you use Diff...?? " hi DiffText ctermbg=#cc0000 guibg=#cc0000 ctermfg=white guifg=white cterm=none gui=none " hi DiffAdd ctermbg=#0000cc guibg=#0000cc ctermfg=white guifg=white cterm=none gui=none " hi DiffChange ctermbg=#990099 guibg=#990099 ctermfg=white guifg=white cterm=none gui=none " hi DiffDelete ctermbg=#888888 guibg=#888888 ctermfg=#333333 guifg=#333333 cterm=none gui=none hi Directory ctermbg=bg guibg=bg ctermfg=#337700 guifg=#337700 cterm=none gui=none hi IncSearch ctermbg=#c8e8ff guibg=#c8e8ff ctermfg=black guifg=black cterm=none gui=none hi Search ctermbg=#c8e8ff guibg=#c8e8ff ctermfg=black guifg=black cterm=none gui=none hi SpecialKey ctermbg=bg guibg=bg ctermfg=fg guifg=fg cterm=none gui=none hi Titled ctermbg=bg guibg=bg ctermfg=fg guifg=fg cterm=none gui=none hi ErrorMsg ctermbg=bg guibg=bg ctermfg=#cc0000 guifg=#cc0000 cterm=bold gui=bold hi ModeMsg ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=none gui=none hi link MoreMsg ModeMsg hi link Question ModeMsg hi WarningMsg ctermbg=bg guibg=bg ctermfg=#cc0000 guifg=#cc0000 cterm=bold gui=bold hi StatusLine ctermbg=#ffeebb guibg=#ffeebb ctermfg=black guifg=black cterm=bold gui=bold hi StatusLineNC ctermbg=#aa8866 guibg=#aa8866 ctermfg=#f8e8cc guifg=#f8e8cc cterm=none gui=none hi VertSplit ctermbg=#aa8866 guibg=#aa8866 ctermfg=#ffe0bb guifg=#ffe0bb cterm=none gui=none " hi Folded " hi FoldColumn " hi SignColumn " Colors for Syntax Highlighting. hi Comment ctermbg=#ddeedd guibg=#ddeedd ctermfg=#002200 guifg=#002200 cterm=none gui=none hi Constant ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=bold gui=bold hi String ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=italic gui=italic hi Character ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=italic gui=italic hi Number ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=bold gui=bold hi Boolean ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=bold gui=bold hi Float ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=bold gui=bold hi Identifier ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=none gui=none hi Function ctermbg=bg guibg=bg ctermfg=#0055aa guifg=#0055aa cterm=bold gui=bold hi Statement ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=none gui=none hi Conditional ctermbg=bg guibg=bg ctermfg=#aa7733 guifg=#aa7733 cterm=bold gui=bold hi Repeat ctermbg=bg guibg=bg ctermfg=#aa5544 guifg=#aa5544 cterm=bold gui=bold hi link Label Conditional hi Operator ctermbg=bg guibg=bg ctermfg=#aa7733 guifg=#aa7733 cterm=bold gui=bold hi link Keyword Statement hi Exception ctermbg=bg guibg=bg ctermfg=#228877 guifg=#228877 cterm=bold gui=bold hi PreProc ctermbg=bg guibg=bg ctermfg=#aa7733 guifg=#aa7733 cterm=bold gui=bold hi Include ctermbg=bg guibg=bg ctermfg=#558811 guifg=#558811 cterm=bold gui=bold hi link Define Include hi link Macro Include hi link PreCondit Include hi Type ctermbg=bg guibg=bg ctermfg=#007700 guifg=#007700 cterm=bold gui=bold hi link StorageClass Type hi link Structure Type hi Typedef ctermbg=bg guibg=bg ctermfg=#009900 guifg=#009900 cterm=italic gui=italic hi Special ctermbg=bg guibg=bg ctermfg=fg guifg=fg cterm=none gui=none hi SpecialChar ctermbg=bg guibg=bg ctermfg=fg guifg=fg cterm=bold gui=bold hi Tag ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399 cterm=bold gui=bold hi link Delimiter Special hi SpecialComment ctermbg=#dddddd guibg=#dddddd ctermfg=#aa0000 guifg=#aa0000 cterm=none gui=none hi link Debug Special hi Underlined ctermbg=bg guibg=bg ctermfg=blue guifg=blue cterm=underline gui=underline hi Title ctermbg=bg guibg=bg ctermfg=fg guifg=fg cterm=bold gui=bold hi Ignore ctermbg=bg guibg=bg ctermfg=#999999 guifg=#999999 cterm=none gui=none hi Error ctermbg=red guibg=red ctermfg=white guifg=white cterm=none gui=none hi Todo ctermbg=bg guibg=bg ctermfg=#aa0000 guifg=#aa0000 cterm=none gui=none "-------------------------------------------------------------------- " Name Of File: brookstream.vim. " Description: Gvim colorscheme, works best with version 6.1 cterm . " Maintainer: Peter B�ckstr�m. " Creator: Peter B�ckstr�m. " URL: http://www.brookstream.org (Swedish). " Credits: Inspiration from the darkdot scheme. " Last Change: Friday, April 13, 2003. " Installation: Drop this file in your $VIMRUNTIME/colors/ directory. "-------------------------------------------------------------------- set background=dark hi clear if exists("syntax_on") syntax reset endif let g:colors_name="brookstream-rgb" "-------------------------------------------------------------------- hi Normal gui=none cterm=none ctermbg=#000000 guibg=#000000 ctermfg=#bbbbbb guifg=#bbbbbb hi Cursor ctermbg=#44ff44 guibg=#44ff44 ctermfg=#000000 guifg=#000000 hi Directory ctermfg=#44ffff guifg=#44ffff hi DiffAdd ctermbg=#080808 guibg=#080808 ctermfg=#ffff00 guifg=#ffff00 hi DiffDelete ctermbg=#080808 guibg=#080808 ctermfg=#444444 guifg=#444444 hi DiffChange ctermbg=#080808 guibg=#080808 ctermfg=#ffffff guifg=#ffffff hi DiffText ctermbg=#080808 guibg=#080808 ctermfg=#bb0000 guifg=#bb0000 hi ErrorMsg ctermbg=#880000 guibg=#880000 ctermfg=#ffffff guifg=#ffffff hi Folded ctermfg=#000088 guifg=#000088 hi IncSearch ctermbg=#000000 guibg=#000000 ctermfg=#bbcccc guifg=#bbcccc hi LineNr ctermbg=#050505 guibg=#050505 ctermfg=#4682b4 guifg=#4682b4 hi ModeMsg ctermfg=#ffffff guifg=#ffffff hi MoreMsg ctermfg=#44ff44 guifg=#44ff44 hi NonText ctermfg=#4444ff guifg=#4444ff hi Question ctermfg=#ffff00 guifg=#ffff00 hi SpecialKey ctermfg=#4444ff guifg=#4444ff hi StatusLine gui=none cterm=none ctermbg=#2f4f4f guibg=#2f4f4f ctermfg=#ffffff guifg=#ffffff hi StatusLineNC gui=none cterm=none ctermbg=#bbbbbb guibg=#bbbbbb ctermfg=#000000 guifg=#000000 hi Title ctermfg=#ffffff guifg=#ffffff hi Visual gui=none cterm=none ctermbg=#bbbbbb guibg=#bbbbbb ctermfg=#000000 guifg=#000000 hi WarningMsg ctermfg=#ffff00 guifg=#ffff00 " syntax highlighting groups ---------------------------------------- hi Comment ctermfg=#696969 guifg=#696969 hi Constant ctermfg=#00aaaa guifg=#00aaaa hi Identifier ctermfg=#00e5ee guifg=#00e5ee hi Statement ctermfg=#00ffff guifg=#00ffff hi PreProc ctermfg=#8470ff guifg=#8470ff hi Type ctermfg=#ffffff guifg=#ffffff hi Special gui=none cterm=none ctermfg=#87cefa guifg=#87cefa hi Underlined gui=bold cterm=bold ctermfg=#4444ff guifg=#4444ff hi Ignore ctermfg=#444444 guifg=#444444 hi Error ctermbg=#000000 guibg=#000000 ctermfg=#bb0000 guifg=#bb0000 hi Todo ctermbg=#aa0006 guibg=#aa0006 ctermfg=#fff300 guifg=#fff300 hi Operator gui=none cterm=none ctermfg=#00bfff guifg=#00bfff hi Function ctermfg=#1e90ff guifg=#1e90ff hi String gui=none cterm=none ctermfg=#4682b4 guifg=#4682b4 hi Boolean ctermfg=#9bcd9b guifg=#9bcd9b |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Bram Moolenaar
On Nov 11, 2007 1:24 PM, Bram Moolenaar <[hidden email]> 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. It would be even better if the best approximation of a color could be found and used. That is, if I specify a color of #0000fe, Vim should be able to determine that #0000ff is the best match. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Matt Wozniski-2
On Mon, Nov 12, 2007 at 02:56:24AM -0500, Matthew Wozniski wrote: > > Do all the terminals supporting 88 and 256 colors really use the same > > color values? > > Well... As far as I can tell, they seem to _default_ to the same > values. In the interest of researching this properly, I've > source-dived a few to be sure. > > GNOME Terminal: same palette as xterm-256color (vte.c:2399) > PuTTY (pterm): same palette as xterm-256color (gtkwin.c:1432) > Mrxvt: same palette as xterm-256color (init.c:110) > > Rxvt-unicode: 88 colour palette (init.C:74). Btw -- rxvt uses a different palette. And if I remember correctly, Konsole uses the same palette as rxvt. I went through some pain and suffering to get a color scheme (xterm16) to display the same colors in the GUI, and the various terminal emulators around. It WorksForMe (TM), but every few months or so someone reports a situation where the colors are slightly different than they should be... If specifying colors via #rrggbb gets implemented, it would certainly make the code in xterm16.vim a lot cleaner... GI -- 100 THINGS I'D DO IF I EVER BECAME AN EVIL OVERLORD 86. I will make sure that my doomsday device is up to code and properly grounded. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Nikolai Weibull-11
Nikolai Weibull wrote: [...] > It would be even better if the best approximation of a color could be > found and used. That is, if I specify a color of #0000fe, Vim should > be able to determine that #0000ff is the best match. BTW: I have read that there is a set of 216 colors which are "safe" to use even on 256-color VGA displays, because they don't require dithering on any of them: namely, the colors, each of whose three RGB components is a multiple of 0x33 (i.e., one of 00 33 66 99 CC and FF). Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 132. You come back and check this list every half-hour. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Gautam Iyer-3
On Nov 12, 2007 4:29 AM, Gautam Iyer <[hidden email]> wrote: > > On Mon, Nov 12, 2007 at 02:56:24AM -0500, Matthew Wozniski wrote: > > > > Do all the terminals supporting 88 and 256 colors really use the same > > > color values? > > > > Well... As far as I can tell, they seem to _default_ to the same > > values. In the interest of researching this properly, I've > > source-dived a few to be sure. > > > > GNOME Terminal: same palette as xterm-256color (vte.c:2399) > > PuTTY (pterm): same palette as xterm-256color (gtkwin.c:1432) > > Mrxvt: same palette as xterm-256color (init.c:110) > > > > Rxvt-unicode: 88 colour palette (init.C:74). > Btw -- rxvt uses a different palette. And if I remember correctly, > Konsole uses the same palette as rxvt. Hm.... it seems like you're right, the colors in Konsole are ever so slightly off... It looks as though they're stepping evenly... xterm's steps are 00, 5F, 87, AF, D7, FF ; it favors the lighter colors. konsole's are 00, 33, 66, 99, CC, FF ; it favors being even... (I found it at TECommon.h:149 after searching harder) So, I would certainly welcome some advice on how querying can be done reasonably... Gnome-terminal and Konsole, at least, do not seem to be able to report back their colors... So, I guess one (pseudocode) approach is... if $TERM =~ 'screen' prefix = "\eP" suffix = "\e\\" endif resp = send_query(prefix + "\e]4;17;?\007" + suffix) if resp != "" palette = query_active_palette() # Repeatedly calls send_query else # No answer: assume default based on &t_Co if &t_Co == 88 palette = default_urxvt else if $KONSOLE_DCOP_SESSION == "" palette = default_xterm_gnome_terminal_putty else palette = default_konsole_rxvt endif endif endif Any thoughts? At the very least, this fails where a user launches gnome-terminal from konsole, since KONSOLE_DCOP_SESSION would have been exported... Is there a better way to tell them apart? Why can't they use $TERM right... :-/ > I went through some pain and suffering to get a color scheme (xterm16) > to display the same colors in the GUI, and the various terminal > emulators around. It WorksForMe (TM), but every few months or so someone > reports a situation where the colors are slightly different than they > should be... > > If specifying colors via #rrggbb gets implemented, it would certainly > make the code in xterm16.vim a lot cleaner... Here's hoping. :) ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
On Mon, Nov 12, 2007 at 05:41:12AM -0500, Matt Wozniski wrote: > > > > Do all the terminals supporting 88 and 256 colors really use the same > > > > color values? > > > > > > Well... As far as I can tell, they seem to _default_ to the same > > > values. In the interest of researching this properly, I've > > > source-dived a few to be sure. > > > > > > GNOME Terminal: same palette as xterm-256color (vte.c:2399) > > > PuTTY (pterm): same palette as xterm-256color (gtkwin.c:1432) > > > Mrxvt: same palette as xterm-256color (init.c:110) > > > > > > Rxvt-unicode: 88 colour palette (init.C:74). > > > Btw -- rxvt uses a different palette. And if I remember correctly, > > Konsole uses the same palette as rxvt. > > Hm.... it seems like you're right, the colors in Konsole are ever so > slightly off... It looks as though they're stepping evenly... > xterm's steps are 00, 5F, 87, AF, D7, FF ; it favors the lighter colors. > konsole's are 00, 33, 66, 99, CC, FF ; it favors being even... > > (I found it at TECommon.h:149 after searching harder) > > So, I would certainly welcome some advice on how querying > can be done reasonably... > > Gnome-terminal and Konsole, at least, do not seem to be able > to report back their colors... So, I guess one (pseudocode) > approach is... > > if $TERM =~ 'screen' > prefix = "\eP" > suffix = "\e\\" > endif > > resp = send_query(prefix + "\e]4;17;?\007" + suffix) > > if resp != "" > palette = query_active_palette() # Repeatedly calls send_query > else > # No answer: assume default based on &t_Co > if &t_Co == 88 > palette = default_urxvt > else > if $KONSOLE_DCOP_SESSION == "" > palette = default_xterm_gnome_terminal_putty > else > palette = default_konsole_rxvt > endif > endif > endif > > Any thoughts? At the very least, this fails where a user launches > gnome-terminal from konsole, since KONSOLE_DCOP_SESSION > would have been exported... Is there a better way to tell them > apart? Why can't they use $TERM right... :-/ It's worse than that. Some of the environment could be hidden if the user runs "sudo", or "ssh". Here's what I used in xterm16.vim: " First check for a user specified color cube. if exists('g:xterm16_ccube') let s:ccube = g:xterm16_ccube " No user specified color cube given. Use rxvt color cube if specified by " user, or running Konsole or rxvt (but not mrxvt). elseif ( exists('g:xterm16_termtype') && g:xterm16_termtype == 'rxvt') || \ ( !exists('g:xterm16_termtype') && \ ( ( &term =~ '^rxvt' && $MRXVT_TABTITLE == "" ) || \ ( &term =~ '^xterm' && $KONSOLE_DCOP != "" ) ) ) let s:ccube = "002a557faad4" else " default to xterm if nothing else is specified. let s:ccube ="005f87afd7ff" endif Of course this completely ignores screen. But handling that inside a Vim script looks formidable. Letting the user override Vim's guess would work best for situations with ssh/sudo. Most users (e.g. me) generally use only one terminal emulator (whatever their favourite is). So you can specify that in your ~/.vimrc so that hidden environment variables under sudo/ssh will not botch the scripts guess. Finally, t_Co is a bad measure. If you're not running xterm, t_Co is read directly from your termcap / terminfo files. The default terminfo files shipped with most distributions sets it to 8 colors. The user has to tweak a little to get 256 colors in Vim / Mutt / etc. Rather than reading t_Co, I choose to leave instructions for the user to get 256 colors working on his favourite terminal emulator. I'm sure you know those by now. If not, they're in the xterm16 help / mrxvt wiki: http://www.vim.org/scripts/script.php?script_id=795 http://www.stanford.edu/~gi1242/per/opensource/xterm16/xterm16-doc.html http://materm.sourceforge.net/wiki/FAQ/Colors Incidentally, I don't know if I mentioned it, but xterm16.vim has code so that the user can specify colors via Vim variables in an '#rrggbb' or other convenient formats. These colors are converted to the best matching cterm colors on terminals, and are used directly in the GUI. The conversion to cterm colors is done by finding the cterm color that (numerically) is the closest in each of the color components. As you probably know by now, the closest approximation in the above sense is NOT what the eye sees as the closest approximation! If you look into the code of some color program (e.g. gimp), you should find more sophisticated algorithms. I chose simplicity (and the option to let the user directly enter cterm colors) instead of a more complicated clever algorithm. But when implementing directly in Vim, you might want the more fancy algorithm. GI -- 'Worry' -- The interest you pay on trouble before it comes. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
On Nov 12, 2007 8:42 PM, Gautam Iyer <[hidden email]> wrote: > Finally, t_Co is a bad measure. If you're not running xterm, t_Co is > read directly from your termcap / terminfo files. The default terminfo > files shipped with most distributions sets it to 8 colors. The user has > to tweak a little to get 256 colors in Vim / Mutt / etc. This has actually changed a lot in recent versions of ncurses. There are terminfo definitions for both xterm-256color and screen-256color straight out of the box now. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
On Mon, Nov 12, 2007 at 10:23:09PM +0100, Nikolai Weibull wrote: > > Finally, t_Co is a bad measure. If you're not running xterm, t_Co is > > read directly from your termcap / terminfo files. The default terminfo > > files shipped with most distributions sets it to 8 colors. The user has > > to tweak a little to get 256 colors in Vim / Mutt / etc. > > This has actually changed a lot in recent versions of ncurses. There > are terminfo definitions for both xterm-256color and screen-256color > straight out of the box now. Somehow xterm-256color never worked well for me. I either lose the mouse in some applications (which I don't mind so much), or have trouble with function / cursor keys, especially when I press them with a modifier (e.g. Control+Left/Right). :( GI -- APATHY ERROR: Don't bother striking any key. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
On Mon, 12 Nov 2007 14:22:21 -0800
Gautam Iyer <[hidden email]> wrote: > especially when I press them with a modifier > (e.g. Control+Left/Right). That's a separate issue, entirely unrelated to the number of colours. It's been somewhat of a hobbyhorse of mine for a few years - I've made some notes on the subject: http://home.leonerd.org.uk/local/terminal.html ------ Vim has trouble parsing the way newer XTerms encode modified cursor keys (that's Up/Down/Left/Right, Insert/Del/Home/End/PageUp/PageDown, and others, combined with Ctrl/Shift/Alt/Hyper/Super/... modifier keys). This problem comes from the way that 'terminfo' basically just provides a static mapping from byte sequences into a big enumeration of key constants. The way xterm encodes it doesn't work like this. Xterm uses the CSIs the encode cursor movement or function keys, and provides extra parameters. [[A brief introduction to CSIs: A CSI is basically a procedure call - it has a method name and some (possibly none) parameters. The name is a single character in the range [\x40-\x7e], and the parameters are semicolon-separated numbers. CSIs are used to send control sequences from the application, into the terminal. The CSI for "move cursor up", for example is usually encoded CSI A It includes a number parameter to give it a count, defaulting to 1. This CSI does not give meanings for any of the other positional parameters. If a parameter is missing, it is presumed to have its default value - this is how "CSI A" alone can stand for it. Other valid encodings could be CSI ; A CSI 1 A CSI 1 ; A etc... All of these mean "move up 1 position". When terminals started gaining extra keys like cursor movement keys, that do not have standard ASCII mappings, these CSIs were extended to encode keys back into the application. CSI A/B/C/D encode up/down/right/left. For most of the other "special" keys (such as F1-F12 and PageUp/PageDown), a more generic mechanism instead is used, where they are given function numbers, and the "~" CSI is used. This takes one parameter, the function key number. PageUp / PageDown are given 5 and 6. A "PageUp" key is thus encoded CSI 5 ~ Equally valid, are any of the other ways to encode this CSI CSI 5 ; ~ CSI 5 ; 1 ~ CSI 5 ; ; ; ; ~ etc... ]] To represent modified movement keys or function keys, xterm uses the second position of the various CSIs normally used, to encode the modifier bitmask. A default of "1" is assumed to be in effect if not otherwise specified, so the encoding uses a 1+bitmask scheme: 1 = no modifier 2 = shift 3 = alt 4 = shift+alt 5 = ctrl 6 = shift+ctrl 7 = alt+ctrl 8 = shift+alt+ctrl etc... This is placed in the second CSI parameter. So, Alt-Left and Alt-PageDown might be encoded as CSI 1 ; 3 D CSI 5 ; 3 ~ This scheme generalises - any function key or movement key can be combined with any modifier. Vim has a problem parsing these currently, because of (I believe) inflexibilities in terminfo. It only has a static mapping from bytes into the key enumeration. It cannot parameterise the modifier bits. While it could be possible to give a large list of K*2^M mappings (for K keys and M possible modifiers), a more efficient scheme ought to be sought, where Vim could directly parse the CSI sequences. This would also avoid the current failure mode. The current failure is that, for example, when xterm sends a Ctrl-Left key, it sends CSI 1 ; 5 D Vim reads that as far as the semicolon, and finds it doesn't correspond to any valid key sequence, so instead interprets it as "5D", which results in 5 lines of text being deleted. I would like to assist in fixing this issue, but I'm not really sure where to start, code-wise. Should Vim somehow have a special case for CSI parsing, if it recognises the $TERM is one that sends CSIs, and use that instead? What makes xterm "special" here? Would other terminals do it? Should terminfo be somehow extended? This seems less desirable - given the arbitrary way CSI parameters can be sent, it would seem useful to have some form of parsing logic that can pull apart the parameters, whatever they may be, even if the logic beyond that just ignores them. This would at least avoid problems in the future, if a meaning for the 3rd position was ever given, for example. Or maybe some new keyboard-input parsing library needs to be provided, that can be used beyond vim, into any program that reads keyboard input and would care about modifiers. Even if not, it would help to avoid for example readline's failure to handle the same CSIs when running handling input for bash. -- Paul "LeoNerd" Evans [hidden email] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ |
signature.asc (196 bytes)
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Thomas Dickey
dickey wrote: > Bram Moolenaar wrote: >> Do all the terminals supporting 88 and 256 colors really use the same >> color values? > > [snip] > Like konsole, it uses (even) more memory but comes with prettier > menus. Konsole seems to support 16777216 colors. $ echo -e '\e[38;2;128;160;128mhello\e[0m' # hex 80a080 -- Matthew A pool hall put up a sign in their front window that read: "Profound language prohibited within." I could just imagine some people discussing the meaning of life and being told to take it outside. -- Scott Adams --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Matt Wozniski-2
On Nov 12, 2007 5:41 AM, Matt Wozniski <[hidden email]> wrote: > So, I would certainly welcome some advice on how querying > can be done reasonably... > > Gnome-terminal and Konsole, at least, do not seem to be able > to report back their colors... So, I guess one (pseudocode) > approach is... > > if $TERM =~ 'screen' > prefix = "\eP" > suffix = "\e\\" > endif > > resp = send_query(prefix + "\e]4;17;?\007" + suffix) > > if resp != "" > palette = query_active_palette() # Repeatedly calls send_query > else > # No answer: assume default based on &t_Co > if &t_Co == 88 > palette = default_urxvt > else > if $KONSOLE_DCOP_SESSION == "" > palette = default_xterm_gnome_terminal_putty > else > palette = default_konsole_rxvt > endif > endif > endif > > Any thoughts? After spending a long time experimenting with this, I've come to two conclusions: 1) It's prohibitively difficult to query the terminal emulator for available colors on its colorcube, especially given that many terminal don't support querying. Given this fact, I feel that the best thing that we can do is to hardcode in the known palettes and add an option to vim allowing you to choose which one your terminal emulator supports. 2) There is no algorithm available to programmatically judge the perceived differences between colors that suits our purposes. We do well with CIE L*a*b*, but not better than the stepping algorithm I proposed first, and in some places drastically worse. Unfortunately, CIE L*a*b* is only good at measuring the perceived differences between relatively similar colors, where the steps on our color cube are far enough apart that the colors are often not "similar" enough. So, I've reworked the patch to support, in addition to the xterm-compatible palette, Eterm and Konsole's palettes. Which palette is used for the matching is controlled by a new option, 'termpalette' (short name 'tpal'). If the option is unset, I default to an xterm palette, but display a warning that color matching might be unaccurate. For those interested, a comparison between the 3 palettes that I've found so far can be seen here: http://www.cs.drexel.edu/~mjw452/256.html So, I'd appreciate comments. The reworked patch can be found: http://www.cs.drexel.edu/~mjw452/ctermrgb-src.diff (source, against SVN) http://www.cs.drexel.edu/~mjw452/ctermrgb-runtime.diff (runtime, against latest AAP) And, the two modified colorschemes for testing are available at http://www.cs.drexel.edu/~mjw452/brookstream-rgb.vim and http://www.cs.drexel.edu/~mjw452/autumnleaf-rgb.vim ; it should be trivial to modify other colorschemes in this way. Please comment! ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
> 2) There is no algorithm available to programmatically judge the > perceived differences between colors that suits our purposes. We do > well with CIE L*a*b*, but not better than the stepping algorithm I > proposed first, and in some places drastically worse. Unfortunately, > CIE L*a*b* is only good at measuring the perceived differences between > relatively similar colors, where the steps on our color cube are far > enough apart that the colors are often not "similar" enough. Do you know about the Munsell color system ( http://en.wikipedia.org/wiki/Munsell_color_system )? It's a (the?) color system based on perceived colors, so perhaps is coul be used for your purpose. Nico --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
On Dec 21, 2007 5:18 AM, Nico Weber <[hidden email]> wrote: > > > 2) There is no algorithm available to programmatically judge the > > perceived differences between colors that suits our purposes. We do > > well with CIE L*a*b*, but not better than the stepping algorithm I > > proposed first, and in some places drastically worse. Unfortunately, > > CIE L*a*b* is only good at measuring the perceived differences between > > relatively similar colors, where the steps on our color cube are far > > enough apart that the colors are often not "similar" enough. > > Do you know about the Munsell color system ( http://en.wikipedia.org/wiki/Munsell_color_system > )? It's a (the?) color system based on perceived colors, so perhaps > is coul be used for your purpose. No, I hadn't tried using the Munsell color system, but I had tried CIEXYZ, CIELAB, CIELUV, and gave a brief glance at CIECAM. All 4 of those color systems are designed based on scientific measurements of perceived colors. If there were more reasons to try it, I might be more motivated, but the only disadvantage to my stepping algorithm is that it can't work if the color palette doesn't follow the same general format as xterm's... and every color palette I've found so far does. ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Matt Wozniski-2
On Dec 20, 2007 11:44 PM, Matt Wozniski <[hidden email]> wrote: > ... > So, I've reworked the patch to support, in addition to the > xterm-compatible palette, Eterm and Konsole's palettes. Which palette > is used for the matching is controlled by a new option, 'termpalette' > (short name 'tpal'). If the option is unset, I default to an xterm > palette, but display a warning that color matching might be > unaccurate. > > For those interested, a comparison between the 3 palettes that I've > found so far can be seen here: > http://www.cs.drexel.edu/~mjw452/256.html > > So, I'd appreciate comments. The reworked patch can be found: > http://www.cs.drexel.edu/~mjw452/ctermrgb-src.diff (source, against SVN) > http://www.cs.drexel.edu/~mjw452/ctermrgb-runtime.diff (runtime, > against latest AAP) > > And, the two modified colorschemes for testing are available at > http://www.cs.drexel.edu/~mjw452/brookstream-rgb.vim and > http://www.cs.drexel.edu/~mjw452/autumnleaf-rgb.vim ; it should be > trivial to modify other colorschemes in this way. > > Please comment! > ~Matt Has anyone tried this out? I would love to have some feedback on this, since I think that it would be a really nice feature to make life easier for colorscheme authors! ~Matt --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
Hello all, I just wanted to let you know that this patch works like a charm and it's by far the closest to having gvim-like color themes inside my terminal; PuTTY with "TERM=xterm-256color" in my case. I happened to be fortunate enough to ask the right question at the right time and stumble across this patch by conversing with Matt in #vim on freenode. Together, we put together a vim regex script that is easily sourced on your favorite vim colorscheme to convert it to the correct #rrggbb format. regex script available here --> http://www.cs.drexel.edu/~mjw452/ctermrgbify-scheme.vim His latest source patch applied cleanly to my Slackware-12 vim-7.1 package and only minor tweaking was required to the runtime patch since Matt diff'd against the latest svn build. I highly suggest that you consider this for inclusion into the main trunk. Regards, -Sean On Jan 3, 1:30 pm, "Matt Wozniski" <[hidden email]> wrote: > On Dec 20, 2007 11:44 PM, Matt Wozniski <[hidden email]> wrote: > > > > > ... > > So, I've reworked the patch to support, in addition to the > > xterm-compatible palette, Eterm and Konsole's palettes. Which palette > > is used for the matching is controlled by a new option, 'termpalette' > > (short name 'tpal'). If the option is unset, I default to an xterm > > palette, but display a warning that color matching might be > > unaccurate. > > > For those interested, a comparison between the 3 palettes that I've > > found so far can be seen here: > >http://www.cs.drexel.edu/~mjw452/256.html > > > So, I'd appreciate comments. The reworked patch can be found: > >http://www.cs.drexel.edu/~mjw452/ctermrgb-src.diff(source, against SVN) > >http://www.cs.drexel.edu/~mjw452/ctermrgb-runtime.diff(runtime, > > against latest AAP) > > > And, the two modified colorschemes for testing are available at > >http://www.cs.drexel.edu/~mjw452/brookstream-rgb.vimand > >http://www.cs.drexel.edu/~mjw452/autumnleaf-rgb.vim; it should be > > trivial to modify other colorschemes in this way. > > > Please comment! > > ~Matt > > Has anyone tried this out? I would love to have some feedback on > this, since I think that it would be a really nice feature to make > life easier for colorscheme authors! > > ~Matt You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Matt Wozniski-2
On Jan 3, 4:30 pm, "Matt Wozniski" <[hidden email]> wrote: > On Dec 20, 2007 11:44 PM, Matt Wozniski <[hidden email]> wrote: > > > > > ... > > So, I've reworked the patch to support, in addition to the > > xterm-compatible palette, Eterm and Konsole's palettes. Which palette > > is used for the matching is controlled by a new option, 'termpalette' > > (short name 'tpal'). If the option is unset, I default to an xterm > > palette, but display a warning that color matching might be > > unaccurate. > > > For those interested, a comparison between the 3 palettes that I've > > found so far can be seen here: > >http://www.cs.drexel.edu/~mjw452/256.html > > > So, I'd appreciate comments. The reworked patch can be found: > >http://www.cs.drexel.edu/~mjw452/ctermrgb-src.diff(source, against SVN) > >http://www.cs.drexel.edu/~mjw452/ctermrgb-runtime.diff(runtime, > > against latest AAP) > > > And, the two modified colorschemes for testing are available at > >http://www.cs.drexel.edu/~mjw452/brookstream-rgb.vimand > >http://www.cs.drexel.edu/~mjw452/autumnleaf-rgb.vim; it should be > > trivial to modify other colorschemes in this way. > > > Please comment! > > ~Matt > > Has anyone tried this out? I would love to have some feedback on > this, since I think that it would be a really nice feature to make > life easier for colorscheme authors! > > ~Matt It works well for me (after editing my system colorschemes). A few things I noticed: * The new code be wrapped in an #ifdef FEAT_SYN_HL . Certain of the prototypes are, which means the code doesn't compile correctly when this feature is disabled. * hexhex2nr in charset.c should be defined whenever the patch is included (as noted in a comment). Adding defined(FEAT_SYN_HL) to the list of conditions should work. * As discussed on IRC, colorschemes will have to define colors differently depending on whether one is in 16- or 256-color mode. If hex colors aren't going to be supported for 16-color mode (and I think your arguments here are convincing), maybe there should be separate hctermfg/hctermbg arguments for high-color schemes. This would require less work on the part of colorscheme authors to support both kinds of terminals (they could keep ctermfg=14 and add a separate hctermfg=#ff33ff to support high-color terms). --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
Re: Patch to allow ctermfg or bg values as #rrggbb
|
|
In reply to this post by Matt Wozniski-2
On Dec 21 2007, 6:44 am, "Matt Wozniski" <[hidden email]> wrote: > So, I'd appreciate comments. The reworked patch can be found: http://www.cs.drexel.edu/~mjw452/ctermrgb-src.diff (source, against SVN) http://www.cs.drexel.edu/~mjw452/ctermrgb-runtime.diff (runtime, against latest AAP) I have tried your patches on recent vim71 (svn@r1029). They applied with few small corrections. I would post the fix, but googlegroups does not allow me include file :(. When trying to figure out, how properly "publish" hexhex2nr I got lost, since originally it seemed like FEAT_SYN_HL is needed, but later on it seemed that in fact FEAT_EVAL might be sufficient to trigger scheme file loading, even though help clearly says that +syntax is required. Then I used the regex script posted here: http://www.cs.drexel.edu/~mjw452/ctermrgbify-scheme.vim to convert my favorite scheme (darkblue). With small tweak of background color (which was too light on xterm-256color compared to gVim running on Windows) I got almost the same coloring. So far so good. Then I found out that it is possible to use RGBified scheme with this script: http://www.vim.org/scripts/script.php?script_id=1809 and it works the same way as your patch (well, on the first look). So now I wonder, if it is worthy the hassle of patching, when in fact, the same thing could be done just by script. Also it seems that the point raised here about different colors for 16 and 256 is valid. For example on darkblue-rgb I had to make blue background slightly darker, so it will match black on 256 approximation rather than blue (which was too blue to my likings.). Richard --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~--- |
«
Return to Vim - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |