If I'm editing a file that has long lines, using `nano -w`, the Home and End keys don't work as expected. ^a and ^e work OK as Home and End respectively, but: End inserts "F" at the line start and Home inserts "H" at the line start. I've remerged nano and baselayout (for /etc/initrc) to no avail. vim works perfectly. This only happens from KDE's konsole or from xterm. aterm is OK as is a non-gui console. In KDE my workaround is to edit ~/.kde3.1/share/apps/konsole/shell.desktop, changing 'Exec=' to 'Exec=bash' and 'Term=xterm' to 'Term=linux'. I posted this on gentoo-dev and got my knuckles rapped by foser for posting there; he said it is being worked on but I couldn't find it in bugzilla
Problem is xterm's terminfo entry is lacking khome/kend definitions. Technically, whenever ncurses sees an escape character followed by another character sequence, it checks what TERM is set to and consults the corresponding terminfo entry for key definitions. If there's a match, ncurses translates this sequence to a single value, if not, the sequence is seen by applications as individual keystrokes. You can check this with the `tack' command, or use the test program below. For example, home and end in xterm send "\e[H" and "\e[F", respectively. Nano tries to interpret some of those sequences itself -- it seems to recognize "\e[", but gives up if they're followed by H or F, so it eats "\e[" and prints H or F. As a quick fix, go to `/usr/share/terminfo/x', there's a `xterm' symlink that points to `xterm-color'. Change that so it points to `xterm-xfree86', and with the xfree-4.2 xterm all keys should be working now (in xfree-4.3, some shifted keys have changed, but normal home/end are not affected). Here's my test program, compile with `gcc -lncurses ti_test.c -o ti_test' --- #include <curses.h> int main() { int ch; char *key; initscr(); cbreak(); noecho(); keypad(stdscr, TRUE); scrollok(stdscr, TRUE); printw("press any key to see its keycode, 'q' quits\n"); for(;;) { if((ch = getch()) == 'q') break; key = ch == 0x1B ? "<ESC>" : keyname(ch); printw("0x%04X: %s\n", ch, key); } endwin(); return 0; } --- If terminfo is set up correctly, it will print `KEY_HOME' and `KEY_END' when home and end are pressed.
Created attachment 12875 [details, diff] ncurses-5.3-xterm.patch patch for ncurses-5.3 to make the `xterm' terminfo entry an alias for `xterm-xfree86' and update `xterm-xfree86' keydefs that have changed in xfree-4.3.
Created attachment 12876 [details, diff] ncurses-5.3-r1.ebuild.diff modified ebuild that makes use of the above patch and doesn't create the terminfo/x/xterm symlink.
bartron, can you do me favour and open a bug in Gentoo New Developer section, please?
bartron, 2 things: 1. Thanks a bunch for this and the openmotif stuff (openmotif is being checked in in a few minutes, with your fixes). 2. Please see comment #4 above
uh, I know this bug has been closed long ago, but indirectly there is still an issue with it: Currently ncurses-5.3-r2, -r3 and -r4 have the patch, but the latest stable version for all archs (besides alpha) is -r1
I think there is still an open issue with PuTTY that hasn't been confirmed yet (bug #26076). By default, PuTTY assumes xterms can't do `background-color-erase' (which in fact they do, even in really ancient versions as shipped with some commercial OSs). But since >=-r2 still masked... there's another issue -r0..-r4 don't address yet... `kbs'. Traditionally, backspace would send ^H, but since emacs has adopted ^H to mean `help' a long time ago, the linux console as well as some xterms around have redefined backspace to send ^? instead. Looking through the tree, the only other term that should set `TERM=xterm' is konsole (easily fixed to send ^? as well). Question is, is there some way to force-update xfree(xterm), kde(konsole), and ncurses all at the same time to break as few systems as possible with this change.
Wasn't -r2 in x86 a long time ago? I sure never used ~x86; but I still have -r2 on my box since early july. Whats the point haveing a broken setup just to support putty, a windoze program? Just out of curiosity, is this kbs thingy the reason, why C-H in emacs in xterms acts like backspace? If so, it would be nice to see this fixed in -r5; would make Gentoo the only linux in existence, where every key in xterm does exactly what it should.
