Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 438076 - >=app-portage/eix-0.27.2 - Unfortunate color maps are used in the unstable versions of eix.
Summary: >=app-portage/eix-0.27.2 - Unfortunate color maps are used in the unstable ve...
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Martin Väth
URL:
Whiteboard:
Keywords:
: 446040 446108 446176 483976 486994 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-10-12 07:01 UTC by Helmut Jarausch
Modified: 2013-12-30 23:05 UTC (History)
21 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
screen shot showing eix colors (eix-screenshot.png,25.04 KB, image/png)
2012-10-12 07:01 UTC, Helmut Jarausch
Details
eix-0.27.4 in urxvt (eix-urxvt.png,218.24 KB, image/png)
2012-11-25 09:12 UTC, Marek Sapota
Details
x11-terms/terminal screenshot eix outupt (terminal.png,876.26 KB, image/png)
2012-11-26 22:46 UTC, Neil
Details
Snapshot showing darker grey on black from bug 446108 (snapshot2.png,202.31 KB, image/png)
2012-12-05 17:17 UTC, Tom Wijsman (TomWij) (RETIRED)
Details
eix 0.29.3 on gnome-terminal default theme (eix.png,36.41 KB, image/png)
2013-12-28 19:00 UTC, pingoo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Helmut Jarausch 2012-10-12 07:01:29 UTC
Created attachment 326360 [details]
screen shot showing eix colors

As of version 0.27.2 of eix it uses a color map which is hard readable (here, at least).
Please have a look at the attach screen shot.

Thanks,
Helmut.
Comment 1 Martin Väth 2012-10-12 17:14:38 UTC
It is not possible to make a colormap which is readable on white and black
background. The 256 color map is "designed" for black background.
You can switch to the previous 8 color map with COLORSCHEME_ALT=0,
but IMHO this was not much better readable either on white background.

In >=eix-0.27.3 the background color of letters can be "forced",
and there will be also color schemes (8 and 256) for a white background.
(However, it is not possible to choose _automatically_ the "correct"
palette since there is no compatible way to determine you terminal's
background color; you have to set COLORSCHEME and/or COLORSCHEME_ALT
appropriately).

You might want to have a look at this forum thread:

https://forums.gentoo.org/viewtopic-t-939308-highlight-.html

Suggestions for improvements of the color scheme are welcome,
but I doubt that it is possible to create a reasonable scheme
which is well readable on all background colors.
Comment 2 Helmut Jarausch 2012-10-16 07:52:14 UTC
I'd like to suggest to release an eix-0.27.3-rc1 ASAP.
This version uses a black background which is readable on a system with light backgrounds, while the 0.27.2 is version is hardly usable.

Thanks,
Helmut.
Comment 3 Marek Sapota 2012-11-25 09:12:49 UTC
Created attachment 330524 [details]
eix-0.27.4 in urxvt

