Red Hat Bugzilla – Bug 130664
PATCH: Enable 256 colour support in xterm
Last modified: 2007-11-30 17:10:47 EST
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
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
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
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.]
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
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.
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
(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
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