On Sun, Nov 9, 2008 at 8:43 AM, Bram Moolenaar wrote:
>
> Matt Wozniski wrote:
>>
>> 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.
Yes, the highlight init arrays, but also user- and colorscheme-set
colors. In a non-gui vim, doing
:highlight Normal cterm=none ctermbg=10 ctermfg=15 gui=none
guibg=#808080 guifg=#ff00ff
:highlight Normal
results in just this information being printed:
Normal xxx ctermfg=15 ctermbg=10
That's because syntax.c has #ifdef FEAT_GUI around the sections of
do_highlight() that correspond to setting the gui{,fg,bg,sp}
attributes, and a matching #ifdef in the struct hl_group definition.
Since what the script does is query the gui and gui{fg,bg,sp}
attributes with synIDattr to figure out what the proper cterm colors
should be, it's dead in the water unless those attributes are stored.
Since doing anything with the stored colors requires +eval anyway,
there's no harm in not storing them for Tiny and Small, as far as I
can see.
>> On Thu, Nov 6, 2008 at 7:35 AM, Richard Hartmann wrote:
>> > 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".
That shouldn't affect me at all, then - my script will never set a
color less than 16, and unless I'm misunderstanding what Richard was
saying, all Konsole has changed is the handling of bold for foreground
colors 0 through 7.
~Matt
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
