Page Up and Page Down
Sat Sep 17 17:03:00 GMT 2005
On Sat, 17 Sep 2005, Mike Hicks wrote:
> [whoops, forgot to CC: this to the list]
> On 9/16/05, Thomas Dickey <email@example.com> wrote:
>> On Fri, 16 Sep 2005, Mike Hicks wrote:
>>> On my Linux box at home, I believe xterm always produces ^[[5~ and
>> It sounds like your Linux system is running Redhat. I get lots of
>> complaints about that (for instance earlier today ;-). For quite a while
>> (I'm told it was corrected in Fedora) their package for xterm alters most
>> of the key translations, lobotomizing it to look like someone's
>> improvement to old xterm.
> Actually, I use Debian, so who knows how up-to-date the program is ;-)
> Most of the time, I actually use aterm at home (i like
> semi-transparent windows), which produces ^[[5~ and ^[[6~ in the
> middle extended section, but ^[Oy and ^[Os for numberpad PgUp/PgDn.
> rxvt on my Linux box behaves the same as aterm.
hmm - Friday's a bad day for thinking. I was looking at home/end
Pageup/pagedown are as noted \E[5~ and \E[6~ for the editing keypad.
However, the point I was interested in is the effect of the control,
shift, meta modifiers on the strings sent by the keys (based on your
comment of "always" in combination with the keypad). While some of those
are intercepted before xterm really sees them, it can (once it sees them)
make them send more interesting combinations to the host, e.g., \E[6;5~
That all goes away with the hacked-up app-defaults file, since it changes
the data before xterm can see it. While translations are useful, etc.,
there's no nice way to make them contingent on the application's state -
so the packagers that set translations are removing functionality from
Debian modifies the backspace/delete stuff, but otherwise doesn't get in
my way regarding the app-defaults file. (I replace it anyway).
> Curiously, while PuTTYcyg always produces ^[[5~ and ^[[6~ on the
> command line, it produces ^[Oy and ^[Os on the number pad when I go
> into using vim. I suppose that's from initializing the terminal into
> a different mode? Well, that's not one of your guys' programs, so I'm
> not sure if it's designed to work that way or what..
long: That's part of the numeric keypad's application-mode. A vt100 does
something like that. PuTTY and xterm differ according to how they support
the vt100's PF1-PF4, and how NumLock is used. xterm also (barring
packagers' changes to app-defaults files) has different keyboard styles
for sending vt100- or PC-style codes for the numeric keypad.
short: it's designed to work that way
> Heh, I finally came across your xterm FAQ
> [http://dickey.his.com/xterm/xterm.faq.html] in searching for how to
> set up X resources to change this, and I'll probably try adding lines
> <Key>Prior: string(0x1b) string("[5~") \n\
> <Key>Next: string(0x1b) string("[6~") \n\
> <Key>KP_3: string(0x1b) string("Os") \n\
> <Key>KP_9: string(0x1b) string("Oy") \n
> ...when I get back to work on Monday
> That's probably all I needed, but I've had a heck of a time searching
> with Google about this topic since typing "^[[5~" in the search box
> only searches on "5". *sigh*
yes - punctuation tends to be ignored. There aren't a lot of places to
look anyway. Shuford's archive and vt100.net are useful for seeing more
about the expected keypad behavior. PuTTY does have documentation, but I
don't find it useful. If I want to know something about PuTTY, it's
simpler to answer the question by reading its source code.
Thomas E. Dickey
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin-xfree