Matt Wozniski wrote:
> On Sun, Feb 15, 2009 at 10:35 AM, Stahlman Family wrote:
>> Ok. I *think* I've got it. You have very fine (24-bit) control
>> over a single color (the default) for foreground and background.
>
> Right.
>
>> A subset of (e.g.) 6, 14 or 254 colors from the 24-bit range is
>> made available to color text applications such as vim.
>
> 8, 16, 88, or 256 - these colors are completely independent of the
> default. FWIW, true 8-color terminals are very rare these days.
> What are much more common are what vim's help informally refers to
> as "8*" color terminals, which support 16 foreground colors and only
> 8 background colors. This is the case for, for instance, the linux
> consoles /dev/tty1-6. But, my point is that the default foreground
> and background - and a few other colors - don't have numbers between
> 0 and t_Co defined for them - they exist outside that range of
> numbers. Think about it this way: even in a monochrome terminal,
> where the applications can't request that any particular color be
> used to draw a particular character, there will still be a color for
> the foreground, the background, and the cursor. When colors were
> added, there were suddenly 8 colors - plus the color of the
> foreground, background, and cursor.
>
>> There's no guarantee that the default color defined by the user is
>> present in the subset.
>
> Right.
>
>> At any rate, I plan to do some reading on the intricacies of color
>> terminals. I'll likely have a much better understanding after I've
>> done so...
>
> /me points at http://www.xfree86.org/current/ctlseqs.html - it lays
> out every single control sequence that xterm understands. Feel free
> to contact me off list with any non-vim questions about terminals,
> and I'll be happy to help, too.
Excellent! Thanks. This is just the sort of reference I needed, and your
explanation of things has been very enlightening.
>
>> I believe I've got it now. I reread this after responding to
>> Tony's email, and one of the remaining questions I had (whether
>> Vim could request background color equal to default when the
>> default doesn't correspond to one of the colors on the "cube") was
>> answered.
>
> Technically, it's possible in xterms to change the default
> background color or default foreground color on the fly, but vim
> doesn't use this functionality - and it doesn't work in all
> terminals, anyway. Likewise, xterm has a "hidden" attribute that
> you can set for some text, which sets it to be invisible - but,
> again, this is only on xterms (technically, vt300's), and vim
> doesn't use this feature.
>
>> Since there's no way to request that foreground be set to the
>> default background, it is not always possible to hide text
>> completely.
>
> Like I said. ;-) If there is a way to do it without changing vim's
> source, I don't see it.
>
>> I suspect, though, that the color on the color cube "nearest" to
>> the default background would typically be close enough (especially
>> in 256 color terminals) effectively to hide the text.
>
> *shrug*, you get the same sort of scenario as the colorschemes have,
> with Ignore text that's hard to see but not invisible.
Yes, although the colorscheme in question was intentionally making the
foreground different from the background: grey40 (fg) vs. grey 20 (bg)
in the gui, and dark grey on light background in the cterm. I was simply
saying that it would typically be possible to find a foreground color
that comes close to matching the background, though as you've pointed
out, it may not be possible to do so programmatically...
As for the txtfmt plugin... I suppose I need to create a txtfmt-specific
highlight group (e.g., Tf_Ignore), which is not (necessarily) linked to
Ignore. For the gui, I can simply define this group as guifg=bg. The
cterm case would need to be treated a bit specially... If the output of
":hi Tf_Ignore" indicates that the user has already defined this group,
I would defer to his setting (which presumably has been chosen to hide
text as well as possible); otherwise, I would simply link Tf_Ignore to
Ignore. Since the Ignore group in most of the distributed colorschemes
I've checked really does hide text, a relatively small group of users
would need to define Tf_Ignore, and for those who need to but don't,
perhaps there's not much harm, since users of those colorschemes
apparently are not overly averse to viewing markup characters anyway.
>
>> Unfortunately, I'm beginning to suspect that there's not an easy
>> way to determine the default background color from within a Vim
>> script.
>
> I doubt there's any way to do it portably - many terminal emulators
> won't let you query that, and you can't count on $TERM being set
> properly because so many things lie and pretend to be an xterm...
> If it is possible, it would require per-terminal hacks, I think.
>
>> Even if the default background color could be determined, it would
>> need to be converted to the nearest color on the color cube, which
>> would depend upon number of colors (which could be presumably be
>> determined from &t_Co),
>
> If &t_Co <= 16, it's basically impossible - as above, you can't
> really query what those colors are set to, and users have a tendency
> to customize them to their tastes. If &t_Co is 88 or 256, you'd
> just wind up reimplementing the logic of (or stealing the code of)
> CSApprox.vim. /me makes a mental note to add a BSD license header
> to that script...
>
>> and perhaps something else...
>
> The terminal emulator itself. Konsole uses a different color
> palette than xterm for it's cube. Eterm uses one that's different
> from both xterm and Konsole. AFAIK, though, every other 256-color
> terminal uses the xterm palette. urxvt (without the 256-color
> patch) and very old xterms support 88 colors instead of 256, but my
> research has led me to believe that all 88-color terminal emulators
> use the same palette. Previews of the 3 different 256-color
> palettes can be found here, for the curious:
>
> http://www.cs.drexel.edu/~mjw452/256.html
Thanks Matt. This is all very good information. I'll email offline if I
have any more questions after digesting the material in the links...
Thanks,
Brett Stahlman
>
> ~Matt
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
