Matt Wozniski wrote:
> On Thu, Nov 6, 2008 at 7:35 AM, Richard Hartmann wrote: > > On Thu, Nov 6, 2008 at 11:55, John Beckett wrote: > > > >> Richard Hartmann wrote: > >>> Can you add the patch to the list, please? :) > >> > >> Sure but I don't have time to work out what text to put. > > > > Unless Matt chips on before you next look at it, I propose what I basically > > stole & adapted from his announcement email: > > > > Unified colors across various Terminal emulators to make colorschemes > > consistent. Supports the xterm-compatible, Eterm and Konsole palettes. > > Which palette is used for the matching is controlled by a new option, > > 'termpalette' (short name 'tpal'). If the option is unset, default to xterm > > palette, but display a warning that color matching might be inaccurate. > > > > Sorry for the late reply, it's been a very busy week. Anyway, I think > I plan on changing tactics with this, since Bram was unhappy with the > thought of adding another option, but has tended to be happy to make > changes to vim's source to make scripting easier. I think what I'd > most like to see happen at this point is for CSApprox.vim to get a few > hundred more downloads, and then ask for it to be included in the > default runtime. It works pretty well out of the box nearly 100% of > the time, and is much easier to customize than the nearly equivalent > code I went with in the patch. > > That being said, there's one thing I'd like to have changed in vim's > source to better support CSApprox, namely that gui colors are not > stored unless vim has +gui. That probably was meant to help keep the > size of the binary or memory usage down for the old dos16 version, but > since CSApprox.vim hooks in by postprocessing the highlights after a > :colorscheme command, this renders it useless on vim binaries that > weren't built with gui support. I think Bram's much more likely to > agree to changing the source to keep the gui colors even without +gui > than he would be to ever accept the original patch, both because it's > a much smaller change and it's because just enabling already-tested > code. > > Any thoughts on that, Bram? What do you mean with "gui colors" in this context? The highlight_init arrays? It could be changed to only exclude GUI colors for Tiny and Small versions. That sounds like an acceptable change. > > PS: Matt, did you look at how Konsole in KDE 4 does some things > > differently? Mainly, it now supports real bold etc instead of mapping > > them to color changes. > > I'm not sure I understand what the difference is? Feel free to > respond off-list with an explanation of what you mean. ;-) Some older highlight scheme used the bold attribute to make colors lighter. Like colors 0 - 7 with bold give you colors 8 - 15. See ":help highlight-ctermfg". -- >From the classified section of a city newspaper: Dog for sale: eats anything and is fond of children. /// 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_use" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
