On Wed, Jul 21, 2010 at 02:02:56PM -0700, Chip Camden wrote: >Quoth Chip Camden on Wednesday, 21 July 2010: >> I have 256 colors enabled for my urxvt, and all works well with mutt >> until I try to define more than 21 color specifications in .muttrc, the >> colors seem to get confused. Must be a table overflow or something. >> Should I engender a flea? Or is this already known? I tried searching >> the flea database without success. > >UPDATE: looks like the breaking point is over 16 colors -- I just didn't >notice that the ones beyond the 16th were borked.
FYI: You can always check your terminal and applications for >16 color support by using the 256colors2.pl color test script. (Google search for "256colors2.pl") For terminal, if you see more then 2 or 3 gradients of pink on the far right box & column, it's likely 256 color support is supported. As for apps, you just need to enable the specific color within the app to see if it works. The big problem I've seen so far, when a user toggles between a 16 color and 256 color application and/or terminal. Terminals *and* applications tend to totally screw-up colors when switching between 16 and 256 color. And, there's usually no fallback color theme for applications -- ie. A user switches to a 16 color terminal and tries to run an application configured for 256 color. I'm thinking, the last issue of having "no fallback" method is the big issue here. And, the lack of of a fallback method theme for Applications, is likely present within terminals too? I know for one, Linux virtual consoles (framebuffer) lack >16 color support -- supposedly a kernel terminal issue. Since I do a lot of work in virtual terminals, I don't use anything >16 colors. I know VI/VIM lacks a fallback method. -- Roger http://rogerx.freeshell.org/
