Recent update to rxvt-unicode package changed the key binding for scrolling up and down by page. It used to be realized by S-PgUp and S-PgDn. Now this binding changed to C-PgUp and C-PgDn. I understand that the problem that the maintainer was trying to solve with this change was to keep tabbing working in face of added support for per-line scrolling. While I agree with that attitude in general (I use tabs quite a bit), I think that changing the tab-creation key to C-down (now it's S-down) would be a less invasive change. Since the tab movement keys use ctrl anyway, that would even make sense. I'd like to ask the maintainer to revert this change. I think that the use of shift for scrolling is well established, pretty much any terminal that I ever used including the linux console has shift dedicated to this operation, and changing that default is inconvenient. This problem is further complicated by the fact that urxvt doesn't exactly lend itself into key-binding configuration. Version-Release number of selected component (if applicable): rxvt-unicode-9.10-1.fc14.x86_64
I have to admit that I'd like to see shift-{pgup,pgdown} reverted for scrolling too.
The change from Shift to Control has (IMHO) violated the Principle of Least Astonishment. rxvt{,-unicode} is now out of sync and incompatible with other terminal applications (such as xterm, GNOME terminal, ...). Actually, apparently only Fedora rxvt{,-unicode}, so it's out of sync and incompatible with the vanilla rxvt packages, too. The way the change was implemented has forced users to a new UI, will-shi nil-shi. For instance, C-Up and C-Down are default bindings in Emacs for backward-paragraph and forward-paragraph. This change means that Emacs in an rxvt terminal window no longer has access to these, although they work in an Emacs X session. That's breakage. I suggest that these internal and hardcoded functions and their bindings be exposed so that users can bind them however they like using the 'keysym' X resource mechanism. Set the defaults however you like, but don't force your choices on the user without giving him a chance to maintain his own preferences.
As a temporary workaround, the following ~/.Xresources additions show how this can be overridden: URxvt.keysym.C-Up: \033Oa URxvt.keysym.C-Down: \033Ob URxvt.keysym.S-Prior: command:\033]720;23\007 URxvt.keysym.S-Next: command:\033]721;23\007
(In reply to comment #2) > Set the defaults however you like, but don't force your choices on the user > without giving him a chance to maintain his own preferences. I agree. This should best be resolved upstream. I will see to write a patch for this asap and submit it upstream.
rxvt-unicode-9.10-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/rxvt-unicode-9.10-2.fc14
rxvt-unicode-9.10-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update rxvt-unicode'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/rxvt-unicode-9.10-2.fc14
... except that now the setting for new tab creation is C-t. That key is commonly bound to character transposition in shell. Why not make it C-down as I proposed?
rxvt-unicode-9.10-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #7) > ... except that now the setting for new tab creation is C-t. That key is > commonly bound to character transposition in shell. Why not make it C-down as > I proposed? Any hard-coded keyseq is going to be a problem for *someone*. Why not make it configurable with a resource setting?
(In reply to comment #9) > (In reply to comment #7) > > ... except that now the setting for new tab creation is C-t. That key is > > commonly bound to character transposition in shell. Why not make it C-down as > > I proposed? > > Any hard-coded keyseq is going to be a problem for *someone*. Why not make it > configurable with a resource setting? I second that.