Bug 130664 - PATCH: Enable 256 colour support in xterm
PATCH: Enable 256 colour support in xterm
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
: FutureFeature, Patch
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-08-23 12:11 EDT by Martin Ebourne
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-16 12:52:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Provide --with 256_colour option for rpmbuild (951 bytes, patch)
2004-09-02 16:39 EDT, Martin Ebourne
no flags Details | Diff

  None (edit)
Description Martin Ebourne 2004-08-23 12:11:07 EDT
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.
Comment 1 Thomas E. Dickey 2004-08-27 20:36:56 EDT
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).
Comment 2 Martin Ebourne 2004-08-28 04:45:56 EDT
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.
Comment 3 Thomas E. Dickey 2004-08-28 06:46:06 EDT
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).
Comment 4 Martin Ebourne 2004-08-28 07:51:02 EDT
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.
Comment 5 Thomas E. Dickey 2004-08-28 11:41:55 EDT
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.
Comment 6 Mike A. Harris 2004-08-30 00:53:17 EDT
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.
Comment 7 dann 2004-09-02 13:43:36 EDT
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.
Comment 8 Thomas E. Dickey 2004-09-02 16:17:45 EDT
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
Comment 9 Thomas E. Dickey 2004-09-02 16:31:03 EDT
Clarification: "It's based on" refers to the
termcap 1.3.1 package.
Comment 10 Martin Ebourne 2004-09-02 16:39:04 EDT
Created attachment 103402 [details]
Provide --with 256_colour option for rpmbuild
Comment 11 Martin Ebourne 2004-09-02 16:54:05 EDT
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.]
Comment 12 dann 2004-09-25 19:42:41 EDT
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. 
Comment 13 Mike A. Harris 2004-12-23 13:00:11 EST
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
Comment 14 dann 2005-01-08 12:13:51 EST
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.
Comment 15 dann 2005-04-08 16:51:01 EDT
(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. 
Comment 16 Mike A. Harris 2005-04-16 12:52:21 EDT
Added to rawhide xterm-200-6

Comment 17 dann 2005-12-13 14:16:28 EST
(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??]
Comment 18 Martin Ebourne 2005-12-13 15:00:43 EST
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.
Comment 19 dann 2005-12-13 18:14:07 EST
(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


Note You need to log in before you can comment on or make changes to this bug.