>>>>> "Brian" == Brian Mays <[EMAIL PROTECTED]> writes:
Brian> rxvt (and rxvt-xpm) always exports the variable "COLORTERM" Brian> so that programs can check for color support. >>>>> "John" == John Goerzen <[EMAIL PROTECTED]> writes: John> Unfortunately, I know of no programs that make use of this John> variable. In fact, I believe that ncurses doesn't even use John> it. The rxvt authors claim that programs such as JED, slrn, Midnight Commander check this variable. I don't know since I don't use any of these applications. Brian> As a side note, when XPM support has been compiled into Brian> rxvt (as with rxvt-xpm supplied in Debian's rxvt package), Brian> the value of COLORTERM is set to "rxvt-xpm" instead of Brian> "rxvt". John> Which could be a bug in itself since Debian has no rxvt-xmp John> terminfo entry. This is not a problem since ncurses uses the TERM variable and not the COLORTERM variable. John> I would suggest that rxvt set TERM to rxvt when on a color John> display and to xterm when on a non-color display. The rxvt John> entry in terminfo already has color support; the xterm entry John> is monochrome. Since rxvt is backwards-compatible with John> xterm, this would seem to be the proper method. It would John> cause the least fuss while ensuring proper behavior in all John> situations. John> Even if this isn't done, I suggest that the default be set John> to rxvt. After all, we have the terminfo entry for it, it John> doesn't make any sense not to use it. Observe the difference between the rxvt entry and the xterm-color entry: $ infocmp rxvt xterm-color comparing rxvt to xterm-color. comparing booleans. comparing numbers. comparing strings. kend: '\EOw', '\EOe'. khome: '\E[H', '\EO\200'. kmous: NULL, '\E[M'. Other than the home key, the end key, and X11 mouse support, there are no differences between the two entries. Therefore, unless we really care about these three features, using TERM=xterm-color is good enough. I think that we have two choices: 1) Strive to be totally correct: Convince the ncurses maintainer to provide two rxvt terminfo entries: one with color capabilities defined and one without color capability. The rxvt program will set the TERM variable to the appropriate entry according to the color depth of the X display. 2) Strive for compatibility: Not all Unices have an rxvt terminfo entry. The RS6000 and SGI machines on which I have accounts do not have an rxvt entry or an xterm-color entry. Thus when I rlogin onto these machines from an rxvt window, the terminal capabilities will default to those of a "dumb" terminal because TERM=rxvt and TERM=xterm-color are unknown terminal types to them. With this mind, rxvt will set the TERM variable to xterm or xterm-color depending on the color depth of the X display. This is the default behavior of rxvt provided by the upstream maintainers, so it should be consistent with rxvt version compiled on non-Debian Unices. Users who insist on using the rxvt terminfo entry can monitor the COLORTERM variable. For example, they can place the following in their .profile file: TERM=${COLORTERM:-$TERM} What I want to avoid is TERM=rxvt on color displays and TERM=xterm on mono displays. I can see this leading to bug reports when the HOME and END keys work on color displays but fail to behave the same way on mono displays. For consistency sake, these keys should either always work or always not work. John> I suspect that rxvt would behave properly in this case even John> if it is on a 1-bit (B&W) display. The problem is not whether rxvt does the right thing, we need to ensure that the programs running in an rxvt terminal do the right thing. This means that when rxvt's window is located on a monochrome display, the programs running on that window should know that they are on a terminal that does not have the capability to display colors. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .