When on the console, the Home and End keys produce the following escape sequences respectively: ^[[1~ ^[[4~ In the current ebuild of rxvt however, the following are produced: ^[[7~ ^[[8~ To replicate, you can log in and then type: <ctrl-v><Home> to see what escape sequence it would have sent to the terminal. This does not cause immediate problems since rxvt's codes are supported in /etc/inputrc, however this only helps programs that use readline. I also knew that this was not always the case with rxvt: up until last weekend I was using rxvt on Red Hat 9 with no problems like this. The first example of problems I found with this is that when I ssh to a remote host that previously had working Home/End behaviour I find this no longer works. I can then edit the /etc/inputrc or .inputrc on all remote hosts I expect to connect to but this is time consuming and hackish and does not help for an application such as Mutt. In Mutt you will see a default keybinding like this: <Home> top jump to the top of the message with a similar one for <End>. With the codes that rxvt's ebuild produces not matching what Mutt considers to be <Home> and <End>, one way to fix it would be to add another keybinding for the specific codes that _are_ produced. I didn't like the idea of editing so many config files and application keybindings though, so I asked around some more. John Paul Wallington found this: > Looks like it is at compile-time for rxvt: > > /build/rxvt/src/feature.h:183 > > /* > * To use > * Home = "\E[1~", End = "\E[4~" > * instead of > * Home = "\E[7~", End = "\E[8~" [default] > */ > /* #define LINUX_KEYS */ I believe that previous installations of rxvt that I have used must have been compiled with this set, and gentoo's ebuild has not set this. In the meantime I read some more docs and came up with this workaround: [andy@fullers tmp]$ cat ~/.Xdefaults rxvt*keysym.0xFF50: \e[1~ rxvt*keysym.0xFF57: \e[4~ (if you want to see the difference this makes without restarting X, do: xrdb -override ~/.Xdefaults) It should also be noted that rxvt on gentoo sets the TERM to xterm, which means that all the xterm conditional parts of /etc/inputrc will be read. Following these parts are some other lines that have the comment "for German users" which then override settings for beginning-of-line and end-of-line. So, I had to add this at the end: # XXX RXVT! # "\e[1~": beginning-of-line "\e[4~": end-of-line I don't know if what I have done is 100% correct. All I know is: - This used to work fine before when I was using Red Hat and both console and rxvt were producing the "\e[1~" and "\e[4~" codes. - When I installed gentoo rxvt was producing different codes for these keys. - Home and End stopped working in the majority of the remote machines I connect to, which include a wide variety of unix OS's, all of which worked before. - After this workaround they now all work again as I'd expect - I think that #define LINUX_KEYS will make my workaround unnecessary.
Reassigning to maintainer of rxvt. Usata, could you please check what should happen to this report? Andy, is this still a problem?
Sorry for the delay. Gentoo sets TERM to rxvt since last November, but doesn't set -DLINUX_KEYS. I added it to rxvt-2.7.10-r1.ebuild, so please test and report back if this works or not.
*** Bug 74805 has been marked as a duplicate of this bug. ***
*** Bug 74262 has been marked as a duplicate of this bug. ***
Maybe I'm readind this wrong, but bug 74805 and bug 74262 don't look like duplicates of this bug. Quite to the contrary, they seem to be the opposite of this bug report, and seem to actually have been caused by the "solution" to this report, i.e. compiling rxvt with -DLINUX_KEYS without properly updating the terminfo portion of the ncurses package. I see no good reason for rxvt Home/End to behave identically to Linux console, that's what ncurses/terminfo is for after all, to handle these types of differences across terminals. There should be no reason for Andy to edit /etc/inputrc on all machines, provided they have properly installed terminfo or termcap libraries and databases. If there is still a problem for some reason and -DLINUX_KEYS must be used, then the maintainer of this ebuild should have also made sure that the ncurses ebuild is patched too, to properly reflect the new keys of rxvt. Otherwise, simply adding -DLINUX_KEYS by itself causes more problems than it solves, so either revert this, or provide a patch to future ncurses ebuilds that will modify /etc/terminfo/r/rxvt appropriately. Things are simply broken right now.
I bumped rxvt-2.7.10-r1 into stable simply because I hadn't any bugreport for one month. I put it back to ~ masked for the time being. (That's why I didn't mark this bug CLOSED and left it as TEST-REQUEST) Please revert to the previous revision if you have problem with -r1. I agree with Ivan with patching ncurses ebuild when I made the change, but don't have time to do that atm. Sorry again.
Hi, I'm the reporter of 74262, and Ivan's right that my bug is the opposite of this one, and was caused by the solution to this one. Regarding changing /etc/terminfo/r/rxvt to accomodate -DLINUX_KEYS, I think it would be a bad idea, unless we can also make the same change upstream with whoever maintains the "master" terminfo database, and tell everyone on the planet to update their terminfo db. Otherwise, whenever we connect to a non-Gentoo system with rxvt, the remote system would still expect the keycodes in the un-updated db.
I introduced linuxkeys local USE flag to rxvt-2.7.10-r2, so someone who really needs to define LINUX_KEYS (and change HOME/END key) can set it through the USE flag. Thanks for your comments and suggestions.
