Thanks for the report.  Having read through the mentioned terminfo it appears that many of the changes in the "konsole" terminfo entry were written to work around bugs in Konsole. 

Unless there are major reasons why Konsole cannot behave like xterm, I would prefer it to do so.  That is, if there are bugs in Konsole which cause programs to work incorrectly when "TERM" is set to 'xterm' and correctly when it is set to 'konsole' I would prefer to find out and fix them.  If you know of any, please mention them in replies to this report.

I need to get in touch with the terminfo maintainer(s) and discuss what to do for KDE 4.  With regards to KDE 3, I don't know whether there will be a KDE 3.5.8 release, if there is I might be able to make this change.

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

Robert,

> Having read through the mentioned terminfo it appears that many 
> of the changes in the "konsole" terminfo entry were written to work
> around bugs in Konsole. 


No, as the konsole works well the current xterm terminfo entry, and the
konsole terminfo entry is not in use. It is different, that's all, no indication
of bugs, as i good as i know.

It absolutely makes sense to have an own terminfo/termcap entry, to
desynchronize the konsole from the xterm, but this is not possible yet
not because of bugs in the konsole but because of the state of curses,
termcap and mc.

The problem could be solved getting in contact with the current mc
maintainer. I was in contact with Miguel de Icaza, long time ago, but
could neither manage to make the problem clear to him, nor fix it
myself. The state has been improved significantly, since, and one
could give it another shot.

-lars

Hello Lars,

Thank you for an extremely informative and interesting explanation, I really appreciated it and learned a lot from it :)

So, the situation was a bit more complicated than I had thought.

Basically, the following is what terminfo would need to be able to describe:
* How to switch to the secondary screen
* How to switch back to the primary screen
* How to turn on mouse events (hmm, but getm might be enough already?)
* How to turn off mouse events

Another mouse capability I thought of that would enhance mouse support in terminals is support for motion events.

From http://www.linuxjournal.com/article/1136 :

"If you consider ever running your application under an xterm, you must be sure to not depend on a full event reporting. Specifically, you won't be informed of any motion or drag events, and button-release events won't specify which button of a set has been released. This means, in practice, that if you need precise reporting of a double-button press, your application will not work properly under xterm."

The first is what I suspected, that xterm doesn't support motion events. However, I don't understand the second problem. From what I've read, a 'release' is simply a 'pressed' event sent once again to indicate that the button has been released.

Also, do you know what causes the window resize problem with TERM=konsole mc? I tried the same in vim, and it does seem to be able to handle it. I found out that there was terminfo capabilities named 'lines' and 'cols', but these don't seem to be it, as they're statically defined to certain numbers. I assume vim is always sending some xterm-specific CSI-code, while mc is only doing this if $TERM == 'xterm'?

Regards, Alexander Toresson

> The first is what I suspected, that xterm doesn't support motion events.

Konsole does support motion events under KDE 4.  The programs that I have tested which make use of motion events, such as Vim, work correctly when TERM is set to "xterm".

I really do think it would be simpler if Konsole just aimed for compatibility with xterm on features/bugs that matter and gave "xterm" as its $TERM value.