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