You are not logged in.
I'm not sure whether to file a bug report. Here is the situation...
The PKGBUILD for rxvt-unicode-256color uses the build flag "-with-term=rxvt-256color". The terminfo for /usr/share/terminfo/r/rxvt-256color uses ^H as the backspace character. However, urxvt(1)'s manpage says that if the resource backspacekey (in ~/.Xdefaults) is set to DEC or unset, it will send code 127 (aka ASCII DEL aka \177 or ^?).
So here I am writing my C program with ncurses, and I do this:
...
int ch;
ch = getch();
if (ch == KEY_BACKSPACE) {
/* do stuff */
}And the if-statement fails, because ncurses uses terminfo, and the terminfo entry for rxvt-256color expects ^H as the backspace character. It looks like rxvt-unicode-256color is telling ncurses that its backspace key is ^H, when in fact it is ^?.
So, I was thinking of ways to get around this somehow.
If I use a different terminfo entry with
export TERM=rxvt-unicode, then it works because the terminfo for rxvt-unicode uses "kbs=\177" (thus correctly telling ncurses that ^? is the backspace key). But now rxvt-unicode does not support 256 colors. ![]()
A better (though more complicated) solution is to edit rxvt-unicode's terminfo entry like so:
# Change the following from:
#
# lines_of_memory#0, max_colors#88, max_pairs#256,
#
# to:
#
# lines_of_memory#0, max_colors#256, max_pairs#32767as described at http://scie.nti.st/2008/10/13/get-rxvt- … -on-ubunut, and just use that terminfo entry by configuring rxvt-unicode-256color with the flag "-with-term=rxvt-unicode-256color" with ABS.
I guess my problem only applies to ncurses programmers at the moment -- and I could live with the solutions I described above, terminfo/ncurses be damned. But, should I file a bug report nonetheless?
Last edited by listdata (2010-10-20 17:32:23)
Offline
I had to work around the same issue when using terminfo (for zsh keybindings) and it seems like it would be better if the 256color patch modified the terminfo that ships with rxvt-unicode instead of pretending to be rxvt
filing a bug report sounds like a good idea
thestinger@arch i ~ % pacman -Qo /usr/share/terminfo/r/rxvt-256color
/usr/share/terminfo/r/rxvt-256color is owned by ncurses 5.7-3
thestinger@arch i ~ % pacman -Qo /usr/share/terminfo/r/rxvt-unicode
/usr/share/terminfo/r/rxvt-unicode is owned by rxvt-unicode-256color 9.07-9Last edited by thestinger (2010-10-12 19:43:13)
Offline
I had to work around the same issue when using terminfo (for zsh keybindings) and it seems like it would be better if the 256color patch modified the terminfo that ships with rxvt-unicode instead of pretending to be rxvt
filing a bug report sounds like a good idea
thestinger@arch i ~ % pacman -Qo /usr/share/terminfo/r/rxvt-256color /usr/share/terminfo/r/rxvt-256color is owned by ncurses 5.7-3 thestinger@arch i ~ % pacman -Qo /usr/share/terminfo/r/rxvt-unicode /usr/share/terminfo/r/rxvt-unicode is owned by rxvt-unicode-256color 9.07-9
Ah, the fact that rxvt-unicode-256color does not use its own terminfo entry seems like another nail in the coffin.
Bug filed at https://bugs.archlinux.org/task/21235
I even made a patch, a new PKGBUILD and all that works! I just modified the terminfo entry that comes with rxvt-unicode as you suggested. Download the tarball I uploaded at the bugtracker at https://bugs.archlinux.org/task/21235?getfile=5837, and test it out. Please continue discussions over at the bugtracker as well.
Last edited by listdata (2010-10-13 18:08:03)
Offline
The bug has been closed (since Oct. 18) --- my patch got accepted into package version 9.07-10!
Marked SOLVED.
Last edited by listdata (2010-10-20 17:34:54)
Offline