Comment 25 for bug 96676

Micah, looking in further detail at xterm's terminfo file, I found some interesting stuff.

Its terminfo file contains multiple definitions for kf25, under multiple term types:
xterm+pcfn: kf25=\E[46~
xterm+pcfN: kf25=\E[46~
xterm+pcf0: kf25=\EO5P
xterm+pcf1: kf25=\E[5P
xterm+pcf2: kf25=\E[1;5P
xterm+pcf3: kf25=\E[>1;5P
xterm-sco: kf25=\E[k

on my ubuntu install, xterm produces the string from xterm+pcf2 ( \E1;5P )
vte would produce \EO1;5P except that ctrl-f1 is intercepted somewhere...but ctrl+f2 produces \EO1;5Q so the point is still valid.

It looks to me as if vte is trying to do some sort of rewriting from the pcf1 sequence to the pcf0 sequence. However, since the sequence it's doing it on is the pcf2 sequence it's doing the wrong thing. I'm 90% sure that's what's going on.

Which mode of xterm is vte supposed to be emulating? If it's supposed to be 'all of them' it fails:
CSI > P s ; P s m
Set or reset resource-values used by xterm to decide whether to construct escape sequences holding information about the modifiers pressed with a given key. The first parameter identifies the resource to set/reset. The second parameter is the value to assign to the resource. If the second parameter is omitted, the resource is reset to its initial value.
→ 1 modifyCursorKeys
→ 2 modifyFunctionKeys
→ 4 modifyOtherKeys
--end quote--

This means that "echo -e '\e[>2;0m' should put xterm into pcf0 mode, and then ctrl+f1 should generate \eO5P. On xterm it does, on vte it doesn't. same for \e[>2;1m, \e[>2;2m, and \e[>2;3m