Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Thu, Apr 08, 2004 at 08:50:07AM +0200, Branden Robinson wrote: I find this color, DodgerBlue1, much easer to read on a black-background xterm when using terminal fonts of very low weight. Here's an interesting discussion on the general topic: http://www.fseric.demon.co.uk/skills/colour.htm -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Thu, Apr 08, 2004 at 08:50:07AM +0200, Branden Robinson wrote: However, the appearance of the X cursor when inside an xterm window has not changed in my experience in the 6 years I've been maintaining this package for Debian. I don't suppose it changed for some time before that either - my guess is that the dynamic colors were added in fall 1995. I modified the initialization in patch #186 (current) so it will default to inheriting colors from the window's colors. Of course that's done only at initialization (unlike the text-cursor, whose color varies dynamically according to the ANSI colors). I also updated the manpage to fix the inconsistent terminology. But I didn't (yet) alter the selection for blue (am considering that still...) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpTrwxxHxVLm.pgp Description: PGP signature
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Mon, Apr 12, 2004 at 07:33:58PM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: On Thu, Apr 08, 2004 at 05:31:09PM +0200, Marc Lehmann wrote: framebuffer: #aa (standard vga actually, and real vt100 AFAICR) vt100's do not, never have done color. The ones with the advanced video option had. Call them vt102, or whatever you like, I do not care. A reasonable alternate choice (still improving contrast for blue/black) might for instance be blue2, which is a little brighter (0xee) than the value used by pterm. On the other hand, it might not display well with a blue/white combination on a low-quality display (I recall some issues about that). On low quality displays people will not use blue/white, as it is very straining for the eyes to have white backgrounds anyways. On Tue, Apr 13, 2004 at 10:15:51AM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: The vt100 colours look very similar everywhere, so programs had ample time to find combinations that work, as opposed to ones that do not work. but as long as you insist on referring to vt100 colours, I'm regarding the report only as an attempt to annoy people. Well, you can research this easily yourself. I don't care how you regard my report, as you can check everything I said for yourself, and I hope you did. Disregarding a perfectly fine bugreport just because I am not 100% precise in my naming conventions is rather idiotic, but it's you to chose. I am absolutely sure that you understood my points, and you understood all the problems I am talking about. The solution, or the way to proceed, is entirely up to your decision (or the debian X maintainers). If you are looking for reasons to disregard my report, there are easier ways than being a hipocrite :( On Tue, Apr 13, 2004 at 03:04:43PM -0500, Branden Robinson [EMAIL PROTECTED] wrote: problem, not the terminal emulator, which, after all, just offers a fairly standardized colour set. But it's not standardized. I would call that pretty much standardized. What you mean is probably that there is no real standard the mandates that with force. That is of course true. Neither the w3c nor the ietf nor... will care a bit which exact colour is used in xterm or elsewhere :) That's common practice, not standardization. It is common practise, and also standardization. Please do not think that only official standard bodies can create standards, that's not what the word standard means (see, for example, de-factor standards or industry standards which might or might not be standardized by a standards body like iso, but are beverteheles standards, as long as they are documented). I think that arguing about words (as this is the level both of you are approaching here) is not useful, and I have nothing more to day about this issue. I would be glad if you would discuss or decide according to the technical issues and problems I brought up. Arguing about words or word usage is secondary to the problem, and will neither help you nor me. With proper standardization comes expert advice. I don't think the xterm color defaults, or the defaults used by other terminal emulators, were selected with the aid of expert advice. True. And neither was expert advice sought when changing these. The problem is that a large body of software has inherent knowledge of these colours (by using them in certain combinations to get certain effects, e.g. use red for warnings). Obviously it would be bad to give some colour codes (former red) completey new colours. It's much less bad to change them subtly, and I think the xterm colour change is somewhere in the middle: It's not terribly problematic, but certainly a drawback for common existing applications, while improving the situation for some others. My point is that this is unexpected, and it's not a very intelligent idea to make colours incompatible in xterm compared to other terminals or terminal emulators by changing readable combinations. Existing terminals have lots of combinations that are marginally readable, not readable, or well readable. The xterm change does not improve the situation, it just changes it by making some combinations more readable and others less. And I argue precisely that this change is unexpected and not good, from a standardization side, as apps must be rewritten with knowledge about xterm colour combinations that are readable, as opposed to all other terminals. And if I haven't made this completely clear: I do not care about rgb bit values used for colours, I only care about readability, which, overall, seems to have been decreased rather than increased by xterms changes. They were picked because they were color values close to some ANSI terminal standard (I don't know which one) -- and which could be easily encoded in a 4-bit colormap. This is factually wrong. I think the colors in common practice were the product initially of technological constraints, and subsequently due to
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Tue, Apr 13, 2004 at 02:00:13AM +0200, Thomas Dickey wrote: A reasonable alternate choice (still improving contrast for blue/black) might for instance be blue2, which is a little brighter (0xee) than the value used by pterm. On the other hand, it might not display well with a blue/white combination on a low-quality display (I recall some issues about that). I note also: black text on blue2 background is unreadable. Dodger blue is readable. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgptNk6mSTcUp.pgp Description: PGP signature
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Tue, Apr 13, 2004 at 05:41:04AM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: On Tue, Apr 13, 2004 at 02:00:13AM +0200, Thomas Dickey wrote: A reasonable alternate choice (still improving contrast for blue/black) might for instance be blue2, which is a little brighter (0xee) than the value used by pterm. On the other hand, it might not display well with a blue/white combination on a low-quality display (I recall some issues about that). I note also: black text on blue2 background is unreadable. Dodger blue is readable. That is a very uncommon combination (I have not seen that used, and after all, xterm has high-intensity colours, so it would be asking for unreadable colours when you use two low-intensity colours together). You will always find colour combimations that are unreadable. The point of changing (or better: not canging colours) with respect to other terminals is not to introduce more or different combinations that are hard to read. The vt100 colours look very similar everywhere, so programs had ample time to find combinations that work, as opposed to ones that do not work. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
The vt100 colours look very similar everywhere, so programs had ample time to find combinations that work, as opposed to ones that do not work. but as long as you insist on referring to vt100 colours, I'm regarding the report only as an attempt to annoy people. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpZtHhhVVfiL.pgp Description: PGP signature
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Sat, Apr 10, 2004 at 02:28:34AM +0200, Marc A. Lehmann wrote: On Fri, Apr 09, 2004 at 05:58:00AM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: If an app uses it as fg and this is bad, then I think that app has a problem, not the terminal emulator, which, after all, just offers a fairly standardized colour set. But it's not standardized. Depends. It's standardized in some local standards, used in about all existing implementations (see the bug report for a comparison between terminal emulators on unix) and was documented for many years. I would call that pretty much standardized. What you mean is probably that there is no real standard the mandates that with force. That is of course true. Neither the w3c nor the ietf nor... will care a bit which exact colour is used in xterm or elsewhere :) That's common practice, not standardization. With proper standardization comes expert advice. I don't think the xterm color defaults, or the defaults used by other terminal emulators, were selected with the aid of expert advice. They were picked because they were color values close to some ANSI terminal standard (I don't know which one) -- and which could be easily encoded in a 4-bit colormap. I think the colors in common practice were the product initially of technological constraints, and subsequently due to laziness, inertia, and code reuse. That's not standardization. -- G. Branden Robinson| One doesn't have a sense of humor. Debian GNU/Linux | It has you. [EMAIL PROTECTED] | -- Larry Gelbart http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Thu, Apr 08, 2004 at 05:31:09PM +0200, Marc Lehmann wrote: On Thu, Apr 08, 2004 at 01:19:07AM -0500, Branden Robinson [EMAIL PROTECTED] wrote: However, the appearance of the X cursor when inside an xterm window has not changed in my experience in the 6 years I've been maintaining this package for Debian. Well, it's not really a major bug but a minor issue. I think it should be fixed, but it's obviously somethig if a correctness issue (how it was meant to be, or how other terminals handle it) not a usability thing. Huh. I can't remember anyone complaining about this before, and this change has been in place for *years*. (Is that an argument? For what? :) It sounds like an expression of surprise. But I do see occasional reports of longstanding bugs. However, in the discussion so far, it is not clear whether you are referring to the text cursor or the mouse pointer. Well, this colour (a reatively dark blue on vt100 and everywhere else) is often used as background colour because it's dark. and it's still more readable for most people. This is the 3rd comment in 6 months. One pointed out a contrast problem with cyan. Being a resource value, it is of course configurable. If you want a light blue as foreground, then you can always have a light blue as foreground, as xterm offers high intensity blue. ...which is still readily distinguishable from the default blue. The only app I know that uses the darker blue as fg is ls, however, there are a multitude of apps that use it as bg (very old ones as well as new ones, such as alsamixer). Most combinations become unreadable to colour-blind people (it seems, at least this is true to me, although I am not completely colour blind but have a colour weakness). I'm told that I am also, and that in fact people who have trouble distinguishing the older blue from black are also defective. So this change brings a small improvement for non-colour-blind and a vast problem for others. Perhaps the reverse of that comment is more correct. I still think that the majority of applications use blue as background for blue being perceived as darker as other colours. Actually, the only workable blue background schemes I've seen use white for text. The other colors all are harder to read than using black or white backgrounds. If an app uses it as fg and this is bad, then I think that app has a problem, not the terminal emulator, which, after all, just offers a fairly standardized colour set. But it's not standardized. It's not of any priority either... pointerColor (class PointerColor) ##XtDefaultForeground.## pointerColorBackground (class PointerColorBackground) ##XtDefaultBackground.## I wonder if it shouldn't default to the VT100 widget's text foreground and background colors instead. What do you think? I tend to agree. That is (I think) how rxvt does it and (definitely) how I could revisit this issue. When I first looked at it (probably 1997), xterm was using Xt to lookup resource values automatically. Now it delays some of those til they're needed (so it would be possible to detect cases where a resource value was not set, and modify its default value dynamically). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpab2DZCipyS.pgp Description: PGP signature
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Fri, Apr 09, 2004 at 05:58:00AM -0400, Thomas Dickey [EMAIL PROTECTED] wrote: of longstanding bugs. However, in the discussion so far, it is not clear whether you are referring to the text cursor or the mouse pointer. Yes. I was refering to the mouse-cursor. You have probably missed the remaining dialogue in the debian bug-report. The maintainer kept replies off-list, and so I did the same. The mails in the bug report detail the two problems quite thoroughly, so if you ae interested in theese arguments you might want to read them. If an app uses it as fg and this is bad, then I think that app has a problem, not the terminal emulator, which, after all, just offers a fairly standardized colour set. But it's not standardized. Depends. It's standardized in some local standards, used in about all existing implementations (see the bug report for a comparison between terminal emulators on unix) and was documented for many years. I would call that pretty much standardized. What you mean is probably that there is no real standard the mandates that with force. That is of course true. Neither the w3c nor the ietf nor... will care a bit which exact colour is used in xterm or elsewhere :) I wonder if it shouldn't default to the VT100 widget's text foreground and background colors instead. What do you think? I tend to agree. That is (I think) how rxvt does it and (definitely) how I could revisit this issue. When I first looked at it (probably 1997), xterm was using Xt to lookup resource values automatically. Now it delays some of those til they're needed (so it would be possible to detect cases where a resource value was not set, and modify its default value dynamically). Well, I would be fine with whoever changing the text fg/bg would also need to adjust the mouse cursor colours, too, to get standard behaviour. So the defaults in the binary and the debain appdefaults would need to be corrected. It's probably more user-friendly to make this automatically when unset, but I am mainly concerned about default settings. Changing the defaults is certainly the easiest fix for this very minor problem. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
tag 241717 - unreproducible thanks On Tue, Apr 06, 2004 at 04:10:52PM +0200, Marc Lehmann wrote: On Tue, Apr 06, 2004 at 02:21:11AM -0500, Branden Robinson [EMAIL PROTECTED] wrote: tag 241717 + unreproducible moreinfo Just BTW: there is no reason to tag this as unreproducible, as you haven't tried to reproduce it but dismissed it because you assumed the mouse cursor is wm-controlled. You might have tagged it as solved or notabug or something similar (wich would have been wrong, but at least consistent with your response :) thanks The xterm mouse cursor is a thin line, under debians xterm, it's much thicker. The *mouse* cursor is not controlled by xterm, but by another program, probably your window manager. This is wrong. If you don't believe me please ask somebody who knows more about X. The mouse cursor is application controllable and apps usually make ample use of that. xterm sets it to the insert cursor (or whatever is configured for xterm), sets the colours etc. and even has escape codes to control this appearance. Sorry, you're right, and I had a brainfart here. I apologize. However, the appearance of the X cursor when inside an xterm window has not changed in my experience in the 6 years I've been maintaining this package for Debian. To be precise, the Debian default is gray90 on black. You can see this in /etc/X11/app-defaults/XTerm-color. I was very imprecise with my use of black vs. white indeed, the point being more of dark-on-light bg vs. light on dark bg, or more precisely, using the same fg/bg colours for the mouse cursor as for the text. Nevertheless, the mousecursor is normally black-on-white (or black-on-gray90 if you like). Debian reverses the default colours for the text but leaves the mouse cursor colours black-on-white (or gray90) while correct colours are white-on-black (or gray90). Oh, I see what you mean. The way old X documentation talks about this is that the background of the X cursor is a mask, and the foreground is an inset image. The mask completely surrounds the cursor. Okay, so you're bothered by the fact that the mask is visible by default in Debian, but not on good old white-background xterms. Huh. I can't remember anyone complaining about this before, and this change has been in place for *years*. However, I use unclutter, so the large, prominent text-insertion-looking cursor never really gets in my way. You can see the correct behaviour and correct appearance by starting xterm without te debian colours (white bg), or another terminal emulator such as rxvt-xpm or Eterm or pterm or just about anything else (I haven't found any emulator that does it wrong with the exception of rxvt-unicode, which is an old version which has been corrected upstream). Yeah, I know what you're talking about now. Perhaps you could put a window dump of xterm up on the web somewhere so we could have a look at this? What you're describing doesn't sound like Debian's defaults at all. Here is an example: http://data.plan9.de/x.png The lower right terminal contains a much lighter blue (blue is often used as a background colour). The other terminals show more-or-less standard vt100 colours, the xterm shows a much more difficult-to-read combination (for me). The program used is alsamixer, but many other programs use this bg colour by default (mutt, irssi, epic4 I think etc..) xterm refers to it as color4, a resource of the VT100 widget. I find this color, DodgerBlue1, much easer to read on a black-background xterm when using terminal fonts of very low weight. Like the default fixed font, which is xterm's default. In fact, the upstream XTerm maintainer, Thomas Dickey, appears to have agreed with my reasoning (as have many users), and changed the upstream defaults to look like Debian's. * use color resource setting from Debian package for xterm VT100 widget, since the choice of blues provides better contrast. http://cvsweb.xfree86.org/cvsweb/xc/programs/xterm/XTerm-col.ad (See the commit message for revision 3.2.) I do agree that the contrast is better in the left window on your screenshot, however you're using a heavily-weighted, thick font. You might be able to win me over on the mouse cursor issue, but I'm not persuaded on this one. (Of course, if anyone reading this on debian-x would like to offer their opinions, please do.) I am not using xterm normally, and am using my own .Xdefaults for 10years+, which is why I didn't notice the problem so far. While working on rxvt-unicode I had a bug that kept the terminal from settting mouse colours, which I fixed (in version 2.7 btw). My own rxvt* config also defaults to white-on-black (gray80, actually ;), while both rxvt and rxvt-unicode default to black-on-white just like xterm. However, the mouse cursor in rxvt-unicode wasn't adjusted properly (that code was broken and commented out). After fixing this I tried xterm with
Processed: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Processing commands for [EMAIL PROTECTED]: tag 241717 - unreproducible Bug#241717: xterm: various colour problems (mouse cursor color, text colours) Tags were: moreinfo unreproducible Tags removed: unreproducible thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Thu, Apr 08, 2004 at 01:19:07AM -0500, Branden Robinson [EMAIL PROTECTED] wrote: However, the appearance of the X cursor when inside an xterm window has not changed in my experience in the 6 years I've been maintaining this package for Debian. Well, it's not really a major bug but a minor issue. I think it should be fixed, but it's obviously somethig if a correctness issue (how it was meant to be, or how other terminals handle it) not a usability thing. Huh. I can't remember anyone complaining about this before, and this change has been in place for *years*. (Is that an argument? For what? :) Fact is, it's incorrect, both from the standpoint of xterm (only some of fg/bg was reversed) as well as from the standpoint of other apps, terminals or not. They all use the same cursor, except xterm in default config. Wther there are masses of people complaining or not should certainly influence the priority that this bug gets. One might even argue that the new look is _better_ (I don't) and keep it, but it should receive some thought at one point in time. I find this color, DodgerBlue1, much easer to read on a black-background xterm when using terminal fonts of very low weight. Well, this colour (a reatively dark blue on vt100 and everywhere else) is often used as background colour because it's dark. If you want a light blue as foreground, then you can always have a light blue as foreground, as xterm offers high intensity blue. The only app I know that uses the darker blue as fg is ls, however, there are a multitude of apps that use it as bg (very old ones as well as new ones, such as alsamixer). Most combinations become unreadable to colour-blind people (it seems, at least this is true to me, although I am not completely colour blind but have a colour weakness). Like the default fixed font, which is xterm's default. Thinner fonts only make this problem worse for me, as the area decreases. In fact, the upstream XTerm maintainer, Thomas Dickey, appears to have agreed with my reasoning (as have many users), and changed the upstream defaults to look like Debian's. I do not think it is fair to take a majority to decide for visually impaired. After all, the majority of users doesn't suffer from this problem. In contrast, it is rather easy to read the default dark blue on black (for me), as opposed to almost anything on the new light blue. So this change brings a small improvement for non-colour-blind and a vast problem for others. I still think that the majority of applications use blue as background for blue being perceived as darker as other colours. If an app uses it as fg and this is bad, then I think that app has a problem, not the terminal emulator, which, after all, just offers a fairly standardized colour set. I do agree that the contrast is better in the left window on your screenshot, however you're using a heavily-weighted, thick font. Well, a thinner font makes it much worse for me. You might be able to win me over on the mouse cursor issue, but I'm not persuaded on this one. (Of course, if anyone reading this on debian-x would like to offer their opinions, please do.) I am not personally insulted if you fix neither of these problems. I stated my opinion, that it is a bug, but I am not terribly affected by it (most occasions where i have to use xterm I don't need colour, and when I need colour I am usually in front of one of my machines). It's not of any priority either... pointerColor (class PointerColor) ##XtDefaultForeground.## pointerColorBackground (class PointerColorBackground) ##XtDefaultBackground.## I wonder if it shouldn't default to the VT100 widget's text foreground and background colors instead. What do you think? I tend to agree. That is (I think) how rxvt does it and (definitely) how rxvt-unicode does it. I have no idea how other terminals like pterm, Eterm etc. do it. They are (on debian at least) gray-on-black, but the mouse cursor colours _are_ correct, wether their maintainers, their authors ir the binaries themselves do it, I am not sure. combinations are much harder to read to me (I have a very common form of red-green blindness). Hmm. This is the first I've heard of the changed colors being an accessibility impediment. Most people won't bother to report it, I'd guess, because for most people it is a non-issue (not having problems because they don't depend on the contrast) and for the rest it's a minor issue (it _is_ a minor issue: I can change colours, and people who can't can just use another terminal. As a matter of fact, xterm is probably not the most-used shell, as it is in a somewhat detrimental state and the (much worse) konsole and gnome-terminals come standard on most dekstops). Well, the Linux framebuffer console driver uses a shade of blue very similar to the one I made color4 use for the corresponding color, and *that's* a VT100 (technically VT220) emulator.
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
tag 241717 + unreproducible moreinfo thanks On Fri, Apr 02, 2004 at 05:25:41PM +0200, Marc Lehmann wrote: Package: xterm Version: 4.3.0-7 Severity: minor The xterm mouse cursor is a thin line, under debians xterm, it's much thicker. The *mouse* cursor is not controlled by xterm, but by another program, probably your window manager. Specifying -rv restores the original cursor (but does not do reverse video, see bug #239510, which is probably related). It seems that debians xterm does not set mouse cursor colours correctly and defaults to white background and black foreground, while the default config specifies black background on white foreground, which is probably why -rv fixes this as it correctly swaps background and foreground for all items. To be precise, the Debian default is gray90 on black. You can see this in /etc/X11/app-defaults/XTerm-color. Another colour problem: debian also changed default colours of xterm, which makes coloured text very hard to read, especially for colour-impaired people like me (it's very difficult for me to decipher e.g. the alsamixer labels in xterm, other shells work fine). The original xterm colours are much easier on my eyes, due to the much increased contrast. Perhaps you could put a window dump of xterm up on the web somewhere so we could have a look at this? What you're describing doesn't sound like Debian's defaults at all. It's also worth noting that Debian's default xterm configuration hasn't changed recently. Perhaps something else on your system is playing around with X resources? -- G. Branden Robinson|Damnit, we're all going to die; Debian GNU/Linux |let's die doing something *useful*! [EMAIL PROTECTED] |-- Hal Clement, on comments that http://people.debian.org/~branden/ | space exploration is dangerous signature.asc Description: Digital signature
Processed: Re: Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Processing commands for [EMAIL PROTECTED]: tag 241717 + unreproducible moreinfo Bug#241717: xterm: various colour problems (mouse cursor color, text colours) There were no tags set. Tags added: unreproducible, moreinfo thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
On Tue, Apr 06, 2004 at 02:21:11AM -0500, Branden Robinson [EMAIL PROTECTED] wrote: tag 241717 + unreproducible moreinfo Just BTW: there is no reason to tag this as unreproducible, as you haven't tried to reproduce it but dismissed it because you assumed the mouse cursor is wm-controlled. You might have tagged it as solved or notabug or something similar (wich would have been wrong, but at least consistent with your response :) thanks The xterm mouse cursor is a thin line, under debians xterm, it's much thicker. The *mouse* cursor is not controlled by xterm, but by another program, probably your window manager. This is wrong. If you don't believe me please ask somebody who knows more about X. The mouse cursor is application controllable and apps usually make ample use of that. xterm sets it to the insert cursor (or whatever is configured for xterm), sets the colours etc. and even has escape codes to control this appearance. It seems that debians xterm does not set mouse cursor colours correctly and defaults to white background and black foreground, while the default config specifies black background on white foreground, which is probably why -rv fixes this as it correctly swaps background and foreground for all items. To be precise, the Debian default is gray90 on black. You can see this in /etc/X11/app-defaults/XTerm-color. I was very imprecise with my use of black vs. white indeed, the point being more of dark-on-light bg vs. light on dark bg, or more precisely, using the same fg/bg colours for the mouse cursor as for the text. Nevertheless, the mousecursor is normally black-on-white (or black-on-gray90 if you like). Debian reverses the default colours for the text but leaves the mouse cursor colours black-on-white (or gray90) while correct colours are white-on-black (or gray90). You can see the correct behaviour and correct appearance by starting xterm without te debian colours (white bg), or another terminal emulator such as rxvt-xpm or Eterm or pterm or just about anything else (I haven't found any emulator that does it wrong with the exception of rxvt-unicode, which is an old version which has been corrected upstream). Perhaps you could put a window dump of xterm up on the web somewhere so we could have a look at this? What you're describing doesn't sound like Debian's defaults at all. Here is an example: http://data.plan9.de/x.png The lower right terminal contains a much lighter blue (blue is often used as a background colour). The other terminals show more-or-less standard vt100 colours, the xterm shows a much more difficult-to-read combination (for me). The program used is alsamixer, but many other programs use this bg colour by default (mutt, irssi, epic4 I think etc..) It's also worth noting that Debian's default xterm configuration hasn't changed recently. Perhaps something else on your system is playing around with X resources? I am not using xterm normally, and am using my own .Xdefaults for 10years+, which is why I didn't notice the problem so far. While working on rxvt-unicode I had a bug that kept the terminal from settting mouse colours, which I fixed (in version 2.7 btw). My own rxvt* config also defaults to white-on-black (gray80, actually ;), while both rxvt and rxvt-unicode default to black-on-white just like xterm. However, the mouse cursor in rxvt-unicode wasn't adjusted properly (that code was broken and commented out). After fixing this I tried xterm with the debian default config for the first time (thus the HOME=/tmp/empty to ensure my .Xdefaults aren't picked up (they are not loaded into the x-server, either)). I then noticed both the hard-to-read colours (which are from /etc/X11/app-defaults/XTerm-color) as well as the same bug regarding the mouse cursor (unlike rxvt-unicode, it's not neccessarily a code bug but a config bug, although it could be assumed that xterm should use the configured fg/bg colours for the mouse cursor by default, as rxvt-unicode does. xterm does not do this and needs manual configuration to match the configured colours. The default black-on-white config is consistent, while debian reversed only part of the colours and left others unchanged, resulting in a white background colou for the mousecursor and black for the text, creating an outline version of whatever cursor used). As for a visual description of how the cursor in most terminal looks like, it should (by default, this is usualy configurable, and no colour cursors used) be a thin vertical line with thick endpoints (as you can see in most terminals), the same is true with xterm in it's default configuration. In debian, the insert cursor becomes very heavyweight because what's actually displayed is the outline of this cursor. It does not resemble the originally intended apearance. I assume that this is a just an oversight or a omission on part of the debian maintainer, nothing more, and not intended behaviour. The changed colours, OTOH, are
Bug#241717: xterm: various colour problems (mouse cursor color, text colours)
Package: xterm Version: 4.3.0-7 Severity: minor The xterm mouse cursor is a thin line, under debians xterm, it's much thicker. Specifying -rv restores the original cursor (but does not do reverse video, see bug #239510, which is probably related). It seems that debians xterm does not set mouse cursor colours correctly and defaults to white background and black foreground, while the default config specifies black background on white foreground, which is probably why -rv fixes this as it correctly swaps background and foreground for all items. Another colour problem: debian also changed default colours of xterm, which makes coloured text very hard to read, especially for colour-impaired people like me (it's very difficult for me to decipher e.g. the alsamixer labels in xterm, other shells work fine). The original xterm colours are much easier on my eyes, due to the much increased contrast. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.4 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 Versions of packages xterm depends on: hi libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an hi libexpat1 1.95.6-4 XML parsing C library - runtime li ii libfontconfig1 2.2.1-8 generic font configuration library hi libfreetype62.1.5-2 FreeType 2 font engine, shared lib ii libice6 4.3.0-7 Inter-Client Exchange library ii libncurses5 5.4-2Shared libraries for terminal hand ii libsm6 4.3.0-7 X Window System Session Management ii libxaw7 4.3.0-7 X Athena widget set library ii libxext64.3.0-7 X Window System miscellaneous exte ii libxft2 2.1.2-6 FreeType-based font drawing librar ii libxmu6 4.3.0-7 X Window System miscellaneous util ii libxpm4 4.3.0-7 X pixmap library ii libxrender1 0.8.3-7 X Rendering Extension client libra ii libxt6 4.3.0-7 X Toolkit Intrinsics ii xlibs 4.3.0-7 X Window System client libraries m ii xlibs-data 4.3.0-7 X Window System client data -- no debconf information
