Patch to allow ctermfg or bg values as #rrggbb
Matthew Wozniski
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
Bram Moolenaar
Matthew Wozniski 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.
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 -- Br...@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 ///
dickey
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 <dic...@saltmine.radix.net>
Subject: Re: X graphics
Newsgroups: comp.os.linux.x
References: <iha3m4-...@royalty.no-ip.org>
<138u3oo...@corp.supernews.>
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 <danSPANcesw...@gmail.com> 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
Matthew Wozniski
>
> 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
Nikolai Weibull
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.
Gautam Iyer
> > 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.
Tony Mechelynck
[...]
> 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.
Matt Wozniski
>
> 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
Gautam Iyer
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.
Nikolai Weibull
> 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.
Gautam Iyer
> > 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.
Paul LeoNerd Evans
Gautam Iyer <gi1...@stanford.edu> 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
leo...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
Matthew Woehlke
> Bram Moolenaar wrote:
>> Do all the terminals supporting 88 and 256 colors really use the same
>> color values?
>
> 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
Matt Wozniski
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
Nico Weber
> 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
Matt Wozniski
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
Matt Wozniski
> ...
> 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
Sean Donner
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
Neil Moore
> On Dec 20, 2007 11:44 PM, Matt Wozniski <m...@drexel.edu> 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-runtime.diff(runtime,
>
> > 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
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).
Richard Musil
> 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
Bram Moolenaar
Matt Wozniski wrote:
[about a patch to support #rrggbb in a terminal]
Where can I find the latest version of this patch? I only see one that
is two years old.
--
Shit makes the flowers grow and that's beautiful
Tony Mechelynck
>
> 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."
Benjamin R. Haskell
> 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
Benjamin R. Haskell
> 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
Tony Mechelynck
> 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
>> cterm= 8 to 16 colors; gui= 88 to 16777216 colors � CSApprox does the
>> "dirty work" of converting "gui" rrggbb values to palette ordinal
>> numbers when in 88- or 256-color consoles.
>
> In the off-chance you hadn't noticed, Matt Wozniski is the author of
> both the patch in question and the CSApprox plugin.
>
> I'm not sure how either the patch or the plugin works currently, but
> personally, I'd prefer that #rrggbb conversion for terminals gets
> integrated into the main program.
> I agree that getting it working so that colorschemes can be written
> toward the following guidelines would be most convenient:
>
> term= no 'colors'
> cterm= 8 or 16 colors
> gui= 88 / 256 / 'true' colors
>
> But as I said, I'd rather it not require a plugin.
>
Well, at least we agree on one point: we'd prefer guifg=#123456 to work
in 88+ color terminal, rather than ctermfg=#123456 which would prevent
writing "ctermfg=cyan guifg=#123456" to cover low-color terminals too.
OTOH, I believe that CSApprox does the job well, with no appreciable
delay, and I don't feel the necessity of patching the C code. It even
has accessible "hooks" for special cases (see below). What _would_ be
useful would be to distribute that plugin as part of the vanilla Vim
distribution, maybe "disabled matchit-like" if people don't want Vim in
xterm-256 and gvim to look alike.
Example of a special case: (my vimrc sets CSApprox_loaded to 1 on the
Linux console and) my colorscheme includes the following:
> " display the status line of the active window in a distinctive color:
> " bold black on bright red in the GUI, white on green in the console
> " (where the bg is never bright, and dark red is sometimes an ugly sort
> " of reddish brown).
> hi StatusLine gui=NONE,bold guibg=red guifg=black
> \ cterm=NONE,bold ctermbg=darkgreen ctermfg=white
> hi WildMenu gui=NONE,bold guibg=green guifg=black
> \ cterm=NONE,bold ctermbg=black ctermfg=white
> " make the status line bold-reverse (but B&W) for inactive windows
> hi StatusLineNC gui=reverse,bold
> \ cterm=NONE ctermbg=black ctermfg=lightgrey
> " make the active status line colours alternate between two settings
> " to give a visual notice of the CursorHold/CursorHoldI events
> if ! exists("s:statuslineflag")
> let s:statuslineflag = 0
> endif
> "
> " The following 'fancy footwork' is needed to have our CursorHold autocommand
> " work smoothly with 256-color cterms handled by the 3rd-party csapprox.vim plugin
> if exists('g:CSApprox_approximator_function')
> let s:ctbg1 = g:CSApprox_approximator_function(0, 255, 0) " green
> let s:ctbg2 = g:CSApprox_approximator_function(255, 0, 0) " red
> let s:ctfg = g:CSApprox_approximator_function(0, 0, 0) " black
> else
> let s:ctbg1 = 'darkgreen'
> let s:ctbg2 = 'black'
> let s:ctfg = 'white'
> endif
>
> function! ToggleStatusLine()
> if s:statuslineflag
> exe 'hi StatusLine'
> \ 'cterm=NONE,bold ctermbg=' . s:ctbg1 'ctermfg=' . s:ctfg
> \ 'gui=NONE,bold guibg=green guifg=black'
> exe 'hi WildMenu'
> \ 'cterm=NONE,bold ctermbg=' . s:ctbg2 'ctermfg=' . s:ctfg
> \ 'gui=NONE,bold guibg=red guifg=black'
> else
> exe 'hi StatusLine'
> \ 'cterm=NONE,bold ctermbg=' . s:ctbg2 'ctermfg=' . s:ctfg
> \ 'gui=NONE,bold guibg=red guifg=black'
> exe 'hi WildMenu'
> \ 'cterm=NONE,bold ctermbg=' . s:ctbg1 'ctermfg=' . s:ctfg
> \ 'gui=NONE,bold guibg=green guifg=black'
> endif
> let s:statuslineflag = ! s:statuslineflag
> endfunction
>
> exe "augroup" s:colors_name
> au! CursorHold,CursorHoldI * call ToggleStatusLine()
> au! ColorScheme *
> \ if g:colors_name != s:colors_name | exe "au!" s:colors_name | endif
> augroup END
Best regards,
Tony.
--
Democracy, n.:
A government of the masses. Authority derived through mass
meeting or any other form of direct expression. Results in mobocracy.
Attitude toward property is communistic... negating property rights.
Attitude toward law is that the will of the majority shall regulate,
whether it is based upon deliberation or governed by passion,
prejudice, and impulse, without restraint or regard to consequences.
Result is demagogism, license, agitation, discontent, anarchy.
-- U. S. Army Training Manual No. 2000-25 (1928-1932),
since withdrawn.
Benjamin R. Haskell
> 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
Narrowing your example down to just the portion (I think?) that uses
CSApprox, and simplifying a bit to isolate the effect of CSApprox:
" elsewhere - disable CSApprox if on linux console
if exists('g:CSApprox_approximator_function')
let s:ctbg1 = g:CSApprox_approximator_function(0, 255, 0) " green
let s:ctbg2 = g:CSApprox_approximator_function(255, 0, 0) " red
else
let s:ctbg1 = 'darkgreen'
let s:ctbg2 = 'black'
endif
function! ToggleStatusLine()
if s:statuslineflag
exe 'hi StatusLine ctermbg=' . s:ctbg1 . 'guibg=green'
else
exe 'hi StatusLine ctermbg=' . s:ctbg2 . 'guibg=red'
endif
let s:statuslineflag = ! s:statuslineflag
endfunction
Why is that preferable to:
" elsewhere - set g:on_linux_console if on linux console
if !exists('g:on_linux_console')
let s:ctbg1 = '#00ff00'
let s:ctbg2 = '#ff0000'
else
let s:ctbg1 = 'darkgreen'
let s:ctbg2 = 'black'
endif
function! ToggleStatusLine()
if s:statuslineflag
exe 'hi StatusLine ctermbg=' . s:ctbg1 . 'guibg=green'
else
exe 'hi StatusLine ctermbg=' . s:ctbg2 . 'guibg=red'
endif
let s:statuslineflag = ! s:statuslineflag
endfunction
It seems to me it's just something you want to special-case regardless
of whether you're using CSApprox, and using built-in #rrggbb recognition
prevents having to call a plugin function.
Or am I missing something with which one of ctermbg/guibg applies at
what points?
linux terminal = 8 colors (modulo playing with fb), but special-cased,
so ctermbg=darkgreen
xterm = 256 colors, so you want ctermbg='#00ff00' (green) rather than
guibg=green? (6 of one, half a dozen of the other)
gui = 24-bit color, so guibg=green
I agree, though, that a disabled-but-shipped plugin would be better than
nothing.
--
Best,
Ben
Dominique Pellé
> 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
Tony Mechelynck
> Tony Mechelynck wrote:
>
>> OTOH, I believe that CSApprox does the job well, with no appreciable delay,
>> and I don't feel the necessity of patching the C code.
>
> Hi Tony
>
> I also use CSApprox which I find very nice. I measured how long it
> 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:
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" :-)
>
> 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
>
Best regards,
Tony.
--
By trying, we can easily learn to endure adversity -- another man's, I
mean.
-- Mark Twain
Gary Johnson
> 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
Tony Mechelynck
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
Matt Wozniski
>
> 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 9cf111138f, 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!
Ingo Karkat
> 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 --