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.
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.
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.
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.
(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.
(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'
(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.
(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!
It's not clear to me whether this is an rxvt-unicode issue or an eix one. Does kde konsole produce the same output?
(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
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.
Created attachment 330692 [details] x11-terms/terminal screenshot eix outupt Comments above.
(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).
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.
I really shouldn't try commenting when I've only just woken up, it does state the default has changed, my apologies.
For me it happens in urxvt, xterm and gnome-terminal with different types of badness in the coloring.
(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?
(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.
(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.
(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.
(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.
*** Bug 446040 has been marked as a duplicate of this bug. ***
*** Bug 446108 has been marked as a duplicate of this bug. ***
Created attachment 331554 [details] Snapshot showing darker grey on black from bug 446108
(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).
(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.
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.
(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.
(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.
(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.
(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
(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...
*** Bug 446176 has been marked as a duplicate of this bug. ***
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.
(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? ;-)
but which xterm ?? there's tons of folks that run xterm with reversed colors (black background).
(In reply to comment #35) > but which xterm ?? As I said, in its default configuration. Which has a white background.
(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
(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.
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.
(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.
(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.
(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...
Martin, Ulrich probably won't read this, since he had deCCed himself. (Oh boy, what a drama)
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?
(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).
(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.
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.
(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.
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?)
Is this still a bug? Perhaps it's time to close it.
(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.
*** Bug 483976 has been marked as a duplicate of this bug. ***
*** Bug 486994 has been marked as a duplicate of this bug. ***
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...)
Ok, sorry, I found the solution at the end of the forum discussion: SOLARIZED=true (but maybe a message after compile ... ;) )
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.
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.
