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 _______________________________________________ konsole-devel mailing list konsole-devel@kde.org https://mail.kde.org/mailman/listinfo/konsole-devel