[Konsole-devel] [Bug 107487] Please add the xterm-256 colour support.

[lars.doelle at on-line.de]

Witek,

> Now konsole is incompatible with xterm-256 and IMHO should not set
> TERM=xterm
> I use ELinks in 256 colors mode on rxvt and xterm, and ELinks in 256 colors
> looks bad on konsole.
> IMHO konsole ouught to have seperate entry in terminfo.
> 
> What do you think?

The konsole has a terminfo entry. It could use a review, perhaps.
You can configure the TERM variable in the konsole's session profiles,
if you need to.

The central problem with using a separate entry for konsole is that it is
not honored by every application, in particular mc, which only offers some
vital features when the terminal is believed to be an xterm. It is not that bad
anymore, meanwhile it became ncurses-aware and apparently now offers a
secondary screen to non-xterms, too. It does not provide mouse input, though,
then, making the mc a "mouseless commander".

It would in fact nice to have the konsole separated from the xterm terminfo
entry, as time and again new escape codes show up in xterm and the related
terminfo, breaking the konsole with other programs, vim in particular.

As i said, coping well with mc is the main hurdle of such a step. It is not that
i want to blame mc. They have had quite some problems with broken termcap
and terminfo entries on other Unixes and hardcoded originally quite some
stuff. It became better though.

You can help by digging a bit into the issue, perhaps one can make mc
recognise the mouse introducing kmous=\E[M and likely entries. Again,
i believe making konsole export TERM=konsole by default is a very good
idea.


Witold, i was in contact with Thomas Dickey, the xterm maintainer, about
the strange escape sequences and the result is, that he simply did not had
ISO 8613-6 at hand, simply because it costs $$$. He was aware about the
issues, but expected no one to use the codes beside xterm.

Now since the standard appears to broken anyway, and has thus various
problems in itself, the codes introduced by Thomas are perhaps the best
we can get. You modification in the scanner are absolute fine with me and
in conformance with the xterm handling.

But the newly introduced colour space does not fit well with the konsole,
it is default colours and intense colours, that suffer. I have not yet found
time to work through this, but i believe, one probably needs to change the
class ca, and extend the fore- and background colors to UINT16 to cope
with issue, see TECommon.h

One would then have (2+256) BASE_COLORS and (INTENSITY*BASE_COLORS)
total TABLE_COLORS. This change would go through in most cases, i think,
but i'm not sure if in all. Would you try that?


-lars