Patch to allow ctermfg or bg values as #rrggbb

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Patch to allow ctermfg or bg values as #rrggbb

Bram Moolenaar

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.

--
Shit makes the flowers grow and that's beautiful

 /// 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.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Patch to allow ctermfg or bg values as #rrggbb

Tony Mechelynck
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.


Best regards,
Tony.
--
Omnibiblious, adj.:
        Indifferent to type of drink.  "Oh, you can get me anything.
I'm omnibiblious."

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Patch to allow ctermfg or bg values as #rrggbb

Benjamin R. Haskell-8
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
Reply | Threaded
Open this post in threaded view
|

Re: Patch to allow ctermfg or bg values as #rrggbb

Benjamin R. Haskell-8
On Wed, 14 Jul 2010, Benjamin R. Haskell wrote:

> 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.

(braino:) I also don't *need* a way to convert 'inkpot'.  But, it'd be
nice if 'inkpot' didn't need to resort to a self-written color mapping
for 88/256-color modes.

-- 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
Reply | Threaded
Open this post in threaded view
|

Re: Patch to allow ctermfg or bg values as #rrggbb

Tony Mechelynck
In reply to this post by Benjamin R. Haskell-8
On 15/07/10 00:34, Benjamin R. Haskell wrote:

> 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 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.
>

Well, at least we agree on one point: we'd prefer guifg=#123456 to work
in 88+ color terminal, rather than ctermfg=#123456 which would prevent
writing "ctermfg=cyan guifg=#123456" to cover low-color terminals too.

OTOH, I believe that CSApprox does the job well, with no appreciable
delay, and I don't feel the necessity of patching the C code. It even
has accessible "hooks" for special cases (see below). What _would_ be
useful would be to distribute that plugin as part of the vanilla Vim
distribution, maybe "disabled matchit-like" if people don't want Vim in
xterm-256 and gvim to look alike.

Example of a special case: (my vimrc sets CSApprox_loaded to 1 on the
Linux console and) my colorscheme includes the following:

> " display the status line of the active window in a distinctive color:
> " bold black on bright red in the GUI, white on green in the console
> " (where the bg is never bright, and dark red is sometimes an ugly sort
> " of reddish brown).
> hi StatusLine   gui=NONE,bold   guibg=red           guifg=black
>         \       cterm=NONE,bold ctermbg=darkgreen   ctermfg=white
> hi WildMenu     gui=NONE,bold   guibg=green         guifg=black
>         \       cterm=NONE,bold ctermbg=black       ctermfg=white
> " make the status line bold-reverse (but B&W) for inactive windows
> hi StatusLineNC gui=reverse,bold
>         \       cterm=NONE      ctermbg=black       ctermfg=lightgrey
> " make the active status line colours alternate between two settings
> " to give a visual notice of the CursorHold/CursorHoldI events
> if ! exists("s:statuslineflag")
>   let s:statuslineflag = 0
> endif
> "
> " The following 'fancy footwork' is needed to have our CursorHold autocommand
> " work smoothly with 256-color cterms handled by the 3rd-party csapprox.vim plugin
> if exists('g:CSApprox_approximator_function')
>     let s:ctbg1 = g:CSApprox_approximator_function(0,   255, 0) " green
>     let s:ctbg2 = g:CSApprox_approximator_function(255, 0,   0) " red
>     let s:ctfg  = g:CSApprox_approximator_function(0,   0,   0) " black
> else
>     let s:ctbg1 = 'darkgreen'
>     let s:ctbg2 = 'black'
>     let s:ctfg  = 'white'
> endif
>
> function! ToggleStatusLine()
>     if s:statuslineflag
>         exe 'hi StatusLine'
>           \     'cterm=NONE,bold ctermbg=' . s:ctbg1 'ctermfg=' . s:ctfg
>           \     'gui=NONE,bold   guibg=green          guifg=black'
>         exe 'hi WildMenu'
>           \     'cterm=NONE,bold ctermbg=' . s:ctbg2 'ctermfg=' . s:ctfg
>           \     'gui=NONE,bold   guibg=red            guifg=black'
>     else
>         exe 'hi StatusLine'
>           \     'cterm=NONE,bold ctermbg=' . s:ctbg2 'ctermfg=' . s:ctfg
>           \     'gui=NONE,bold   guibg=red            guifg=black'
>         exe 'hi WildMenu'
>           \     'cterm=NONE,bold ctermbg=' . s:ctbg1 'ctermfg=' . s:ctfg
>           \     'gui=NONE,bold   guibg=green          guifg=black'
>     endif
>     let s:statuslineflag = ! s:statuslineflag
> endfunction
>
> exe "augroup" s:colors_name
>     au! CursorHold,CursorHoldI * call ToggleStatusLine()
>     au! ColorScheme *
>         \ if g:colors_name != s:colors_name | exe "au!" s:colors_name | endif
> augroup END



