On Wed, 14 Jul 2010, Tony Mechelynck wrote: > On 14/07/10 22:57, Bram Moolenaar wrote: > > > > Matt Wozniski wrote: > > > > [about a patch to support #rrggbb in a terminal] > > > > Where can I find the latest version of this patch? I only see one > > that is two years old. > > > > Is such a patch necessary? The CSApprox plugin gives me uniform look & > feel between GUI and xterm-256color; OTOH I can still use _different_ > cterm ctermbg ctermfg colors for the Linux console which has only > (IIUC) 8 colors + foreground bold. > > With this plugin installed I can think (and program my colorshceme) in > terms of: term= black & white only, possibly bold and/or underline; > cterm= 8 to 16 colors; gui= 88 to 16777216 colors — CSApprox does the > "dirty work" of converting "gui" rrggbb values to palette ordinal > numbers when in 88- or 256-color consoles.
In the off-chance you hadn't noticed, Matt Wozniski is the author of both the patch in question and the CSApprox plugin. I'm not sure how either the patch or the plugin works currently, but personally, I'd prefer that #rrggbb conversion for terminals gets integrated into the main program. I currently use a self-written Perl script to do the approximation (handles both X11 rgb.txt names and #rrggbb), but there are colorschemes that resort to hacky tricks (and yes, my self-written Perl script is hacky) to get their GUI-oriented colors to work for terminals. E.g. I don't have a nice way to convert 'inkpot', since it uses its own conversion that handles both urxvt-style t_Co=88 and xterm-style t_Co=256. I agree that getting it working so that colorschemes can be written toward the following guidelines would be most convenient: term= no 'colors' cterm= 8 or 16 colors gui= 88 / 256 / 'true' colors But as I said, I'd rather it not require a plugin. -- Best, Ben -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
