Re: Patch to allow ctermfg or bg values as #rrggbb
On 21-Jul-2010 20:57, Matt Wozniski wrote:
The down side is that it's a bit slow (as Dominique pointed out), but
I have a version in my sandbox that should hopefully help a bit with
that.
If you don't change your colorscheme often, CSApprox.vim (again, thanks Matt for
this wonderful plugin!) allows to take a static snapshot, which avoids the
runtime penalty of translating all colors on each Vim launch; instead, only the
generated snapshot is sourced.
I have my own colorscheme, and here's how I generate a new snapshot whenever I
have modified it (notice how I have put CSApprox in .vim/, not .vim/plugin/, so
it's only sourced on-demand for this one-time conversion):
gvim -c runtime CSApprox.vim|CSApproxSnapshot!
~/.vim/colors/ingo-cterm.vim|quit
In my .vimrc, the following fragment detects a color terminal and then sources
the snapshot. (Though this isn't strictly necessary, it falls back to the
original, handwritten colorscheme when run in a plain terminal or the GUI.)
let g:color_terminal = ! has('gui_running') t_Co = 88
if g:color_terminal
There may exist a high color snapshot of my colorscheme generated by
CSApprox.vim.
try
colorscheme ingo-cterm
catch /^Vim\%((\a\+)\)\=:E185/ catch error E185: Cannot find color
scheme
colorscheme ingo
endtry
else
colorscheme ingo
endif
This works well for me, so I would recommend such an approach to try in case
you're concerned about the startup performance.
-- regards, ingo
--
-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
-- http://vim.sourceforge.net/account/profile.php?user_id=9713--
--
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
Re: Patch to allow ctermfg or bg values as #rrggbb
On Wed, Jul 14, 2010 at 4:57 PM, 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. As Benjamin Haskell noted, I decided to shoot for a vimscript implementation instead of a patch implementation, and wound up with CSApprox instead. You've already committed 9cf38f, which was the last thing that was really missing in making CSApprox perfect, and it turns out it's much easier to do all of the nasty magic that needs to be done in a script than in code, and the result is much more flexible. The down side is that it's a bit slow (as Dominique pointed out), but I have a version in my sandbox that should hopefully help a bit with that. Thanks! -- 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
Re: Patch to allow ctermfg or bg values as #rrggbb
Matt Wozniski wrote: On Wed, Jul 14, 2010 at 4:57 PM, 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. As Benjamin Haskell noted, I decided to shoot for a vimscript implementation instead of a patch implementation, and wound up with CSApprox instead. You've already committed 9cf38f, which was the last thing that was really missing in making CSApprox perfect, and it turns out it's much easier to do all of the nasty magic that needs to be done in a script than in code, and the result is much more flexible. The down side is that it's a bit slow (as Dominique pointed out), but I have a version in my sandbox that should hopefully help a bit with that. OK, I'll remove the todo item then. -- Why isn't there mouse-flavored cat food? /// Bram Moolenaar -- b...@moolenaar.net -- 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
Re: Patch to allow ctermfg or bg values as #rrggbb
On 2010-07-15, Tony Mechelynck wrote: On 15/07/10 07:44, Dominique Pellé wrote: 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: You're a fast-reacting guy. Changing from a quarter of a second to half a second is not something I notice. Especially now that I use a hand-coded session file whose last line is sleep 3 | intro :-) Are you serious? Why do you sleep for 3 seconds? Best regards, Gary -- 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
Re: Patch to allow ctermfg or bg values as #rrggbb
On 15/07/10 23:07, Gary Johnson wrote: On 2010-07-15, Tony Mechelynck wrote: On 15/07/10 07:44, Dominique Pellé wrote: 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: You're a fast-reacting guy. Changing from a quarter of a second to half a second is not something I notice. Especially now that I use a hand-coded session file whose last line is sleep 3 | intro :-) Are you serious? Why do you sleep for 3 seconds? Best regards, Gary I tell Vim to sleep, to make sure that whatever else the previous commands initiated, including a possible CursorHold autocommand, will be finished by then and not interfere with the display of the splash screen. Best regards, Tony. -- methionylglutaminylarginyltyrosylglutamylserylleucylphenylalanylalanylglutamin- ylleucyllysylglutamylarginyllysylglutamylglycylalanylphenylalanylvalylprolyl- phenylalanylvalylthreonylleucylglycylaspartylprolylglycylisoleucylglutamylglu- taminylserylleucyllysylisoleucylaspartylthreonylleucylisoleucylglutamylalanyl- glycylalanylaspartylalanylleucylglutamylleucylglycylisoleucylprolylphenylala- nylserylaspartylprolylleucylalanylaspartylglycylprolylthreonylisoleucylgluta- minylasparaginylalanylthreonylleucylarginylalanylphenylalanylalanylalanylgly- cylvalylthreonylprolylalanylglutaminylcysteinylphenylalanylglutamylmethionyl- leucylalanylleucylisoleucylarginylglutaminyllysylhistidylprolylthreonylisoleu- cylprolylisoleucylglycylleucylleucylmethionyltyrosylalanylasparaginylleucylva- lylphenylalanylasparaginyllysylglycylisoleucylaspartylglutamylphenylalanyltyro- sylalanylglutaminylcysteinylglutamyllysylvalylglycylvalylaspartylserylvalylleu- cylvalylalanylaspartylvalylprolylvalylglutaminylglutamylserylalanylprolylphe- nylalanylarginylglutaminylalanylalanylleucylarginylhistidylasparaginylvalylala- nylprolylisoleucylphenylalanylisoleucylcysteinylprolylprolylaspartylalanylas- partylaspartylaspartylleucylleucylarginylglutaminylisoleucylalanylseryltyrosyl- glycylarginylglycyltyrosylthreonyltyrosylleucylleucylserylarginylalanylglycyl- valylthreonylglycylalanylglutamylasparaginylarginylalanylalanylleucylprolylleu- cylasparaginylhistidylleucylvalylalanyllysylleucyllysylglutamyltyrosylasparagi- nylalanylalanylprolylprolylleucylglutaminylglycylphenylalanylglycylisoleucylse- rylalanylprolylaspartylglutaminylvalyllysylalanylalanylisoleucylaspartylalanyl- glycylalanylalanylglycylalanylisoleucylserylglycylserylalanylisoleucylvalylly- sylisoleucylisoleucylglutamylglutaminylhistidylasparaginylisoleucylglutamylpro- lylglutamyllysylmethionylleucylalanylalanylleucyllysylvalylphenylalanylvalyl- glutaminylprolylmethionyllysylalanylalanylthreonylarginylserine, n.: The chemical name for tryptophan synthetase A protein, a 1,913-letter enzyme with 267 amino acids. -- Mrs. Bryne's Dictionary of Unusual, Obscure, and -- 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
Re: Patch to allow ctermfg or bg values as #rrggbb
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 -- b...@moolenaar.net -- 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
Re: Patch to allow ctermfg or bg values as #rrggbb
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
Re: Patch to allow ctermfg or bg values as #rrggbb
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
Re: Patch to allow ctermfg or bg values as #rrggbb
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
Re: Patch to allow ctermfg or bg values as #rrggbb
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 BW) 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=redguifg=black'
else
exe 'hi StatusLine'
\ 'cterm=NONE,bold ctermbg=' . s:ctbg2 'ctermfg=' . s:ctfg
\ 'gui=NONE,bold guibg=redguifg=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,
Re: Patch to allow ctermfg or bg values as #rrggbb
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 BW) 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=redguifg=black'
else
exe 'hi StatusLine'
\ 'cterm=NONE,bold ctermbg=' . s:ctbg2 'ctermfg=' . s:ctfg
\ 'gui=NONE,bold guibg=redguifg=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
Re: Patch to allow ctermfg or bg values as #rrggbb
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
Re: Patch to allow ctermfg or bg values as #rrggbb
On Dec 21 2007, 6:44 am, Matt Wozniski [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]). 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 -~--~~~~--~~--~--~---
Re: Patch to allow ctermfg or bg values as #rrggbb
On Dec 20, 2007 11:44 PM, Matt Wozniski [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
On Nov 12, 2007 5:41 AM, Matt Wozniski [EMAIL PROTECTED] 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
On Nov 11, 2007 1:24 PM, Bram Moolenaar [EMAIL PROTECTED] 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 #ff. 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 #fe, Vim should
be able to determine that #ff 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
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
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 #fe, Vim should be able to determine that #ff 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
On Nov 12, 2007 4:29 AM, Gautam Iyer [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 -~--~~~~--~~--~--~---
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
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 #ff. 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 -- [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_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 #ff. 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 [EMAIL PROTECTED]
Subject: Re: X graphics
Newsgroups: comp.os.linux.x
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Organization: RadixNet Internet Services
User-Agent: tin/1.4.4-2803 (Vet for the Insane) (UNIX) (SunOS/
5.8 (sun4u))
Status: RO
Content-Length: 937
Lines: 23
Dances With Crows [EMAIL PROTECTED] 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
Re: Patch to allow ctermfg or bg values as #rrggbb
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 #ff. 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 +