eix-0.27.4 looks terrible in urxvt, I tried it in xterm and it is much more colorful - in urxvt I mostly get gray and some dark, hard to read purple.  I tried setting COLORSCHEME, but it doesn't seem to have an effect.
Comment 4 Vasilis Lourdas 2012-11-25 12:40:27 UTC
(In reply to comment #3)
> Created attachment 330524 [details]
> eix-0.27.4 in urxvt
> 
> eix-0.27.4 looks terrible in urxvt, I tried it in xterm and it is much more
> colorful - in urxvt I mostly get gray and some dark, hard to read purple.  I
> tried setting COLORSCHEME, but it doesn't seem to have an effect.

Exactly the same issue here with urxvt.
Comment 5 Martin Väth 2012-11-25 15:11:49 UTC
(In reply to comment #3)
> eix-0.27.4 looks terrible in urxvt

The problem is that urxvt supports only 88 colors by default
(see e.g. eix --256 and, afterwards, also eix --ansi --256)

The easiest solution is to emerge rxvt-unicode with USE=256-color.

> tried setting COLORSCHEME, but it doesn't seem to have an effect.

TERM_ALT contains rxvt, i.e. you must set COLORSCHEME_ALT instead.
However, these variables will be renamed in >=eix-0.27.5 to
TERM_ALT{1..3} and COLORSCHEME{0...3} so that more choices will be possible.
Also in the defaults TERM=rxvt-unicode (without -256color) will be treated specially.

For the moment you can use as a workaround with similar effect:

TERM_ALT='256 [aeEkx]term rxvt$ rxvt-[^u] konsole gnome putty'
Comment 6 Vasilis Lourdas 2012-11-25 15:30:43 UTC
(In reply to comment #5)
> The problem is that urxvt supports only 88 colors by default
> (see e.g. eix --256 and, afterwards, also eix --ansi --256)
> 
> The easiest solution is to emerge rxvt-unicode with USE=256-color.

Yes, this fixes things with rxvt-unicode. Thanks.
Comment 7 Marek Sapota 2012-11-25 21:27:20 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > The easiest solution is to emerge rxvt-unicode with USE=256-color.
> 
> Yes, this fixes things with rxvt-unicode. Thanks.

Same for me, thanks!
Comment 8 Markos Chandras (RETIRED) gentoo-dev 2012-11-26 12:33:24 UTC
It's not clear to me whether this is an rxvt-unicode issue or an eix one. Does kde konsole produce the same output?
Comment 9 Markos Chandras (RETIRED) gentoo-dev 2012-11-26 12:34:31 UTC
(In reply to comment #8)
> It's not clear to me whether this is an rxvt-unicode issue or an eix one.
> Does kde konsole produce the same output?

hmm sorry ignore me. I failed to read all comments
Comment 10 Neil 2012-11-26 22:43:06 UTC
I have some strange behaviour with eix-0.27.4 under x11-terms/terminal-0.4.8.

I use transparet terminal and after running eix the background for the output and the next line are solid black, the transparency hasn't been used.  Attached a screen shot (I've blacked over my name at the prompts and terminal title).

Didn't have this happening under eix-0.27.2.
Comment 11 Neil 2012-11-26 22:46:27 UTC
Created attachment 330692 [details]
x11-terms/terminal screenshot eix outupt

Comments above.
Comment 12 Martin Väth 2012-11-27 15:57:55 UTC
(In reply to comment #10)
> the background [...] solid black

This is intentional, please read the documentation.
To avoid it set e.g. BG1=none (for the 256 dark colorscheme).
Comment 13 Neil 2012-11-28 07:02:58 UTC
Ah, ok I hadn't realised the default behavior has changed.

Now read the ChangeLog, doesn't explicitly state the default has changed, just that its possible to control the background.

Thanks for the pointer, config file duly modified.
Comment 14 Neil 2012-11-28 07:05:39 UTC
I really shouldn't try commenting when I've only just woken up, it does state the default has changed, my apologies.
Comment 15 Justin Lecher gentoo-dev 2012-11-28 18:52:09 UTC
For me it happens in urxvt, xterm and gnome-terminal with different types of badness in the coloring.
Comment 16 Ulrich Müller gentoo-dev 2012-11-28 23:06:16 UTC
(In reply to comment #12)
> > the background [...] solid black
> 
> This is intentional, please read the documentation.

But it's rather peculiar behaviour.

> To avoid it set e.g. BG1=none (for the 256 dark colorscheme).

All these things are certainly fine, if they can can be enabled via an option or in a config file.

But please, can we have a reasonable default? One that is readable on all terminals, and that leaves the background colour alone?
Comment 17 Martin Väth 2012-11-29 09:58:52 UTC
(In reply to comment #16)
> One that is readable on all
> terminals, and that leaves the background colour alone?

Unfortunately, these are contradictory requirements:

There is no color scheme which works on all backgrounds, and there is no
way to detect the background color. So either the background has to be
forced or you cannot read it on all terminals or you can use only 6 colors
or so - even then implicitly excluding certain backgrounds.

Since eix encodes much information into colors, the latter would be a
very poor default, making eix much less convenient in the majority of cases
(even before eix supported 256 colors, there were readability problems
on white backgrounds e.g. with yellow; gray was even invisible on urxvt
with black background, i.e. one would have to restrict the number of
previous colors even more.)

The way I decided prefers readability on all terminals - IMHO this is what
should be guaranteed by the defaults if possible (if this is still not the
case on some terminals, please report this so that this can be fixed).
If you want to have additional features like keeping your background if it is
not black, you need to configure it. I see no other way.

Perhaps we could make a USE-flag "white" for white background or "keep" for
keep background to change the defaults, but I am not sure whether it is
really a good idea to "lift" simple configure variables to USE-flags -
eix has already more than enough USE-flags anyway.
Comment 18 Ulrich Müller gentoo-dev 2012-11-29 11:15:12 UTC
(In reply to comment #17)
> There is no color scheme which works on all backgrounds, and there is no
> way to detect the background color. [...]

You could use some heuristics to determine the default. It's good enough for both Emacs and Vim:
<http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/104918/lisp/frame.el#L885>
<http://code.google.com/p/vim/source/browse/src/option.c?name=v7-3-743#3723>

Of course, it needs an option in addition, so that the user can override the default.

> Perhaps we could make a USE-flag "white" for white background or "keep" for
> keep background to change the defaults, but I am not sure whether it is
> really a good idea to "lift" simple configure variables to USE-flags -

Please don't. I'm certain that there are users who use eix on both light and dark background terminals on the same system. This is something to be configured at run time, not at build time.
Comment 19 Martin Väth 2012-11-29 23:41:09 UTC
(In reply to comment #18)
> 
> You could use some heuristics to determine the default.

I implemented the vim solution in the eix git master on BerliOS.

Unfortunately, this means that e.g. on transparent or black xterm/gnome/kterm
the colorscheme for white background is used which is of course completely
the wrong choice.

This will certainly lead to a lot of complains.
I am not sure whether I can keep this.

Please test the git version (e.g. from the mv overlay) and report if you
have ideas for improvements.
Comment 20 Ulrich Müller gentoo-dev 2012-11-30 16:00:56 UTC
(In reply to comment #19)
> I implemented the vim solution in the eix git master on BerliOS.
> 
> Unfortunately, this means that e.g. on transparent or black xterm/gnome/kterm
> the colorscheme for white background is used which is of course completely
> the wrong choice.

Sure, it's called "heuristic" because its results aren't always right. ;-) It is still a win if it's now right in more cases than it was before.

> Please test the git version (e.g. from the mv overlay) and report if you
> have ideas for improvements.

Works nicely here. Tested in xterm and Linux console.
Comment 21 Markos Chandras (RETIRED) gentoo-dev 2012-12-05 09:43:12 UTC
*** Bug 446040 has been marked as a duplicate of this bug. ***
Comment 22 Markos Chandras (RETIRED) gentoo-dev 2012-12-05 15:20:51 UTC
*** Bug 446108 has been marked as a duplicate of this bug. ***
Comment 23 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2012-12-05 17:17:17 UTC
Created attachment 331554 [details]
Snapshot showing darker grey on black from bug 446108
Comment 24 Martin Väth 2012-12-05 18:53:14 UTC
(In reply to comment #23)
> Snapshot showing darker grey on black from bug 446108

You see the colorscheme for white background.

The heuristic determining the background color is that from vim
and is horribly poor: Essentially, it is assumed that TERM determines
the background color (which means that most X Terminals are assumed
to have a white background).
Suggestions how to improve it are welcome.
(I certainly do not want to include X libraries into eix just to
get an improved heuristics).

As explained in a prominent place in the ChangeLog you have to set e.g.
DARK=true
(or to adapt the regular expressions in TERM_DARK to your settings).
Comment 25 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2012-12-05 19:15:47 UTC
(In reply to comment #24)
> (In reply to comment #23)
> > Snapshot showing darker grey on black from bug 446108
> 
> You see the colorscheme for white background.
> 
> The heuristic determining the background color is that from vim
> and is horribly poor: Essentially, it is assumed that TERM determines
> the background color (which means that most X Terminals are assumed
> to have a white background).
> Suggestions how to improve it are welcome.
> (I certainly do not want to include X libraries into eix just to
> get an improved heuristics).
> 
> As explained in a prominent place in the ChangeLog you have to set e.g.
> DARK=true
> (or to adapt the regular expressions in TERM_DARK to your settings).

https://438076.bugs.gentoo.org/attachment.cgi?id=326360
https://438076.bugs.gentoo.org/attachment.cgi?id=331554

This first one is dark on dark, the second one is light on light.

I would think inverting the color detection would solve these...

But that would only work out well if everyone has the problem; I haven't been following this bug though, who is experiencing this bug? Everyone or just some people? It might be interesting to set up a table containing information which eix versions, which terminals, etc... affect this.

And yes, mimicing the black/white detection algorithm of a program that works well could be an option; although I don't directly know of a console program that uses as much colors as eix out-of-the-box.
Comment 26 Alexandre 2012-12-05 19:45:31 UTC
On the attachment 331554 [details] I was using yakuake with default setting:

TERM=xterm

Now I changed that to:

TERM=xterm-256color

And it is working fine.
Comment 27 Martin Väth 2012-12-05 19:49:35 UTC
(In reply to comment #25)
> I would think inverting the color detection would solve these...

The "color detection" is much more primitive than you seem to think:

Essentially, TERM is matched against the regular expressions in
TERM_DARK (which defaults to "linux cygwin putty").
If it does not match white background is assumed:
Most terminals under X default to white background.

Only exception is if COLORFGBG is set (but this only works for rxvt).

> And yes, mimicing the black/white detection algorithm of a program that
> works well could be an option

The above is exactly the algorithm used by vim.
The algorithm used by emacs would require using X libraries which I do
not consider a reasonable option.
Comment 28 Martin Väth 2012-12-05 19:56:51 UTC
(In reply to comment #26)
> 
> TERM=xterm
> TERM=xterm-256color

This is strange: If you didn't change the defaults and changed nothing
else, this should not make any difference: Both should match TERM_ALT1
(and neither TERM_ALT2 nor TERM_ALT3) and should not match TERM_DARK.
And these are all places concerning colors where eix uses your TERM variable.
Comment 29 Alexandre 2012-12-05 20:07:45 UTC
(In reply to comment #28)
> (In reply to comment #26)
> > 
> > TERM=xterm
> > TERM=xterm-256color
> 
> This is strange: If you didn't change the defaults and changed nothing
> else, this should not make any difference: Both should match TERM_ALT1
> (and neither TERM_ALT2 nor TERM_ALT3) and should not match TERM_DARK.
> And these are all places concerning colors where eix uses your TERM variable.

Initially I was used 'DARK=true' on (a created) ~/eixrc, and it's worked as expected. After changed to 'TERM=xterm-256color' I deleted the ~/eixrc, restarted Yakuake (work OK) and then reboot to not to be any doubt.
Comment 30 Alexandre 2012-12-05 20:47:57 UTC
(In reply to comment #28)
> (In reply to comment #26)
> > 
> > TERM=xterm
> > TERM=xterm-256color
> 
> This is strange: If you didn't change the defaults and changed nothing
> else, this should not make any difference: Both should match TERM_ALT1
> (and neither TERM_ALT2 nor TERM_ALT3) and should not match TERM_DARK.
> And these are all places concerning colors where eix uses your TERM variable.

Sorry, I need to make a update:

Using 'TERM=xterm-256color' on my user yakuake settings and running eix(-diff) as user it's works nice, but as root not. When I changed on root yakuake settings to 'TERM=xterm-256color', eix works nice as root too.

*same happens on Konsole
Comment 31 Martin Väth 2012-12-05 21:24:30 UTC
(In reply to comment #30)and running
> eix(-diff) as user it's works nice, but as root not.

You probably have different files ~/.eixrc as root and user...

If you really think that there is a problem with eix parsing config-files
or behaving differently for different users when it should not,
please open a new bug:
There are enough comments here concering colors alone...
Comment 32 Martin Väth 2012-12-07 14:55:07 UTC
*** Bug 446176 has been marked as a duplicate of this bug. ***
Comment 33 Martin Väth 2012-12-07 19:15:38 UTC
As already expected, the poor heuristics causes only complaints.

I intend to release a new version of eix soon in which the heuristics
can be slightly more tweaked by the user, the default having a
*very* strong tendency to the previous DARK=true
(in contrast, the previous heuristics resulted mainly in DARK=false under X;
probably nobody knows what is "more correct", but the DARK=true schemes
are more known to users of previous eix versions)

Please test from git master and report if you have suggestions.
Comment 34 Ulrich Müller gentoo-dev 2012-12-07 19:27:33 UTC
(In reply to comment #33)
> Please test from git master and report if you have suggestions.

In the default configuration the output is now unreadable in xterm. Haven't we been there before? ;-)
Comment 35 Ian Stakenvicius gentoo-dev 2012-12-07 19:29:31 UTC
but which xterm ??  there's tons of folks that run xterm with reversed colors (black background).
Comment 36 Ulrich Müller gentoo-dev 2012-12-07 19:33:32 UTC
(In reply to comment #35)
> but which xterm ??

As I said, in its default configuration. Which has a white background.
Comment 37 Ian Stakenvicius gentoo-dev 2012-12-07 19:41:31 UTC
(In reply to comment #36)
> (In reply to comment #35)
> > but which xterm ??
> 
> As I said, in its default configuration. Which has a white background.

Ah; sorry.  Thought your 'default configuration' statement only implied to the config of eix
Comment 38 Martin Väth 2012-12-07 21:12:02 UTC
(In reply to comment #34)
> In the default configuration the output is now unreadable in xterm. Haven't
> we been there before? ;-)

It was you who strongly argued to exchange the previous default which was
always readable (but only ugly in some situations like transparent terms)
by a heuristic for which it was clear from the very beginning
that it cannot produce readable results in some cases:

> Sure, it's called "heuristic" because its results aren't always right. ;-)
> It is still a win if it's now right in more cases than it was before.
Comment 39 Ulrich Müller gentoo-dev 2012-12-07 21:36:14 UTC
Still, the goal should be a good default in as many cases as possible. For this, Vim's approach - proven for many years - would have just been fine (as would Emacs'). No need to reinvent the wheel.
Comment 40 Martin Väth 2012-12-07 22:28:08 UTC
(In reply to comment #39)
> Vim's approach - proven for many years - would have just been fine

Have you seen all the bug reports (several more on BerliOS, not counting
emails) of people who get now an unreadable default output?
There were never so many complaints about any change in eix.
(This is why I want to release next version so soon).

After thinking about it, I probably shouldn't have listened to you from
the very beginning and should have kept the policy that readability
in *all* situations is more important than avoiding a "peculiar behaviour".

So I think I will revert to forcing the background color to black/white
in colorscheme 1/3 (but keep the new heuristics).

This has the following effect:
If the heuristic succeeds completely (and the terminal is not transparent)
this will make no change. If the heuristic fails this still produces at
least a readable output.

Compared to this, the disadvantages appear mild: Users of fancy things like
transparent terminals will need to set BG1=none and/or BG3=none if they want
to keep the transparency. However, this is more a cosmetical issue compared
to non-readability for other users.

> Vim's approach - proven for many years

Maybe the age is the main problem with vim's approach: It seems that nowadays
there are several terminals on X with black background (for many choices
of themes) while vim's approach *always* gives a white background on X
(except for the few terminals which set COLORFGBG).
I also realized that vim's heuristic fails for konsole with white
background although konsole does set COLORFGBG and thus can be
correctly handled by the heuristics, i.e. it seems that the state
of vim's heuristic was never updated.
Comment 41 Ulrich Müller gentoo-dev 2012-12-07 23:54:57 UTC
(In reply to comment #40)
> After thinking about it, I probably shouldn't have listened to you from
> the very beginning [...]

Yeah, sorry that I was trying to help.
Comment 42 Martin Väth 2012-12-08 15:44:31 UTC
(In reply to comment #41)
>
> Yeah, sorry that I was trying to help.

Sorry, I didn't mean to attack you. I meant that I should not have
followed this suggestion, because I already felt that it would lead
to a lot of protests. However, I was now really overwhelmed by their
number...
Comment 43 Nikolaj Šujskij 2012-12-08 16:15:37 UTC
Martin, Ulrich probably won't read this, since he had deCCed himself.

(Oh boy, what a drama)
Comment 44 Markos Chandras (RETIRED) gentoo-dev 2012-12-08 17:13:04 UTC
I still fail to understand why this change had to be made. eix was working fine for years and nobody complained about the colors before. I am not expert in this area, but I guess it would be possible to revert all these changes and restore the old behavior?
Comment 45 Martin Väth 2012-12-08 19:15:27 UTC
(In reply to comment #44)
> I still fail to understand why this change had to be made.

eix used to output more and more data since years (e.g. last version
just added mask-reason data); for clarity, it is preferrable if you
can distinguish the type of data immediately by colors -
and the few system colors (6,8,12, or 16 - one can discuss about
their number since several are not usable for some reason or another or
are not distinguished on some terminals) are very poor for this task.

If you have ever worked with a well-configured "ls" command
(making full use of the 256 colors to distinguish a lot of file types)
and similar things you will know what I mean.
I hope to make eix similarly convenient.

If you want to revert to the previous colors, you can still configure
eix to use always the colorscheme 0.

However, I do not want to make this IMHO extremely poor setting the default -
otherwise practically nobody would/could use the possibilities which
fortunately exist nowadays on practically all terminals.
(And even then there was always the problem that e.g. the yellow color
is practically unreadable on white terminals, i.e. a poor default would not
even solve the problems).
Comment 46 Ulrich Müller gentoo-dev 2012-12-08 20:30:10 UTC
(In reply to comment #42)
> Sorry, I didn't mean to attack you. I meant that I should not have
> followed this suggestion, because I already felt that it would lead
> to a lot of protests. However, I was now really overwhelmed by their
> number...

Thanks for your notice by e-mail, I accept the apology. And reading my previous comments again, I see that they might have come across somewhat snotty, which was unintended. Sorry for that.
Comment 47 Thomas Capricelli 2012-12-10 15:59:57 UTC
Using konsole with black background (the default i guess), i cannot read/see the output anymore since updating eix :(

I'm pretty sure konsole supports top-notch-modern stuff with max numbers of colors possible and such. AND that this is a very common setup.
Comment 48 Martin Väth 2012-12-10 16:34:30 UTC
(In reply to comment #47)
> Using konsole with black background (the default i guess)

Since konsole exports COLORFGBG, the background should be recognized correctly
(unless this variable is removed in your startup files).
I just tested konsole again with eix-0.26.0 and it has no problems here.

> cannot read/see the output anymore since updating eix

If there is no readable output at all, there is a different problem.
Comment 49 Thomas Capricelli 2012-12-10 19:15:05 UTC
Er.. now i'm confused. At the time of writing , this bug is about " >=app-portage/eix-0.27.2". Of course eix-0.26 displays right. i would have filled another bug would there be a problem.

I dont think i've messed with COLORFGBG (never heard about it actually).

I didn't say "no output at all". It's all grey/black, and some words wont show (i guess they are displayed black on black?)
Comment 50 Roc Vallès 2013-06-06 21:45:38 UTC
Is this still a bug?

Perhaps it's time to close it.
Comment 51 Martin Väth 2013-06-07 07:37:55 UTC
(In reply to Roc Vallès from comment #50)
> Is this still a bug?

Some users might consider it so, since there appears no solution which makes
everybody happy. You are right, it is perhaps time to close it as CANTFIX.
Comment 52 Martin Väth 2013-09-06 14:48:41 UTC
*** Bug 483976 has been marked as a duplicate of this bug. ***
Comment 53 Joe Breuer 2013-09-06 16:54:16 UTC
*** Bug 483976 has been marked as a duplicate of this bug. ***
Comment 54 Martin Väth 2013-10-05 12:57:56 UTC
*** Bug 486994 has been marked as a duplicate of this bug. ***
Comment 55 pingoo 2013-12-28 19:00:21 UTC
Created attachment 366382 [details]
eix 0.29.3 on gnome-terminal default theme

Is really not possible to resolve this bug, maybe discarding some change in the code? Why is just eix that suffer of this problem?
Or add some info after compiling for solve it (actually I have not understood what to do...)
Comment 56 pingoo 2013-12-28 19:15:46 UTC
Ok, sorry, I found the solution at the end of the forum discussion:
SOLARIZED=true
(but maybe a message after compile ... ;) )
Comment 57 Joe Breuer 2013-12-30 16:38:33 UTC
Apart from

  SOLARIZED=true

(which gives "decent" color output for dark-on-light, but different from what people might be used to from older versions), a color scheme *almost* identical to the old 8/16 color one can be achieved with:

  TERM_ALT3=.
  COLORSCHEME3=0

This is detailed in bug #483976; I thought I'd repeat that here to give more folks a chance of finding that solution.
Comment 58 Martin Väth 2013-12-30 23:05:35 UTC
This is all summarized in the beginning of the Bugs/FAQ section on the manpage (including some more hints - depending what is disturbing you concerning colors - and a description when you should use SOLARIZED - of course, the latter is also described in the SOLARIZED environment variable on the manpage).
The ChangeLog contains a reference to that section even in capital letters, so if one is really interested in getting the previous poor 8 color scheme one can certainly find easily how to do it.