Description of problem: Please build Xterm using the --enable-256-color option Applications (including the upcoming version of Emacs) are able to make use of this and it is a significant improvement over the default 16 colours. The 256 colour support is in addition to the normal 16 colours and so nothing will break.
Actually, what can break is that the application can run out of colors - a problem with less capable video cards. (On the other hand, that sort of consideration may not apply to your users).
Are you saying that if it is compiled with 256 colour support then xterm will fail to start if it cannot get all of those colours? I had assumed it would just disable the 256 colour support in this case (or produce a best-effort mapping) and perhaps produce a warning. Presumably on an 8 bit display it would install a private colour map so are we talking about 4 bit or less displays here? If so another solution would be to make 256 colour a run-time option (by command line and x resource) rather than a compile time option. I guess if so that should be over at freedesktop.org bugzilla.
no - it will start. 8-bit displays don't have enough colors (because other applications generally start first). So a program such as emacs wouldn't be able to show all of the colors as requested - they'd come out as the default foreground and background colors. (On an 8-bit display, 88-colors seems like a reasonable compromise, but the difference between 88- and 256-colors is a compile-time option). In either case, the layout of memory used to store the color information is determined at compile-time (I suppose it would be doable to make that runtime-switchable, but unlike the wide characters, this would change the way bits are packed, rather than add extra bytes to an array).
So if I read you right then a 256 colour xterm would work perfectly well on an 8-bit display as long as you stuck to the basic 16 colours. It would only display incorrect colours in the case that a user tried to use 256. (Or does it not necessarily allocate the base 16 colours first? Could it?) If that is the case then I still think it is reasonable to compile with 256 colour support because people with such displays are unlikely to try to use the extra colours, and even if they do nothing really bad will happen.
yes, it should work properly. It'll use a little more memory since 2 bytes per cell are used to store color rather than one. It allocates colors in the order that someone uses them. Normally that means that the base colors would be allocated first.
There seems to be a number of potential user visible problems that could occur if this was enabled by default (as described in comments above). I assume that this is why the upstream xterm ships with it disabled by default. If someone is willing to write a patch to our xterm spec file to add a new rpm macro named "with_256_colors" which conditionally enables this option experimentally, but defaulting to off in the stock rpm build, I'd be glad to patch our spec file to allow users to rebuild the rpm with 256 color mode as an option, but leaving our default build to the stock xterm defaults. Please attach unified diff as a bugzilla file attachment and I'll add it to the next build. Thanks in advance.
Unfortunatelly I don't know how to write spec files, so I can't help with that... I hope someone else will be able to help with that. But I know of a problem that will show up once this is done: /etc/termcap as provided by termcap-11.0.1-18.1 does not have an entry for xterm-256color. tcsh uses termcap, so it will have problems. You can test this by doing: setenv TERM xterm-256color terminfo has an xterm-256color definition.
There's really no good reason for that. I added the entry in ncurses toward the end of 1999. Sometime after that I mentioned to the GNU termcap maintainer that he should upgrade, and he dithered about and did nothing. (It's based on ESR's text, which incorporated many of the changes I made during 1997-1999, but has been effectively defunct for more than four years). Running tic -Cr on ftp://invisible-island.net/ncurses/terminfo.src.gz would give a better version of termcap.src
Clarification: "It's based on" refers to the termcap 1.3.1 package.
Created attachment 103402 [details] Provide --with 256_colour option for rpmbuild
Patch included as requested by Mike. As I understand it the 'potential user visible problems' discussed above boil down to: If a user uses a low colour display (<=256) and they try to use 256 colours in xterm then when it runs out of colours the rest will be displayed as the default colour. It wouldn't affect anyone using the default 16 colours, nor anyone who didn't try to use most of the 256 colours since as Thomas said above, the colours are allocated on an as-needed basis. [Also it'll use a little more memory.] I would say that given the minor 'failure' and the fact that the user has to explicitly be using 256 colours to get it, then enabling 256 colour support by default is still reasonable. Maybe you could try it in rawhide and see what people say. The termcap problem is only seen if you explicitly set TERMCAP as described above. Still, that should probably be fixed separately. [PS. Option is --with 256_color despite what I wrote above.]
A caveat: The terminfo entry for xterm-256color needs to be synchronized with the one for xterm. On my FC2 system the kbs terminfo string is ^? for xterm, and ^H for xterm-256color.
Submit a patch for terminfo against the terminfo package, and once it is included in rawhide, update this report I will consider adding the patch from comment #10 to rawhide. TIA
The terminfo entries for xterm and xterm-256color are synchronized on my FC3 system (i.e. the ncurses-5.4-13 package), so comment #12 is not valid anymore.
(In reply to comment #13) > Submit a patch for terminfo against the terminfo package, and once > it is included in rawhide, update this report I will consider > adding the patch from comment #10 to rawhide. This is done now as shown in comment #14. Can you please consider adding the patch in comment #10 to rawhide? The main reason I am asking is that Emacs-22 will probably be released during the lifetime of FC4, and that Emacs version has very good support for 256 color terminals.
Added to rawhide xterm-200-6
(In reply to comment #16) > Added to rawhide xterm-200-6 Can the 256 color support be enabled by default in rawhide? The --with 256_color option only helps people that rebuild with their rpms, it would be great if the 256 color support would be enabled by default for all users. [I am not sure if anybody reads comments on closed bugs, should I open another bug for this??]
I guess open a new one is the right way to go. If you do, post a reference here. I think it would definitely be good to enable 256 colour by default, and I think this is the ideal time to try it. If it did cause any problems (and I doubt it will) it's easy to turn off again.
(In reply to comment #18) > I guess open a new one is the right way to go. If you do, post a reference here. Done, the bug number is: 175684