You (Matthias) say that there are usability problems with letting people
control the default colors.  May I make a suggestion?

There is a technically feasible solution.  Personally, I may not have the
kernel expertise to implement it, nor do I care enough to bother; I'm
using X nearly 100% of the time (and have configured xterm to suit my
preferences).  However, someone really wanting the ability to configure
default console colors might consider this:

If the kernel allowed an extra level of indirection for translating colors
(essentially a color-map (or CLUT, some prefer)), then one could reassign
the colors.  (Possibly even redefine the colors, though I don't know what
limitations the text-only video has in general.)  This indirection could
be omitted for those who don't want custom colors, and in any case should
in general only come into play when handling color-change codes.

This approach works out fairly well in practice.  (The old Amiga
console.device would map ANSI color-codes to screen colors 0..7, but did
NOT enforce those colors to be anything in particular.  I always ran with
a default background that was dim-/medium-grey, and a default foreground
of black.)  The only problem is that then programs that try to display
``red'' text is not guaranteed to actually get red text.  It is, however,
assured that if colors 0..7 are distinguishable, then ``red'' text will be
different-colored than any other color that you can select with the ANSI
sequences.

In virtually all cases, it is enough that the colors 0..7 are legible when
used in any combination of fore-/background for text.  Programs/scripts
are rare that actually depend upon colors being rendered exactly.
(Usually this centers around such things as user instructions: ``Red text
is used to ...''; even in these cases, sample ``red'' text is typically
shown so you can see immediately what color you will have to actually look
for.)

I suspect that simply _reordering_ the default colors would be a fairly
trivial tweak to our terminal emulation.  Allowing for arbitrary RGB
triples to completely remap the colors may be a little more involved (and,
for very old display hardware at least, may be impossible to actually
support).


Well, that's the suggestion.  Again, I don't care about this feature,
myself, so I wouldn't implement it.  But someone else might like the idea
and might want to give it a whirl.  (^&  I merely point out that I believe
it to be problem with an entirely feasible solution.

As long as the feature is implemented so that it doesn't contribute to
kernel bloat when the feature is disabled (which should be easy enough to
ensure), it seems to be a desirable option to include, if someone
volunteers the code.


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com