Best regards,
Tony.
--
Democracy, n.:
        A government of the masses.  Authority derived through mass
meeting or any other form of direct expression.  Results in mobocracy.
Attitude toward property is communistic... negating property rights.
Attitude toward law is that the will of the majority shall regulate,
whether it is based upon deliberation or governed by passion,
prejudice, and impulse, without restraint or regard to consequences.
Result is demagogism, license, agitation, discontent, anarchy.
                -- U. S. Army Training Manual No. 2000-25 (1928-1932),
                   since withdrawn.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Patch to allow ctermfg or bg values as #rrggbb

Benjamin R. Haskell-8
On Thu, 15 Jul 2010, Tony Mechelynck wrote:

> On 15/07/10 00:34, Benjamin R. Haskell wrote:
> > 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 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.
> >
>
> Well, at least we agree on one point: we'd prefer guifg=#123456 to
> work in 88+ color terminal, rather than ctermfg=#123456 which would
> prevent writing "ctermfg=cyan guifg=#123456" to cover low-color
> terminals too.
>
> OTOH, I believe that CSApprox does the job well, with no appreciable
> delay, and I don't feel the necessity of patching the C code. It even
> has accessible "hooks" for special cases (see below). What _would_ be
> useful would be to distribute that plugin as part of the vanilla Vim
> distribution, maybe "disabled matchit-like" if people don't want Vim
> in xterm-256 and gvim to look alike.
>
> Example of a special case: (my vimrc sets CSApprox_loaded to 1 on the
> Linux console and) my colorscheme includes the following:
>
> > " display the status line of the active window in a distinctive color:
> > " bold black on bright red in the GUI, white on green in the console
> > " (where the bg is never bright, and dark red is sometimes an ugly sort
> > " of reddish brown).
> > hi StatusLine   gui=NONE,bold   guibg=red           guifg=black
> >         \       cterm=NONE,bold ctermbg=darkgreen   ctermfg=white
> > hi WildMenu     gui=NONE,bold   guibg=green         guifg=black
> >         \       cterm=NONE,bold ctermbg=black       ctermfg=white
> > " make the status line bold-reverse (but B&W) for inactive windows
> > hi StatusLineNC gui=reverse,bold
> >         \       cterm=NONE      ctermbg=black       ctermfg=lightgrey
> > " make the active status line colours alternate between two settings
> > " to give a visual notice of the CursorHold/CursorHoldI events
> > if ! exists("s:statuslineflag")
> >   let s:statuslineflag = 0
> > endif
> > "
> > " The following 'fancy footwork' is needed to have our CursorHold
> > autocommand
> > " work smoothly with 256-color cterms handled by the 3rd-party csapprox.vim
> > plugin
> > if exists('g:CSApprox_approximator_function')
> >     let s:ctbg1 = g:CSApprox_approximator_function(0,   255, 0) " green
> >     let s:ctbg2 = g:CSApprox_approximator_function(255, 0,   0) " red
> >     let s:ctfg  = g:CSApprox_approximator_function(0,   0,   0) " black
> > else
> >     let s:ctbg1 = 'darkgreen'
> >     let s:ctbg2 = 'black'
> >     let s:ctfg  = 'white'
> > endif
> >
> > function! ToggleStatusLine()
> >     if s:statuslineflag
> >         exe 'hi StatusLine'
> >           \     'cterm=NONE,bold ctermbg=' . s:ctbg1 'ctermfg=' . s:ctfg
> >           \     'gui=NONE,bold   guibg=green          guifg=black'
> >         exe 'hi WildMenu'
> >           \     'cterm=NONE,bold ctermbg=' . s:ctbg2 'ctermfg=' . s:ctfg
> >           \     'gui=NONE,bold   guibg=red            guifg=black'
> >     else
> >         exe 'hi StatusLine'
> >           \     'cterm=NONE,bold ctermbg=' . s:ctbg2 'ctermfg=' . s:ctfg
> >           \     'gui=NONE,bold   guibg=red            guifg=black'
> >         exe 'hi WildMenu'
> >           \     'cterm=NONE,bold ctermbg=' . s:ctbg1 'ctermfg=' . s:ctfg
> >           \     'gui=NONE,bold   guibg=green          guifg=black'
> >     endif
> >     let s:statuslineflag = ! s:statuslineflag
> > endfunction
> >
> > exe "augroup" s:colors_name
> >     au! CursorHold,CursorHoldI * call ToggleStatusLine()
> >     au! ColorScheme *
> >         \ if g:colors_name != s:colors_name | exe "au!" s:colors_name |
> > endif
> > augroup END

