[Konsole-devel] [Bug 145977] New: Konsole has a terminfo entry of its own; please change default $TERM

[lars.doelle at on-line.de]

Alexander,

> ncurses has had terminfo entries for konsole
> since ncurses 5.3. These also got updated
> recently for ncurses 5.5.  
> 
> Thus you should be able to change your
> default $TERM from the incorrect 'xterm' to
> the correct 'konsole'.  

I absolutely agree with you, and doing so would be helpful to
desynchronize the konsole from the changes in xterm.

But this a sad though important topic since day one of the konsole.

It needs a bit longer reply, thanks for your patience.

Today, practically the only important program in the way of
such a step is "mc", but not it cannot really help, the real
reason is the terminfo/curses itself, which does not handle
xterm like terminals correctly.

Basically, "mc" becomes useless under X11 as soon as
it sees any terminal not being a TERM=xterm.

In a konsole, simply try:

$ TERM=konsole mc

It is by far not as bad as it was in earlier days, but you will
notice, that "mc" still does not react on the mouse (making
it a "mouseless commander") and has difficulties to follow
window resizes. To some degree, one (in particular me)
could perhaps live with this, perhaps not. 

Now it is not alone mc's fault. mc had, at the time i looked
at last its source, to take care of a lot of wrong terminfo/termcap
entries flying around on a variety of architectures. So the terminfo
was not a reliable basis for a decision - and still, it seems to be so:

The mouse and the secondary screen are extensions of
xterm, which have to be properly recognized somehow.
This could be done using the terminfo/termcap database,
if it were correct.


A) Primary and Secondary Screen

Mainly, these are the codes ESC[?47l and ESC[?47h.

Now, terminfo does not even have the concept of a terminal
having different screens, but this concept is _vital_ to any
decent fullscreen application, as vim or mc.

It is worked-around using "smcup" and "rmcup", a kind of
bracket sequence for applications needing "cup" (cursor
up). Since any Ansi terminal (e.g. a VT100) can do "cup"
whenever wanted, though not having a secondary screen,
this does not really express the feature of a second screen
and the switching to it.

Actually, this work-around is only in the konsole's terminfo
database entry (i'm using a post etch debian unstable, which
packages ncurses-5.6) . For the xterm entry, you will search
for the related escape code without result:

$ infocmp xterm | grep 47

newer xterm use a kind of variation of the code actually provided
with the xterm entry:

rmcup=\E[?1049l, smcup=\E[?1049h

This is an escape code combining several other escape codes into one...
For an explanation see the xterm escape code reference. This is file
"ctlseqs.ms", typeset using "groff -Tps ctlseqs.ms > ctlseqs.ps". Basically,
it does what ESC[?47 above does, i.e. screen switching.

To summarize, terminfo/termcap does not properly describes
terminals with multiple screens. The entries working around the
problem purports that the terminals would be unable to do a CUP
anytime. (Though this might be a very interesting idea!)


B) Mouse

Mainly, these are the codes:

ESC[?1000h - make terminal start sending mouse events
ESC[?1000l  - make terminal stop sending mouse events
ESC[Mbxy    - report of a mouse event (b=button, x=x, y=y)

Here, the state is a bit better with respect to curses, as terminfo
allows (among other) the following capabilities (citing terminfo (5))

getm  - Curses should get button events, parameter #1 not documented.
kmous - Mouse event has occurred.

First note that this is not enough. Any decent handling of the mouse
requires that mouse reporting is switched on and off. Try for example
the behavior of the mouse in mc and type ctrl-O to get to the full screen
shell and try it again. Get back to the panel using ctrl-O again and move
the mouse holding down the shift key. Make sense, doesn't it?

Now for actual terminfo entries:

kmous is both in the xterm as well as in the konsole entry - fine.
getm is not used in either.

Looking for any ESC[?1000 entries in konsole's and xterm's database
entry shows:

xterm: none

konsole:  rs2=...\E[?1000l...

Ok, mouse tracking deactivate during during reset...

Now please guess, where the application get the necessary escape
sequence to control the mouse from when running in an xterm ...



Alexander, i _absolutely_ support using curses (it is in my opinion for
terminal programs, what Xlib is for X11 programs), and i do _absolutely_
support using an own "konsole" terminfo entry for the konsole.


To summarize the state as i find it now:

1) The terminfo entries would have to be extended to _properly_ describe
     x-terminal capabilities, especially the mouse features, to describe the
     secondary screen feature more properly, would also help

2) programs (especially 'mc') would need to make use of these.

3) proper terminfo entries for x-terminals would need to get through the
   distribution pipeline.

The later is not so simple, kde is used under HPUX, AIX, ... etc, too, thus one
would have to distribute the konsole's terminfo/termcap entry together with
the konsole itself, to cope with cases of OSes distributing their own curses.


Now Alexander, or anyone else, if you like to help to go down this way, or you
have any other proposals how to improve matters, i would be firmly on your side.


Hmm, another alternative might be to redefine the 1049 to include mouse events,
leaving the poor terminfo guys alone. One could also try a konsole terminfo entry
containing:

smcup=\E?47h\E?1000h, rmcup=\E?47l\E?1000l

to get mc properly working with a TERM=konsole, but this alone does not work
given the present state of mc. It only ends with mouse events being echoed on
the command line...

Another hint found in mouse(3NCURSES):

       If the terminfo entry contains a XM string, this is used in the xterm mouse
       driver to control the way the terminal is initialized for mouse  operation.
       The default, if XM is not found, corresponds to private mode 1000 of xterm:
              \E[?1000%?%p1%{1}%=%th%el%;

but there is no XM string defined in terminfo(5)...

Perhaps, if anyone would like to have a look at the mc's code, the presence of
"kmous" would today be a pretty save indicator for an xterminal too...


Kind regards,

  Lars