Patch to allow ctermfg or bg values as #rrggbb

[Matt Wozniski-2]

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 "\cgui\%([fb]g\|sp\)="he=e-1 nextgroup=vimHiGroup,vimHiGuiFontname,vimHiRgb,vimFgBgAttrib
 syn match  vimHiTermcap contained "\S\+" contains=vimNotation
 
 " Highlight: clear {{{2
@@ -602,7 +602,7 @@
 hi def link vimHiGroup vimGroupName
 hi def link vimHiGuiFgBg vimHiTerm
 hi def link vimHiGuiFont vimHiTerm
-hi def link vimHiGuiRgb vimNumber
+hi def link vimHiRgb vimNumber
 hi def link vimHiGui vimHiTerm
 hi def link vimHiStartStop vimHiTerm
 hi def link vimHLGroup vimGroup
Index: src/syntax.c
===================================================================
--- src/syntax.c (revision 647)
+++ src/syntax.c (working copy)
@@ -448,6 +448,9 @@
 static int get_id_list __ARGS((char_u **arg, int keylen, short **list));
 static void syn_combine_list __ARGS((short **clstr1, short **clstr2, int list_op));
 static void syn_incl_toplevel __ARGS((int id, int *flagsp));
+static int cube_nr_is_grey __ARGS((char_u nr));
+static char_u closest_cube_step __ARGS((short size, char_u component, int skip_grey));
+static int approximate_cterm_from_gui __ARGS((char_u* hex));
 
 /*
  * Start the syntax recognition for a line.  This function is normally called
@@ -6952,6 +6955,13 @@
 
     if (VIM_ISDIGIT(*arg))
  color = atoi((char *)arg);
+    else if (*arg == '#')
+    {
+ if ((color = approximate_cterm_from_gui(arg)) == -1) {
+    error = TRUE;
+    break;
+ }
+    }
     else if (STRICMP(arg, "fg") == 0)
     {
  if (cterm_normal_fg_color)
@@ -9118,6 +9128,186 @@
 }
 #endif
 
+/*
+ * The majority of colors in both the 256 color colorcube and the 88 color
+ * colorcube can only be used in greys.  That is, even though 0xEE might be
+ * valid to use in a color, it can only be used as 0xEEEEEE.  This function
+ * returns true if a particular r/g/b val can only be combined with itself.
+ */
+    static int
+cube_nr_is_grey(nr)
+    char_u nr;
+{
+    /*
+     * Only the 8 colors below can be used outside of greys, including both
+     * 256 color and 88 color cubes.  There is no place where a grey-only color
+     * on one cube can be mix-and-matched on the other, so this simplistic
+     * solution works.
+     */
+    return (nr != 0x00 && nr != 0x8B
+         && nr != 0xCD && nr != 0xFF
+         && nr != 0x5F && nr != 0x87
+         && nr != 0xAF && nr != 0xD7);
+}
+
+/*
+ * Given an r, g, or b component and a colorcube size to use, this function
+ * will return a number representing the closest colorcube value to that
+ * component.  If skip_grey is true, it will not return a grey.  If the return
+ * value is greater than or equal to 80, it is the colorcube value of a grey,
+ * otherwise it will be in the range [0-5] for a 256 color colorcube, and
+ * [0-3] for an 88 color colorcube; an index along a side of the cube.
+ */
+    static char_u
+closest_cube_step(size, component, skip_grey)
+    short size;
+    char_u component;
+    int skip_grey;
+{
+    /* All possible steps on an 88 color colorcube */
+    static char_u vals_88[12] = { 0x00, 0x2E, 0x5C, 0x73, 0x8B, 0xA2,
+                                        0xB9, 0xCD, 0xD0, 0xE7, 0xFF };
+
+    /* And on a 256 color colorcube */
+    static char_u vals_256[30] = { 0x00, 0x08, 0x12, 0x1C, 0x26, 0x30,
+                                         0x3A, 0x44, 0x4E, 0x58, 0x5F, 0x62,
+                                         0x6C, 0x76, 0x80, 0x87, 0x8A, 0x94,
+                                         0x9E, 0xA8, 0xAF, 0xB2, 0xBC, 0xC6,
+                                         0xD0, 0xD7, 0xDA, 0xE4, 0xEE, 0xFF };
+
+    unsigned i, end, n_color, n_grey, grey;
+    char_u *list;
+
+    n_color = n_grey = 0;
+
+    if (size == 88)
+    {
+ end  = 11;
+ list = vals_88;
+    }
+    else
+    {
+ end  = 30;
+ list = vals_256;
+    }
+
+    for (i = 0; i < end - 1; /*NOP*/)
+    {
+ int j = 1;
+
+ if (cube_nr_is_grey(list[i]))
+    ++n_grey;
+ else
+    ++n_color;
+
+ while (skip_grey && cube_nr_is_grey(list[i+j]))
+ {
+    ++n_grey;
+    ++j;
+ }
+
+        /* The component is closest to list[i] if it is less than or equal to
+         * the midpt of list[i] and list[i+1] */
+ if (component <= (list[i] + list[i+j]) / 2) {
+    grey = cube_nr_is_grey(list[i]);
+    break;
+ }
+
+ i += j;
+    }
+
+
+    if (i == end - 1)
+        /* Last one is a color on both cubes, and it wasn't yet counted so we
+         * don't subtract 1 */
+ return n_color;
+    else if (!grey)
+ return n_color - 1;
+    else
+ return (size == 88 ? 80 : 232) + n_grey - 1;
+}
+
+/*
+ * Given a hex color of the form "#rrggbb", returns the closest cterm color on
+ * the currently available colorcube (based on  &t_Co).  This will only work if
+ * the current number of colors is greater than or equal to 88; it returns an
+ * error code of -1 upon failure.
+ */
+    static int
+approximate_cterm_from_gui(hex)
+    char_u* hex;
+{
+    int i;
+    char_u rgb[3] = { 0, 0, 0 };  // These each store { rr, gg, bb }
+    char_u vals[3];
+    unsigned colors;
+
+    colors = t_colors;
+#ifdef FEAT_GUI
+    /*
+     * Don't ever give E805 error in gui, just pick a reasonable colorcube.
+     * Otherwise, colorschemes that set ctermfg=#rrggbb will give errors when
+     * used in the gui.
+     */
+    if (colors < 88 && gui.in_use)
+ colors = 256;
+#endif
+
+    if (colors < 88)
+    {
+ EMSG(_("E804: Too few terminal colors"));
+ return -1;
+    }
+
+    if (*hex == '#')
+ ++hex;
+
+    for (i = 0; i < 6; ++i) {
+ int order = (i%2 ? 1 : 16);
+
+ 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;
+ else
+    break;
+    }
+
+    /* Too few characters, too many, or not all in [0-9A-Fa-f] */
+    if (i != 6 || hex[6] != NUL) {
+ /* Should this get a new error number, or should I reuse E254? */
+ EMSG(_("E805: Bad color spec provided."));
+ return -1;
+    }
+
+    vals[0] = closest_cube_step(colors, rgb[0], FALSE);
+    vals[1] = closest_cube_step(colors, rgb[1], FALSE);
+    vals[2] = closest_cube_step(colors, rgb[2], FALSE);
+
+    if (vals[0] != vals[1] || vals[1] != vals[2])
+    {
+ /*
+ * The author obviously didn't want a grey, and having #003000 rounded
+ * to #121212 rather than #005F00 bothers me.  Search again, skipping
+ * grey-only values.  This extra search just guarantees that unless the
+ * requested color is sufficiently close to a grey, we will use
+ * a color, even if it's further away.
+ */
+ vals[0] = closest_cube_step(colors, rgb[0], TRUE);
+ vals[1] = closest_cube_step(colors, rgb[1], TRUE);
+ vals[2] = closest_cube_step(colors, rgb[2], TRUE);
+    }
+
+    if (vals[0] == vals[1] && vals[1] == vals[2] && vals[0] >= 80)
+ return vals[0];
+    else if (colors == 88)
+ return (vals[0] * 16 + vals[1] * 4 + vals[2] + 16);
+    else
+ return (vals[0] * 36 + vals[1] * 6 + vals[2] + 16);
+}
+
 #if defined(FEAT_GUI) || defined(PROTO)
 /*
  * Free all the highlight group fonts.

[Bram Moolenaar]

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 #0000ff.  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 -- [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.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

[Thomas Dickey]

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 #0000ff.  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 <[hidden email]>
Subject: Re: X graphics
Newsgroups: comp.os.linux.x
References: <[hidden email]>
<[hidden email].>
Organization: RadixNet Internet Services
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (SunOS/
5.8 (sun4u))
Status: RO
Content-Length: 937
Lines: 23

Dances With Crows <[hidden email]> 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 to try out?
>
> --
> From "know your smileys":
>  |-( Contact lenses, but has lost them
>
>  /// 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.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

[Matt Wozniski-2]

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 #0000ff.  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
> > + 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.

Yes.. But it doesn't help for xterm -> screen -> vim, with the same
problem as above.  I don't know that it's sufficiently generic, and
a pointer in the help seems like a better idea...

> The stuff to haneld grey and non-grey colors looks like a bit of a hack.
> Isn't there a more consistent solution?

I'm open to suggestions.  A better solution might be to figure out if
the author probably wanted a grey, by saying for instance,
abs(r-b) < 16 && abs(b-g) < 16 && abs(g-r) < 16 and then filtering for
lowest Euclidean distance in rgb space, excluding greys if necessary.

Either way, it's not worth focusing on if we plan to support
customized, as opposed to default, palettes.  The algorithm will need
complete retooling; the current algorithm does revolve quite tightly
around the standard values.

> > + 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 figured there was a utility function around for this and I just
couldn't find it.

Looking at the #if defined()'s around hexhex2nr, what #defines are
paired with this cterm[fb]g=#rrggbb feature?  Is it just
#ifndef ALWAYS_USE_GUI, or is there something else that needs to be
considered?  Is this useful in windows builds, for instance?

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

Absolutely.  I've attached copies of my two favorite colorschemes,
brookstream for dark terminals and autumnleaf for light terminals,
each modified to work with cterm[fb]g=#rrggbb values.  They'll work in
a patched vim, in both an 88 or 256 color terminal or in gvim, but
they won't work in an 8 or 16 color terminal.

~Matt

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---


" Vim color file
" Maintainer: Anders Korte
" Last Change: 17 Oct 2004

" AutumnLeaf color scheme 1.0

set background=light

hi clear

if exists("syntax_on")
    syntax reset
endif

let colors_name="autumnleaf-rgb"

" Colors for the User Interface.

hi Cursor ctermbg=#aa7733 guibg=#aa7733   ctermfg=#ffeebb guifg=#ffeebb   cterm=bold gui=bold
hi Normal ctermbg=#fffdfa guibg=#fffdfa ctermfg=black guifg=black cterm=none gui=none
hi NonText ctermbg=#eafaea guibg=#eafaea   ctermfg=#000099 guifg=#000099   cterm=bold gui=bold
hi Visual ctermbg=#fff8cc guibg=#fff8cc   ctermfg=black guifg=black cterm=none gui=none
" hi VisualNOS

hi Linenr ctermbg=bg guibg=bg ctermfg=#999999 guifg=#999999 cterm=none gui=none

" Uncomment these if you use Diff...??
" hi DiffText ctermbg=#cc0000 guibg=#cc0000 ctermfg=white guifg=white cterm=none gui=none
" hi DiffAdd ctermbg=#0000cc guibg=#0000cc ctermfg=white guifg=white cterm=none gui=none
" hi DiffChange ctermbg=#990099 guibg=#990099 ctermfg=white guifg=white cterm=none gui=none
" hi DiffDelete ctermbg=#888888 guibg=#888888 ctermfg=#333333 guifg=#333333 cterm=none gui=none

hi Directory ctermbg=bg guibg=bg ctermfg=#337700 guifg=#337700   cterm=none gui=none

hi IncSearch ctermbg=#c8e8ff guibg=#c8e8ff ctermfg=black guifg=black cterm=none gui=none
hi Search ctermbg=#c8e8ff guibg=#c8e8ff ctermfg=black guifg=black cterm=none gui=none
hi SpecialKey ctermbg=bg guibg=bg ctermfg=fg guifg=fg     cterm=none gui=none
hi Titled ctermbg=bg guibg=bg ctermfg=fg guifg=fg cterm=none gui=none

hi ErrorMsg    ctermbg=bg guibg=bg ctermfg=#cc0000 guifg=#cc0000   cterm=bold gui=bold
hi ModeMsg    ctermbg=bg guibg=bg ctermfg=#003399 guifg=#003399   cterm=none gui=none
hi link MoreMsg    ModeMsg
hi link Question    ModeMsg
hi WarningMsg    ctermbg=bg guibg=bg ctermfg=#cc0000 guifg=#cc0000   cterm=bold gui=bold

hi StatusLine ctermbg=#ffeebb guibg=#ffeebb ctermfg=black guifg=black cterm=bold gui=bold
hi StatusLineNC ctermbg=#aa8866 guibg=#aa8866 ctermfg=#f8e8cc guifg=#f8e8cc cterm=none gui=none
hi VertSplit ctermbg=#aa8866 guibg=#aa8866 ctermfg=#ffe0bb guifg=#ffe0bb cterm=none gui=none

" hi Folded
" hi FoldColumn
" hi SignColumn


" Colors for Syntax Highlighting.

hi Comment ctermbg=#ddeedd guibg=#ddeedd ctermfg=#002200 guifg=#002200 cterm=none gui=none

hi Constant ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399 cterm=bold gui=bold
hi String ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399 cterm=italic gui=italic
hi Character ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399 cterm=italic gui=italic
hi Number ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399 cterm=bold gui=bold
hi Boolean ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399 cterm=bold gui=bold
hi Float ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399 cterm=bold gui=bold

hi Identifier ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399 cterm=none gui=none
hi Function ctermbg=bg guibg=bg    ctermfg=#0055aa guifg=#0055aa cterm=bold gui=bold
hi Statement ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399 cterm=none gui=none

hi Conditional ctermbg=bg guibg=bg    ctermfg=#aa7733 guifg=#aa7733 cterm=bold gui=bold
hi Repeat ctermbg=bg guibg=bg    ctermfg=#aa5544 guifg=#aa5544 cterm=bold gui=bold
hi link Label Conditional
hi Operator ctermbg=bg guibg=bg    ctermfg=#aa7733 guifg=#aa7733 cterm=bold gui=bold
hi link Keyword Statement
hi Exception ctermbg=bg guibg=bg    ctermfg=#228877 guifg=#228877 cterm=bold gui=bold

hi PreProc    ctermbg=bg guibg=bg ctermfg=#aa7733 guifg=#aa7733 cterm=bold gui=bold
hi Include    ctermbg=bg guibg=bg ctermfg=#558811 guifg=#558811 cterm=bold gui=bold
hi link Define    Include
hi link Macro    Include
hi link PreCondit   Include

hi Type ctermbg=bg guibg=bg    ctermfg=#007700 guifg=#007700 cterm=bold gui=bold
hi link StorageClass Type
hi link Structure Type
hi Typedef ctermbg=bg guibg=bg    ctermfg=#009900 guifg=#009900 cterm=italic gui=italic

hi Special    ctermbg=bg guibg=bg    ctermfg=fg guifg=fg    cterm=none gui=none
hi SpecialChar    ctermbg=bg guibg=bg    ctermfg=fg guifg=fg    cterm=bold gui=bold
hi Tag    ctermbg=bg guibg=bg    ctermfg=#003399 guifg=#003399   cterm=bold gui=bold
hi link Delimiter   Special
hi SpecialComment   ctermbg=#dddddd guibg=#dddddd   ctermfg=#aa0000 guifg=#aa0000   cterm=none gui=none
hi link Debug    Special

hi Underlined ctermbg=bg guibg=bg ctermfg=blue guifg=blue cterm=underline gui=underline

hi Title    ctermbg=bg guibg=bg ctermfg=fg guifg=fg     cterm=bold gui=bold
hi Ignore   ctermbg=bg guibg=bg ctermfg=#999999 guifg=#999999 cterm=none gui=none
hi Error    ctermbg=red guibg=red ctermfg=white guifg=white cterm=none gui=none
hi Todo    ctermbg=bg guibg=bg ctermfg=#aa0000 guifg=#aa0000   cterm=none gui=none

"--------------------------------------------------------------------
" Name Of File: brookstream.vim.
" Description: Gvim colorscheme, works best with version 6.1   cterm .
" Maintainer: Peter B�ckstr�m.
" Creator: Peter B�ckstr�m.
" URL: http://www.brookstream.org (Swedish).
" Credits: Inspiration from the darkdot scheme.
" Last Change: Friday, April 13, 2003.
" Installation: Drop this file in your $VIMRUNTIME/colors/ directory.
"--------------------------------------------------------------------

set background=dark
hi clear
if exists("syntax_on")
    syntax reset
endif
let g:colors_name="brookstream-rgb"

"--------------------------------------------------------------------

hi Normal           gui=none  cterm=none  ctermbg=#000000 guibg=#000000  ctermfg=#bbbbbb guifg=#bbbbbb
hi Cursor                                 ctermbg=#44ff44 guibg=#44ff44  ctermfg=#000000 guifg=#000000
hi Directory                                                             ctermfg=#44ffff guifg=#44ffff
hi DiffAdd                                ctermbg=#080808 guibg=#080808  ctermfg=#ffff00 guifg=#ffff00
hi DiffDelete                             ctermbg=#080808 guibg=#080808  ctermfg=#444444 guifg=#444444
hi DiffChange                             ctermbg=#080808 guibg=#080808  ctermfg=#ffffff guifg=#ffffff
hi DiffText                               ctermbg=#080808 guibg=#080808  ctermfg=#bb0000 guifg=#bb0000
hi ErrorMsg                               ctermbg=#880000 guibg=#880000  ctermfg=#ffffff guifg=#ffffff
hi Folded                                                                ctermfg=#000088 guifg=#000088
hi IncSearch                              ctermbg=#000000 guibg=#000000  ctermfg=#bbcccc guifg=#bbcccc
hi LineNr                                 ctermbg=#050505 guibg=#050505  ctermfg=#4682b4 guifg=#4682b4
hi ModeMsg                                                               ctermfg=#ffffff guifg=#ffffff
hi MoreMsg                                                               ctermfg=#44ff44 guifg=#44ff44
hi NonText                                                               ctermfg=#4444ff guifg=#4444ff
hi Question                                                              ctermfg=#ffff00 guifg=#ffff00
hi SpecialKey                                                            ctermfg=#4444ff guifg=#4444ff
hi StatusLine       gui=none  cterm=none  ctermbg=#2f4f4f guibg=#2f4f4f  ctermfg=#ffffff guifg=#ffffff
hi StatusLineNC     gui=none  cterm=none  ctermbg=#bbbbbb guibg=#bbbbbb  ctermfg=#000000 guifg=#000000
hi Title                                                                 ctermfg=#ffffff guifg=#ffffff
hi Visual           gui=none  cterm=none  ctermbg=#bbbbbb guibg=#bbbbbb  ctermfg=#000000 guifg=#000000
hi WarningMsg                                                            ctermfg=#ffff00 guifg=#ffff00

" syntax highlighting groups ----------------------------------------

hi Comment                                                               ctermfg=#696969 guifg=#696969
hi Constant                                                              ctermfg=#00aaaa guifg=#00aaaa
hi Identifier                                                            ctermfg=#00e5ee guifg=#00e5ee
hi Statement                                                             ctermfg=#00ffff guifg=#00ffff
hi PreProc                                                               ctermfg=#8470ff guifg=#8470ff
hi Type                                                                  ctermfg=#ffffff guifg=#ffffff
hi Special          gui=none  cterm=none                                 ctermfg=#87cefa guifg=#87cefa
hi Underlined       gui=bold  cterm=bold                                 ctermfg=#4444ff guifg=#4444ff
hi Ignore                                                                ctermfg=#444444 guifg=#444444
hi Error                                  ctermbg=#000000 guibg=#000000  ctermfg=#bb0000 guifg=#bb0000
hi Todo                                   ctermbg=#aa0006 guibg=#aa0006  ctermfg=#fff300 guifg=#fff300
hi Operator         gui=none  cterm=none                                 ctermfg=#00bfff guifg=#00bfff
hi Function                                                              ctermfg=#1e90ff guifg=#1e90ff
hi String           gui=none  cterm=none                                 ctermfg=#4682b4 guifg=#4682b4
hi Boolean                                                               ctermfg=#9bcd9b guifg=#9bcd9b

[Nikolai Weibull-11]

On Nov 11, 2007 1:24 PM, Bram Moolenaar <[hidden email]> 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 #0000ff.  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 #0000fe, Vim should
be able to determine that #0000ff is the best match.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

[Gautam Iyer-3]

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

[Tony Mechelynck]

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 #0000fe, Vim should
> be able to determine that #0000ff 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
-~----------~----~----~----~------~----~------~--~---

[Matt Wozniski-2]

On Nov 12, 2007 4:29 AM, Gautam Iyer <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

[Gautam Iyer-3]

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

[Nikolai Weibull-11]

On Nov 12, 2007 8:42 PM, Gautam Iyer <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

[Gautam Iyer-3]

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

[Paul Evans-7]

On Mon, 12 Nov 2007 14:22:21 -0800
Gautam Iyer <[hidden email]> wrote:

> especially when I press them with a modifier
> (e.g. Control+Left/Right).

That's a separate issue, entirely unrelated to the number of colours.

It's been somewhat of a hobbyhorse of mine for a few years - I've made
some notes on the subject:

   http://home.leonerd.org.uk/local/terminal.html

------

Vim has trouble parsing the way newer XTerms encode modified cursor keys
(that's Up/Down/Left/Right, Insert/Del/Home/End/PageUp/PageDown, and
others, combined with Ctrl/Shift/Alt/Hyper/Super/... modifier keys).

This problem comes from the way that 'terminfo' basically just provides a
static mapping from byte sequences into a big enumeration of key
constants. The way xterm encodes it doesn't work like this.

Xterm uses the CSIs the encode cursor movement or function keys, and
provides extra parameters.

[[A brief introduction to CSIs:

A CSI is basically a procedure call - it has a method name and some
(possibly none) parameters. The name is a single character in the range
[\x40-\x7e], and the parameters are semicolon-separated numbers. CSIs are
used to send control sequences from the application, into the terminal.

The CSI for "move cursor up", for example is usually encoded

  CSI A

It includes a number parameter to give it a count, defaulting to 1. This
CSI does not give meanings for any of the other positional parameters. If
a parameter is missing, it is presumed to have its default value - this
is how "CSI A" alone can stand for it. Other valid encodings could be

  CSI ; A
  CSI 1 A
  CSI 1 ; A
  etc...

All of these mean "move up 1 position".

When terminals started gaining extra keys like cursor movement keys, that
do not have standard ASCII mappings, these CSIs were extended to encode
keys back into the application. CSI A/B/C/D encode up/down/right/left.
For most of the other "special" keys (such as F1-F12 and
PageUp/PageDown), a more generic mechanism instead is used, where they
are given function numbers, and the "~" CSI is used. This takes one
parameter, the function key number. PageUp / PageDown are given 5 and 6.
A "PageUp" key is thus encoded

  CSI 5 ~

Equally valid, are any of the other ways to encode this CSI

  CSI 5 ; ~
  CSI 5 ; 1 ~
  CSI 5 ; ; ; ; ~
  etc...
]]

To represent modified movement keys or function keys, xterm uses the
second position of the various CSIs normally used, to encode the modifier
bitmask. A default of "1" is assumed to be in effect if not otherwise
specified, so the encoding uses a 1+bitmask scheme:

  1 = no modifier
  2 = shift
  3 = alt
  4 = shift+alt
  5 = ctrl
  6 = shift+ctrl
  7 = alt+ctrl
  8 = shift+alt+ctrl
  etc...

This is placed in the second CSI parameter. So, Alt-Left and
Alt-PageDown might be encoded as

  CSI 1 ; 3 D
  CSI 5 ; 3 ~

This scheme generalises - any function key or movement key can be
combined with any modifier.

Vim has a problem parsing these currently, because of (I believe)
inflexibilities in terminfo. It only has a static mapping from bytes into
the key enumeration. It cannot parameterise the modifier bits.

While it could be possible to give a large list of K*2^M mappings (for K
keys and M possible modifiers), a more efficient scheme ought to be
sought, where Vim could directly parse the CSI sequences. This would also
avoid the current failure mode.

The current failure is that, for example, when xterm sends a Ctrl-Left
key, it sends

  CSI 1 ; 5 D

Vim reads that as far as the semicolon, and finds it doesn't correspond
to any valid key sequence, so instead interprets it as "5D", which
results in 5 lines of text being deleted.

I would like to assist in fixing this issue, but I'm not really sure
where to start, code-wise. Should Vim somehow have a special case for CSI
parsing, if it recognises the $TERM is one that sends CSIs, and use that
instead? What makes xterm "special" here? Would other terminals do it?

Should terminfo be somehow extended? This seems less desirable - given
the arbitrary way CSI parameters can be sent, it would seem useful to
have some form of parsing logic that can pull apart the parameters,
whatever they may be, even if the logic beyond that just ignores them.
This would at least avoid problems in the future, if a meaning for the
3rd position was ever given, for example.

Or maybe some new keyboard-input parsing library needs to be provided,
that can be used beyond vim, into any program that reads keyboard input
and would care about modifiers. Even if not, it would help to avoid for
example readline's failure to handle the same CSIs when running handling
input for bash.

--
Paul "LeoNerd" Evans

[hidden email]
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

[Matthew Woehlke]

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

[Matt Wozniski-2]

On Nov 12, 2007 5:41 AM, Matt Wozniski <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

[Nico Weber-3]

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

[Matt Wozniski-2]

On Dec 21, 2007 5:18 AM, Nico Weber <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

[Matt Wozniski-2]

On Dec 20, 2007 11:44 PM, Matt Wozniski <[hidden email]> 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
-~----------~----~----~----~------~----~------~--~---

[Sean Donner-2]

Hello all,

I just wanted to let you know that this patch works like a charm and
it's by far the closest to having gvim-like color themes inside my
terminal; PuTTY with "TERM=xterm-256color" in my case.

I happened to be fortunate enough to ask the right question at the
right time and stumble across this patch by conversing with Matt in
#vim on freenode.  Together, we put together a vim regex script that
is easily sourced on your favorite vim colorscheme to convert it to
the correct #rrggbb format.

regex script available here --> http://www.cs.drexel.edu/~mjw452/ctermrgbify-scheme.vim

His latest source patch applied cleanly to my Slackware-12 vim-7.1
package and only minor tweaking was required to the runtime patch
since Matt diff'd against the latest svn build.

I highly suggest that you consider this for inclusion into the main
trunk.

Regards,

-Sean


On Jan 3, 1:30 pm, "Matt Wozniski" <[hidden email]> wrote:

> On Dec 20, 2007 11:44 PM, Matt Wozniski <[hidden email]> 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.vimand
> >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
-~----------~----~----~----~------~----~------~--~---

[Neil Moore-2]

On Jan 3, 4:30 pm, "Matt Wozniski" <[hidden email]> wrote:

> On Dec 20, 2007 11:44 PM, Matt Wozniski <[hidden email]> 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.vimand
> >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

It works well for me (after editing my system colorschemes).  A few
things I noticed:

 * The new code be wrapped in an #ifdef FEAT_SYN_HL . Certain of the
prototypes are, which means the code doesn't compile correctly when
this feature is disabled.
 * hexhex2nr in charset.c should be defined whenever the patch is
included (as noted in a comment).  Adding defined(FEAT_SYN_HL) to the
list of conditions should work.

 * As discussed on IRC, colorschemes will have to define colors
differently depending on whether one is in 16- or 256-color mode.  If
hex colors aren't going to be supported for 16-color mode (and I think
your arguments here are convincing), maybe there should be separate
hctermfg/hctermbg arguments for high-color schemes.  This would
require less work on the part of colorscheme authors to support both
kinds of terminals (they could keep ctermfg=14 and add a separate
hctermfg=#ff33ff to support high-color terms).

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

[Richard Musil]

On Dec 21 2007, 6:44 am, "Matt Wozniski" <[hidden email]> 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 (svn@r1029). 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
-~----------~----~----~----~------~----~------~--~---