Narrowing your example down to just the portion (I think?) that uses
CSApprox, and simplifying a bit to isolate the effect of CSApprox:


" elsewhere - disable CSApprox if on linux console

if exists('g:CSApprox_approximator_function')
        let s:ctbg1 = g:CSApprox_approximator_function(0,   255, 0) " green
        let s:ctbg2 = g:CSApprox_approximator_function(255, 0,   0) " red
else
        let s:ctbg1 = 'darkgreen'
        let s:ctbg2 = 'black'
endif
function! ToggleStatusLine()
        if s:statuslineflag
                exe 'hi StatusLine ctermbg=' . s:ctbg1 . 'guibg=green'
        else
                exe 'hi StatusLine ctermbg=' . s:ctbg2 . 'guibg=red'
        endif
        let s:statuslineflag = ! s:statuslineflag
endfunction


Why is that preferable to:

" elsewhere - set g:on_linux_console if on linux console

if !exists('g:on_linux_console')
        let s:ctbg1 = '#00ff00'
        let s:ctbg2 = '#ff0000'
else
        let s:ctbg1 = 'darkgreen'
        let s:ctbg2 = 'black'
endif
function! ToggleStatusLine()
        if s:statuslineflag
                exe 'hi StatusLine ctermbg=' . s:ctbg1 . 'guibg=green'
        else
                exe 'hi StatusLine ctermbg=' . s:ctbg2 . 'guibg=red'
        endif
        let s:statuslineflag = ! s:statuslineflag
endfunction


It seems to me it's just something you want to special-case regardless
of whether you're using CSApprox, and using built-in #rrggbb recognition
prevents having to call a plugin function.

Or am I missing something with which one of ctermbg/guibg applies at
what points?

linux terminal = 8 colors (modulo playing with fb), but special-cased,
so ctermbg=darkgreen
xterm = 256 colors, so you want ctermbg='#00ff00' (green) rather than
guibg=green? (6 of one, half a dozen of the other)
gui = 24-bit color, so guibg=green

I agree, though, that a disabled-but-shipped plugin would be better than
nothing.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Patch to allow ctermfg or bg values as #rrggbb

Dominique Pellé
In reply to this post by Tony Mechelynck
Tony Mechelynck wrote:

> OTOH, I believe that CSApprox does the job well, with no appreciable delay,
> and I don't feel the necessity of patching the C code.

Hi Tony

I also use CSApprox which I find very nice.  I measured how long it
takes for vim to start with & without CSApprox on my machine (without
using the snapshotted scheme feature of CSApprox):

When using CSApprox.vim:

  $ time vim -c q
  real 0m0.496s
  user 0m0.468s
  sys 0m0.020s


When not using CSApprox.vim:

  $ time vim -c q
  real 0m0.221s
  user 0m0.196s
  sys 0m0.012s

So on my machine, using CSApprox.vim adds ~ 275 ms which is acceptable
but noticeable (it more than doubles startup time).  I'm using Vim-7.3a
huge with this colorscheme:

  http://www.vim.org/scripts/script.php?script_id=2198

This is the timing using --startuptime (measuring several times)
which shows that sourcing CSApprox.vim takes ~ 270 ms (second column):

  $ vim --startuptime with-csaaprox.txt -c q

  $ grep CSApprox with-csaaprox.txt
  401.332  272.682  262.586: sourcing /home/pel/.vim/plugin/CSApprox.vim
  398.207  269.501  259.428: sourcing /home/pel/.vim/plugin/CSApprox.vim
  392.784  262.959  253.058: sourcing /home/pel/.vim/plugin/CSApprox.vim
  389.716  262.984  253.074: sourcing /home/pel/.vim/plugin/CSApprox.vim
  400.432  267.164  257.251: sourcing /home/pel/.vim/plugin/CSApprox.vim

Regards
-- Dominique

--
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
12