The home and end keys don't seem to work consistently: in vim they work fine, but mutt and less don't recognise them as home and end (though they do recognise that I pressed _something_). I'm using pterm 0.53-2002-10-26-1, zsh-beta 4.1.0-dev-6+cvs20021005-2, vim 6.1.206-1 and mutt 1.4.0-4. According to cat, home generates this: ^[[1~ and end generates this: ^[[4~ Under Eterm, they generate ^[[7~ and ^[[8~, respectively. $ echo $TERM xterm Using the pterm.RXVTHomeEnd option doesn't seem to help either.
respectively (current CVS). 'xterm -e cat' shows Home and End generating ^[[H and ^[[F. Debian's rxvt produces ^[[7~ and ^[[8~. I'm clueless about this kind of thing, so I'll simply forward it on and hope I've done everything in FAQ section A.6.17. Should I just go for trying to propagate a PuTTY terminfo entry instead? :-) Thanks,
----- Forwarded message from Simon Tatham <anakin@pobox.com> ----- From: Simon Tatham <anakin@pobox.com> Cc: putty@projects.tartarus.org Reply-To: putty@projects.tartarus.org To: Colin Watson <cjwatson@debian.org> Subject: Re: [putty]Re: Bug#167629: pterm: Inconsistent home/end behaviour Date: Tue, 05 Nov 2002 13:30:45 +0000 [...] I've been tempted for some time by the idea of a PuTTY terminfo entry, but I'd really prefer to coexist peacefully within `xterm' if possible, if only because of the practical considerations (that almost all machines will lack the PuTTY terminfo at least to begin with). I'll have (yet) another look at the function of Home and End in various termulators and we'll see. It might be that I'll have to add yet another key mapping option, and perhaps change the default as well... Cheers, Simon----- End forwarded message -----
This bug is covered by PuTTY wishlist item "xterm-keyboard": <http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/xterm-keyboard.html> [ which points out that the rest of PuTTY's keyboard mapping is wonky too ]
forwarded 167629 http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/xterm-keyboard.html thanks Thanks. I think I'll start switching the forwarded-to address over as above, in cases where there's an explicit wishlist item filed.
and 'TerminalType' to 'rxvt'. Regarding to documentation setting RXVTHomeEnd
to '1' should instruct pterm to emit rxvt-like home and end key sequences,
and this should work when TerminalType is also set to rxvt.
Documentation of pterm states: "'rxvt' sends 'ESC [H' for the Home key and
'ESC [Ow' for the End key." But this is not correct. When trying out with
rxvt, one finds out that rxvt (at least in the actual version as in debian
unstable) sends 'ESC [7~' for the Home Key and 'ESC [8~' for End key. Therefore
the sources of pterm/putty needs to be modified in this.
I suggest adding the following patch at least to the debian version:
--- putty-0.55/terminal.c 2004-07-29 19:56:50.000000000 +0200
+++ putty-0.55-fixed/terminal.c 2004-10-26 14:23:37.000000000 +0200
@@ -4586,7 +4586,7 @@
/* RXVT Home/End */
if (term->cfg.rxvt_homeend &&
(keysym == PK_HOME || keysym == PK_END)) {
- p += sprintf((char *) p, keysym == PK_HOME ? "\x1B[H" : "\x1BOw");
+ p += sprintf((char *) p, keysym == PK_HOME ? "\x1B[7~" : "\x1B[8~");
goto done;
}
diff -Naur putty-0.55/unix/pterm.c putty-0.55-fixed/unix/pterm.c
--- putty-0.55/unix/pterm.c 2004-07-27 17:20:37.000000000 +0200
+++ putty-0.55-fixed/unix/pterm.c 2004-10-26 14:23:27.000000000 +0200
@@ -916,7 +916,7 @@
goto done;
}
if (inst->cfg.rxvt_homeend && (code == 1 || code == 4)) {
- end = 1 + sprintf(output+1, code == 1 ? "\x1B[H" : "\x1BOw");
+ end = 1 + sprintf(output+1, code == 1 ? "\x1B[7~" : "\x1B[8~");
use_ucsoutput = FALSE;
goto done;
}
diff -Naur putty-0.55/window.c putty-0.55-fixed/window.c
--- putty-0.55/window.c 2004-07-29 19:56:50.000000000 +0200
+++ putty-0.55-fixed/window.c 2004-10-26 14:23:11.000000000 +0200
@@ -3793,7 +3793,7 @@
return p - output;
}
if (cfg.rxvt_homeend && (code == 1 || code == 4)) {
- p += sprintf((char *) p, code == 1 ? "\x1B[H" : "\x1BOw");
+ p += sprintf((char *) p, code == 1 ? "\x1B[7~" : "\x1B[8~");
return p - output;
}
if (code) {
When applying this patch and adding the following Lines to ~/.Xresources
everything works fine:
pterm.RXVTHomeEnd: 1
pterm.TerminalType: rxvt
in current rxvt, <CSI O w> is numeric keypad Home, not End at all, so I
don't see how the current code can be correct? Anyway, belatedly
forwarding the patch.
Going back to xterm compatibility and surveying the available
LinuxFunctionKeys modes in pterm, "pterm.LinuxFunctionKeys: 5" (a.k.a.
FUNKY_SCO) appears to match xterm's current behaviour for Home/End, but
very little else; Insert/Delete/PageUp/PageDown match xterm in
LinuxFunctionKeys modes 0 (FUNKY_TILDE), 1 (FUNKY_LINUX), 2
(FUNKY_XTERM), and 4 (FUNKY_VT100P).
Here's a patch that makes pterm emit sequences that match current xterm
in FUNKY_XTERM mode. If you don't want to apply it without making it
configurable as well, would you mind if I applied this at least in
Debian, so that we're in sync with the way other Debian terminal
emulators behave?
Index: windows/window.c
===================================================================
--- windows/window.c (revision 5386)
+++ windows/window.c (working copy)
@@ -3981,6 +3981,10 @@
p += sprintf((char *) p, code == 1 ? "\x1B[H" : "\x1BOw");
return p - output;
}
+ if (cfg.funky_type == FUNKY_XTERM && (code == 1 || code == 4)) {
+ p += sprintf((char *) p, code == 1 ? "\x1B[H" : "\x1B[F");
+ return p - output;
+ }
if (code) {
p += sprintf((char *) p, "\x1B[%d~", code);
return p - output;
Index: terminal.c
===================================================================
--- terminal.c (revision 5386)
+++ terminal.c (working copy)
@@ -5984,6 +5984,13 @@
goto done;
}
+ /* Xterm Home/End */
+ if (term->cfg.funky_type == FUNKY_XTERM &&
+ (keysym == PK_HOME || keysym == PK_END)) {
+ p += sprintf((char *) p, keysym == PK_HOME ? "\x1B[H" : "\x1B[F");
+ goto done;
+ }
+
if (term->vt52_mode) {
int xkey;
Index: unix/gtkwin.c
===================================================================
--- unix/gtkwin.c (revision 5386)
+++ unix/gtkwin.c (working copy)
@@ -953,6 +953,11 @@
use_ucsoutput = FALSE;
goto done;
}
+ if (inst->cfg.funky_type == FUNKY_XTERM && (code == 1 || code == 4)) {
+ end = 1 + sprintf(output+1, code == 1 ? "\x1B[H" : "\x1B[F");
+ use_ucsoutput = FALSE;
+ goto done;
+ }
if (code) {
end = 1 + sprintf(output+1, "\x1B[%d~", code);
use_ucsoutput = FALSE;
Thanks,
I've been belatedly revisiting this bug today. I've used TERM=putty-256color as a workaround for this sort of thing for a long time, but that has some other significant annoyances: I'm forever having to set TERM=xterm-256color for various applications, and that's what PuTTY's own documentation recommends, so I'd like to get back to it. However, having Home and End not work in my editor (compare https://github.com/neovim/neovim/issues/6014) is indescribably annoying. This updated version of my patch from 2005 seems to work to align PuTTY a bit more closely with "modern" xterm behaviour (r6 and onwards); but I make no claim to having extensively vetted its compliance with the official terminfo entries, as I'm afraid I find terminfo rather impenetrable! diff --git a/terminal/terminal.c b/terminal/terminal.c index 584bd3e6..26759193 100644 --- a/terminal/terminal.c +++ b/terminal/terminal.c @@ -7617,6 +7617,10 @@ int format_small_keypad_key(char *buf, Terminal *term, SmallKeypadKey key, } } else if ((code == 1 || code == 4) && term->rxvt_homeend) { p += sprintf(p, code == 1 ? "\x1B[H" : "\x1BOw"); + } else if ((code == 1 || code == 4) && + (term->funky_type == FUNKY_XTERM || + term->funky_type == FUNKY_XTERM_216)) { + p += sprintf(p, code == 1 ? "\x1B[H" : "\x1B[F"); } else { if (term->vt52_mode) { p += sprintf(p, "\x1B[%d~", code); Thanks,