Bug 112151
| Summary: | xterm does not display bold text due to color setting "white" in XTerm-color | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Andreas Luik <andreas.luik> |
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-01-15 08:06:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Every time we make changes to xterm resources that differ from what XFree86 ships, we end up fixing one user's bug and creating another bug for some other user, or upsetting another group of users who liked things fine the way they were. In some cases there is indeed a bug in the default resources and in other cases it is purely a question of preference. Rather than be to blame for causing xterm resource related problems for some users however, I have decided a year or two ago, that we will no longer modify xterm resources from what XFree86 ships, with 3 exceptions: 1) Changes which we were already applying prior to this decision remain present, since changing them would modify behaviour that many people already have come to expect. In some cases I have tried to revert some of our xterm resource changes that were made prior to my ownership of the XFree86 resources and have done so successfully with no complaints, and in other cases I've had complaints either externally, or internally at Red Hat, and so I've reverted and put our small modifications back. 2) Something that is an acknowledged bug by the upstream xterm maintainer Thomas Dickey, which he has already changed in his official xterm. That way we can make the same change, and be tracking the official sources for fixes. Anything Thomas does not see fit to include in his official xterm sources, I will not include in ours either, in order to be consistent with upstream as possible - aside from these 3 exceptions of course. 3) Something that fixes a _major_ bug which affects a seriously large portion of our userbase, and results in a large number of bug reports submitted by various users. The users will be redirected to Thomas Dickey to have the problem resolved in the upstream sources first if at all possible. If Thomas disagrees with the changes, and we feel that the bug is serious enough or affects a large enough group of users, then I may decide to make the change anyway. However, I have a very strong desire and tendancy to leave xterm as close to stock as is possible. gnome-terminal and konsole are our officially supported terminal applications, and xterm is provided as-is for end user convenience only, due to the number of users who rely on it for legacy or other reasons. I see no reason for us to make changes to xterm that the upstream maintainer disagrees with, which may upset the behaviour that other users expect, and which are not fixing major bugs, and aren't easily worked around via end user or system administrator configuration. This particular bug seems to be a trivial annoyance to a small subset of users rather than a major bug, and if it is fixed in Thomas' upstream's xterm (we do not ship xterm as part of XFree86 anymore, but rather separately), the fixes will trickle into the distribution when we update to XFree86 4.4.0 in the future. However, if the upstream maintainer is willing to apply the changes that are in XFree86 CVS head into the xf-4_3-branch of 4.3.0 stable CVS, I would consider that to be an upstream fix, and would have no problem updating our stable branch patch to pick up this change for future builds. You may want to contact him to request this be committed to the stable branch perhaps. If it does get committed there, feel free to reopen this report and I'll make the update. Closing WONTFIX |
From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; SunOS 5.8 sun4u) Description of problem: As recommended in the X Toolkit Manual, I'm using a X resource setting of #ifdef COLOR *customization: -color #endif Unfortunately, the XTerm-color application defaults file uses this brain-damaged color definitions: *VT100*colorUL: yellow *VT100*colorBD: white Since my xterm's background is the default white, I cannot read text written in bold (because it is white), and I can hardly read underlines text (printed in yellow). The color definitions in XTerm-color should be changed to be the same as in XTerm: *VT100*colorUL: green4 *VT100*colorBD: blue3 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. xrdb -merge - *customization: -color 2. xterm & 3. in xterm: man ls -> observe that underlined text is printed in yellow top -> observer that system information at the top is not visible Additional info: BTW: color resource definitions should not be in XTerm, but in XTerm-color anyways (as they are in the XFree86 CVS HEAD now).