As the original author of the code noticed in his comment,
home and end are a can of worms.
I just noticed that what xterm actually does, what termcap says about it,
and what terminfo says about it are three quite different things.

My changes above work with bash/readline, with nano, with some other apps,
but break vi.

Next attempt:
1. Leave the base sequences unchanged as "^[OH" and "^[OF".
2. Add xterm's modifier sequences "^[[1;5H" and "^[[1;3H" etc.

Makes readline, nano and vi happy for me.

New patch:
--- keymap.c.orig       2009-11-04 10:18:09.000000000 +0100
+++ keymap.c    2009-11-04 13:22:20.000000000 +0100
@@ -279,14 +279,14 @@
        {cursor_all, keypad_all, fkey_all, 0, X_NULL, 0, "kh"},
        {cursor_all, keypad_all, fkey_vt220, 0, _VTE_CAP_CSI "1~", -1, X_NULL},
        {cursor_all, keypad_all, fkey_hp, 0, _VTE_CAP_ESC "h", -1, X_NULL},
-       {cursor_all, keypad_all, fkey_nothpvt, 0, X_NULL, 0, "kh"},
+       {cursor_all, keypad_all, fkey_nothpvt, 0, _VTE_CAP_SS3 "H", -1, X_NULL},
        {cursor_all, keypad_all, fkey_all, 0, X_NULL, 0, X_NULL},
 };
 
 static const struct _vte_keymap_entry _vte_keymap_GDK_End[] = {
        {cursor_all, keypad_all, fkey_all, 0, X_NULL, 0, "@7"},
        {cursor_all, keypad_all, fkey_vt220, 0, _VTE_CAP_CSI "4~", -1, X_NULL},
-       {cursor_all, keypad_all, fkey_notvt220, 0, X_NULL, 0, "@7"},
+       {cursor_all, keypad_all, fkey_notvt220, 0, _VTE_CAP_SS3 "F", -1, X_NULL},
        {cursor_all, keypad_all, fkey_all, 0, X_NULL, 0, X_NULL},
 };
 
@@ -1265,6 +1265,8 @@
        case GDK_Delete:
        case GDK_Page_Up:
        case GDK_Page_Down:
+       case GDK_Home:
+       case GDK_End:
        case GDK_KP_Up:
        case GDK_KP_Down:
        case GDK_KP_Left:
@@ -1273,6 +1275,8 @@
        case GDK_KP_Delete:
        case GDK_KP_Page_Up:
        case GDK_KP_Page_Down:
+       case GDK_KP_Home:
+       case GDK_KP_End:
        case GDK_F1:
        case GDK_F2:
        case GDK_F3:
@@ -1409,7 +1413,7 @@
                /* SS3 should have no modifiers so make it CSI instead. See
                 * http://cvsweb.xfree86.org/cvsweb/xc/programs/xterm/input.c.diff?r1=3.57&r2=3.58
                 */
-               if (cursor_app_mode &&
+               if (/*cursor_app_mode && */
                        g_str_has_prefix(nnormal, _VTE_CAP_SS3)
                        && is_cursor_key(keyval)) {
                        nnormal[1] = '[';

As per https://bugzilla.gnome.org/show_bug.cgi?id=425462#c20 , moving my comments here. This bug is confirmed and has at least 2 duplicates:

https://bugzilla.gnome.org/show_bug.cgi?id=599634
https://bugzilla.gnome.org/show_bug.cgi?id=612453

Original comment below:

Behdad Esfahbod, I know you are the MAN that fixed the freaking invisible
cursor bug. This one has been around for 3 years already. Could you please look
into this?

I'm coming from the mc side. We recently mapped CTRL+Home and CTRL+End to the
movements to the beginning and the end of file to adhere to the standard set by
other editors. 

What we've got is that herds of vte-based terminal users are now screaming,
because vte and consequently gnome-terminal sends the same sequences for
Home/End and CTRL+Home / CTRL+End so that we can't distinguish them.

Xterm(243):

Home = ^[[H
End = ^[[F
CTRL+Home = ^[[1;5H
CTRL+End = ^[[1;5F

GNOME Terminal 2.28.1

Home = ^[OH
End = ^[OF
CTRL+Home = ^[OH
CTRL+End = ^[OF

PLEASE PLEASE PLEASE!

FYI in Konsole / Xterm mode I get correct Xterm sequences, it's just VTE that
does not distinguish between Home and CTRL+Home.

Behdad to the rescue!!! The last patch looks good to me.

*** Bug 599634 has been marked as a duplicate of this bug. ***

*** Bug 612453 has been marked as a duplicate of this bug. ***

Copying useful script from one of the dupe bugs:

#!/usr/bin/perl -w

use Term::ReadKey;
ReadMode('cbreak');
print "Press keys to see their ASCII values.  Use Ctrl-C to quit.\n";

while (1) {
    $char = ReadKey(0);
    last unless defined $char;
    printf(" Decimal: %d\tHex: %x\n", ord($char), ord($char));
}

ReadMode('normal');

Friendly ping: it's been a month since my last comment and the bug exists for more than half a year. A reasonably looking patch is floating around. Please finish it! 

Thanks!

Hello?

Right now, I kind of worked around this issue for Debian by building mc --with-x in order to detect the sequences via XQuery* but people keep on complaining, because then it breaks with mc via ssh / with disabled X forwarding... :-(

Please!

Taking a look at this one one...

Many thanks! Keep us posted...

Humm.  After spending half hour on it, I can't claim that I understand how this should be fixed :(.

As long as it's fixed in a way so that the home and end keys in Midnight Commander start working again when running under GNOME terminal, I'll be happy.

What's wrong with my second patch?

That Home and End should accept modifiers
(and the key sequences Home and End should generate 
when they are pressed together with modifiers) are universally agreed on,
there were no objections, they work for me for a year now,
they are what MC expects, ...

The only remaining problem is whether Home and End 
without modifiers should generate ^[[H / ^[[F or ^[OH / ^[OF.
As both xterm and gnome terminal have ^[OH / ^[OF for the Home and End keys
in their terminfo database,
and as ^[[H / ^[[F breaks vim among others,
I think they should remain ^[OH / ^[OF.

And that's what my patch does.

I don't understand your patch.  And I guess you don't understand why it works either.  For example, I expected a non-zero mod_mask field, but I don't see any.

Or what this line is about:

-               if (cursor_app_mode &&
+               if (/*cursor_app_mode && */


I guess it just made it work for you without having an explanation.  I don't know how to test these in app-mode off the top of my head.

Could you please explain what you mean by "app-mode"? Sorry, I'm not familiar with vte development.

Apparently apps (like mc) can switch the terminal to an application mode, in which some keys produce different sequences than in normal mode.  It's all over the place.  And confusing.  And I don't fully understand it either.

I am extremely confused by your follow-up. We are not doing anything fancy inside mc with regards to terminal interaction. We mainly use two libraries (alternatively): SLang or ncurses. These libraries provide us with the escape sequences which are generated by the terminal and then we interpret them ourselves.

I am not aware of any code in mc to instruct these libraries to switch the terminal in the "application mode". I'm not even sure what exactly is this mode and where it is supposed to be documented so that I can check up on this.

Usually we just run cat and press keys in order to visualize which escape sequences are being generated. I am not aware of the cases when they didn't match those that we were getting from our TUI libraries. Alternatively, you can use the Perl script visualize them in a fancier way.

Maybe you are referring to the termcap / terminfo databases?

There's Application Keypad, Application Cursor Keys, etc.  Look for it in ctlseq.txt from xterm.  I don't fully understand it either, but it's relevant to the part of code being touched (and in the way the proposed patch touches it without explanation).

Comment #13:

You're right. I tried to make it work, mostly by looking at and copying
things from other keys, without fully analyzing why the code is the way it is.

But basically, we all don't care why it works as long as it works...

Behdad, I've shown this report to my colleagues and they are telling me that I'm lying to you:

void
application_keypad_mode (void)
{
    if (console_flag || xterm_flag)
    {
        fputs ("\033=", stdout);
        fflush (stdout);
    }
}

Maybe it will be useful for you if you want to test your code in the application mode.

Additional information: they claim that mc uses "application mode", because otherwise, the keypad doesn't work.

Again about Comment #13:

The "if (cursor_app_mode &&" controls changing the "O" in "^[OH" 
to a "[" before inserting the modifier code sequence.

Without commenting out "cursor_app_mode &&",
I think we would get "^[O1;5H" instead of "^[[1;5H" in non-app mode,
which is not what we want:
We always want the the "O" -> "[" change, at least for Home and End.
(however, I did not check what other keys are affected by this change,
and if the change is ok for them. But I didn't notice any breakage up to now).

Thanks both.  These help. I digged into xterm and found some clues about how to handle these.  I'll take another look.

As I noted in

https://bugzilla.gnome.org/show_bug.cgi?id=425462

the bug

https://bugzilla.gnome.org/show_bug.cgi?id=375652

seems to be related to both this and the other bug.

Created attachment 212545 [details] [review]
vte patch to solve mc <-> gnome-terminal keybindings problem

    Please look through my patch for vte. This patch is intended to solve some wide-known problems remaining with some key combinations in (gnome-terminal + mc and mcedit) and creates more comfortable thick blinking underling cursor.
    I don't think it is worth doing to accept this without changes. But it really works. It could be nice if the people who use vi or vim, and gnome-terminal developers, will test, cleare up and finally accept this patch.
    The patch makes the following changes:
    - switching on scrolling for Shift+Up/Down. It does not prevent normal work "inside" mcedit (as I understood, this is "application mode"), so this function was unreasonably moved to Alt+Shiht+Up/Down.
    - unlocked the \e-seq child application feedeng for all the Shift+ - scrolling combinations. These are: Alt+Shiht+Up/Down -> Shiht+Up/Down, Shiht+PgUp/PgDown, Shiht+Home/End.
    - The \e-seq. for all modif.+arrow, modif.+PgUp/PgDown appeared to be correct for me - leaved them unchanged.
    - Adjusted all the \e-seq. for the modif.+Home/End combinations,
    - added double \e\e for Esc that permits to leave mcedit quickly (this is the thing mc-users usially doing),
    - added \e\r for Ctrl+Enter to insert current file in mc to the command string (this tradition is very popular in Russia),
    - provides 1 pixel more thick cursor in underling mode.
    I assumed the \e-seq. for the keys combinations should be:

		Home	End	PgUp	PgDwn	Up	Down
      <>	[OH ([1~)[OF ([4~)[5~	[6~	[A	[B
Alt  +<>	[1;3H	[1;3F	[5;3~	[6;3~	[1;3A	[1;3B
Shiht+<>	[1;2H	[1;2F	[5;2~	[6;2~	[1;2A	[1;2B
Ctrl +<>	[1;5H	[1;5F	[5;5~	[6;5~	[1;5A	[1;5B
Ctrl+Shiht+<>	[1;6H	[1;6F	-	-	-	-
Ctrl+  Alt+<>	[1;7H	[1;7F	-	-	-	-
Shiht+ Alt+<>	[1;4H	[1;4F	[5;4~	[6;4~	[1;4A	[1;4B
Ctrl+Shiht+Alt+<>[1;8H	[1;8F	-	-	-	-

    I failed to provide correct \e-seq. for double-modifiers combinations. For example, you still can not highlight text till the end of file by Shift+Ctrl+End pressing. Sorry, voluntaries welcome.
   The system is: Scientific Linux 6.1, KDE 4.3.4, Gnome-terminal 2.31.3, vte 0.25.1

   And, last but not least. I'm joinig the people who vote that no keybindings should be hardcoded. Of course, gnome-terminal become much flexible, convienient and popular if all the keybindings will be adjustable in the  simple unified manner.

Comment on attachment 212545 [details] [review]
vte patch to solve mc <-> gnome-terminal keybindings problem

Obviously not commit-quality; marking the patch as needs-work.

Anything going on here?

Having no solution is worse than having a 95 % solution...

Somebody needs to rework the patch.

Created attachment 264737 [details] [review]
0001-Home-End-generate-wrong-control-sequences.patch

(In reply to comment #25)
> (From update of attachment 212545 [details] [review])
> Obviously not commit-quality; marking the patch as needs-work.

Ok. Well, I've prepared this patch for committing, but according to comment #24 it has problems.

Created attachment 264739 [details] [review]
0001-Home-End-generate-wrong-control-sequences.patch

more better description

Created attachment 264740 [details] [review]
0001-Home-End-generate-wrong-control-sequences.patch

v3: drop comments in sources

This patch works for me. I've tried it with vte3-0.34.9-1.fc20 in Fedora 20.

Egmont, you seem to know these things best.  Can you take a look?

I hardly know anything about terminfo related stuff, it's always been a mystery to me. Anyway, I'll try to take a look as time permits, probably in January. Please ping me in about a month should I forget about it, the patch changes behavior so is a good candidate for a new major release but not for minor ones.

The original concern seems to be valid, vte indeed generates different escape than other terminals and ignores modifiers. However, home/end work for me in mc, I'm not sure how/why.

It's indeed true that in application mode (like mc, where there's no scrollback) certain keys generate different sequences, and I'm really not sure how to conveniently test them, perhaps stracing vte is the easiest...

A quick note: increasing cursor width is something that's always been bugging me, I'm using I-beam with my own patch to make it 2px wide instead of 1px, I was just too lazy to file a bug, but I'm all for it -- but it should be a separate patch with a separate bug record, not piggybacked on something completely irrelevant.

(In reply to comment #33)
> I hardly know anything about terminfo related stuff, it's always been a mystery
> to me. Anyway, I'll try to take a look as time permits, probably in January.
> Please ping me in about a month should I forget about it, the patch changes
> behavior so is a good candidate for a new major release but not for minor ones.
will do.
> The original concern seems to be valid, vte indeed generates different escape
> than other terminals and ignores modifiers. However, home/end work for me in
> mc, I'm not sure how/why.
> 
> It's indeed true that in application mode (like mc, where there's no
> scrollback) certain keys generate different sequences, and I'm really not sure
> how to conveniently test them, perhaps stracing vte is the easiest...
you can run gnome-terminal, run vim, write some strings and test ^Home and ^End.
It doesn't work now. W/ this patch it works again.
P.S. ^ == Ctrl
> A quick note: increasing cursor width is something that's always been bugging
> me, I'm using I-beam with my own patch to make it 2px wide instead of 1px, I
> was just too lazy to file a bug, but I'm all for it -- but it should be a
> separate patch with a separate bug record, not piggybacked on something
> completely irrelevant.

Hi Egmont,

It could be the case that it works for you in mc, because we query the modifiers using X, when possible. You can check by disabling it explicitly and see if it still works.

Z.

Thanks Yury for the reminder, it suddenly didn't occur to me that mc does this, but indeed it does. I'll take care of testing mc both with and without X11 support.

F1-F4 with modifiers also generate different sequences in vte and xterm.

First, I'm trying to understand what xterm does, and which subset of that we'd like to implement. The doc (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html) is not always clear to me or doesn't seem to always match the behavior. I'll take xterm-300's behavior as the reference.

Stuff I believe we shouldn't care about: alt/meta related resources, numLock resource (along with DECSET 1035), oldXtermFKeys, non-PC style (vt220, vt52, sun, hp) function keys.

Stuff we should care about: apparently there are two orthogonal internal states that influence the sequences generated by keys:

- Application Cursor Keys (\e[?1h) vs Normal Cursor Keys (\e[?1l). This modifies the behavior of seven symbols (most of which are accessible by two physical keys when numlock is off): Home, End, Left, Right, Up, Down and "Begin" (numpad 5 when numlock is off, whatever it is supposed to mean). When Application Cursor Keys mode is enabled, the escapes begin with \eO rather than \e[.

- Application Keypad (\e=) vs Normal Keypad (\e>). This modifies the behavior of the four numpad math operators only (although the doc says it should modify the behavior of space, tab and enter too). When Application Keypad mode is enabled, these keys generate escape sequences, rather than plain ascii characters.

There's also the external state: the NumLock modifier. Whenever NumLock is enabled, numpad keys ignore both of the internal states mentioned above, and just emit the corresponding digit or ./*-+ symbol. Standalone Home/End keys still depend on App/Normal Cursor Keys mode. Whenever NumLock is disabled, the ten numpad keys: up, down, left, right, home, end, pgup, pgdn, insert, delete always produce the same escapes as their standalone key counterparts.

*** Bug 425462 has been marked as a duplicate of this bug. ***

Igor, I've tried your patch but unfortunately I really don't get what you're doing.

Following the comments in your patch:

1. ^[OH vs ^[[H as per the original report, you didn't fix it.

2. Modifiers: these ones are fixed.

The bullet points starting with "-" characters:

- 1st, 2nd and 4th: Unfortunately I don't understand their descriptions - could you maybe describe them like "press this and that, previously it did foo, but now it does bar"?

- 5th and 6th: They change the behavior in ways incompatible with any other terminal emulator for the benefit of one particular application, likely breaking many others. Clearly unacceptable for inclusion in mainstream.

- 7th: Irrelevant to the current bugreport.

Created attachment 265276 [details] [review]
Fix F1-F4 with modifiers

Created attachment 265277 [details] [review]
Fix numpad /*-+ with modifiers

Created attachment 265278 [details] [review]
Fix Home and End, with and without modifiers

Created attachment 265279 [details] [review]
Fix Numpad 5 with modifiers

I hope these patches make vte generate the same escapes as XTerm, whatever the state of the Application/Normal Cursor Mode flag, whatever the state of the Application Keypad flag, and whatever the status of NumLock is.

I didn't pay attention to the non-default emulation modes (vt220 and such), I didn't spend time figuring out how to enable them.

There's one difference I'm aware of: with NumLock enabled, pressing Shift + numpad 1, 3, 7 or 9 generate escapes in XTerm, while scroll the buffer in VTE. I'd be happy to live with it.

I think there's one nontrivial part that deserves explanation. In the F1-F4 patch I add a separate entry for each modifier. This is because OR-ing them would require *all* of them to be pressed, but there we need to catch when *any* of them are active. Building up an infrastructure for this would have been overkill. When multiple modifiers are pressed at the same time, one of the branches will match and the code that encodes the modifiers will properly encode all of them, so it's okay.

(In reply to comment #40)
> Igor, I've tried your patch but unfortunately I really don't get what you're
> doing.
This isn't my patch. I've got old patch and rebase it, because author unresponsive.

Review of attachment 265279 [details] [review]:

Tested-by: Igor Gnatenko <i.gnatenko@gnome.org>

Review of attachment 265278 [details] [review]:

Tested-by: Igor Gnatenko <i.gnatenko@gnome.org>

Review of attachment 265277 [details] [review]:

Tested-by: Igor Gnatenko <i.gnatenko@gnome.org>

Review of attachment 265276 [details] [review]:

Tested-by: Igor Gnatenko <i.gnatenko@gnome.org>

whoops.. my mail is ignatenko@gnome.org ;)

I've tested this patch-set and it fixes all problems.

(In reply to comment #47)
> This isn't my patch. I've got old patch and rebase it, because author
> unresponsive.

Indeed, these were created by Alexej, probably based on Klaus's patch. Sorry for that.

Thanks for testing my patches! :)

In the mean time I also got a reply from Thomas E. Dickey (author of XTerm), basically boiling down to:

- ctlseqs.txt might be slightly out of date or incomplete, XTerm's actual behavior should be the reference.

- F1..F4 indeed switch to a completely different escape upon pressing any modifier.

- Most escape sequences switch to SS3 prefix on Application mode, but revert to CSI when a modifier is pressed. Numpad math operators are different, they get the modifiers with SS3.

- The story is more complicated than I stated above in comment 38, e.g. there are modifyCursorKeys and modifyFunctionKeys resources that also influence the behavior, but I don't think we should try to mimic all possible configurations of XTerm.

(Unrelated note: the cursor width, which Alexej tried to change in his patch, can be configured dynamically as per bug 586950 comment 17.)

*** Bug 157448 has been marked as a duplicate of this bug. ***

Fixed in 0-36, keeping open for vte-next.

Excellent work, Egmont, and highly appreciated!

Thanks Egmont.

Egmont, thank you! ;)

Don't forget close bug ;)

*** Bug 310305 has been marked as a duplicate of this bug. ***

*** Bug 674216 has been marked as a duplicate of this bug. ***

Hmm. I still get different behaviour in vte master compared to xterm 303 for the keypad keys:

key:     vte:    xterm:
KP Home: ^[[1~   ^[[H
KP End:  ^[[4~   ^[[F

I get H and F in vte. Could the difference come from terminfo maybe?

Are you testing by a simple "cat", or something more complicated? There might be a numpad mode which changes the escape (although should do it consistently with xterm).

Just using cat. Numlock is off.

keymap.c _vte_keymap_GDK_Home (and _End): which of those lines actually work for you? Change the escape sequence and see if it actually changes. For me it's the cursor_default lines that win with their hardcoded H/F. For you it could be the hardcoded 1~/4~ or via terminfo hk/@7.

I don't quite understand the process behind that selects the matching entry.

What's your TERM? Mine is xterm-256color.

Seems I've accidentally found the reason for the ^[[1~ vs. ^[[H discrepancy. I have a broken laptop that alters the keycodes when numlock is turned off, so even from the keypad I emit Home instead of KP_Home.

I can temporarily disable this bug by holding down Fn, in which case I also get ^[[1~.

Details: https://bugs.freedesktop.org/show_bug.cgi?id=78012

Created attachment 275319 [details] [review]
Fix Home/End on non-broken keyboards

I still have no clue what I'm doing, and no clue about vt220/notvt220/hp/sun. stuff. All I tested is the normal cursor mode (Home/End should generate ^[[F and ^[[H by default) and the application cursor mode (after executing echo -ne '\e[?1h', they should generate ^[OF and ^[OH), and it seems to work. Please verify.

Do we use that vt220/nonvt220 at all? Couldn't we just get rid of these vt220/hp/sun/etc fkey modes completely? I mean, if they are used anywhere, they are sure be quite broken by now.

It also looks that the whole mapping table deserves a big cleanup (maybe as part of bug 728900?). The three columns for the cursor, keypad and fkey values should hopefully each only influence a disjoint subset of the keys (numpad digits, numpad math operators and function keys respectively). I don't understand any of the keymap entry tables where more than one of these have a specific (rather than a match-all) entry.

I can't test the patch now, but did you make sure that the home and end
control sequences get properly prefixed when home or end are pressed
together with modifiers (Shift / Alt / Ctrl)?

That's what this bug report was initially about:
Ctrl / Alt / Shift were completely ignored,
Home and End always sent the same sequence, 
even when combined with modifiers.
I (and others) need Ctrl/Home etc. for special fuctionality,
which is impossible right now in all vte-based terminals.

That was fixed recently as part of this bug, and the new patch doesn't break it, I verified.

Re-opening. I had to revert the commit cbc73b6d40aa099643cce07400c31028cfaa7e8c because it caused a crash here, simply by starting vteapp, then pressing Ctrl-D to exit the shell:

Vte:ERROR:keymap.c:1080:_vte_keymap_map: assertion failed: ((fkey_mode == 0) || (fkey_mode == fkey_all))

Program received signal SIGABRT, Aborted.
0xb7fde424 in __kernel_vsyscall ()
(gdb) where

+ Trace 233582

Indeed. Note: --enable-debug is required for this crash. I'll take a look.

Could we please drop all these fkey_* stuff? (default, legacy, vt220, hp, sun; and we'd also need sco and termcap for full xterm parity)

It's a maintenance hell, just look at e.g. the definition of _vte_keymap_GDK_F1. It's encoding a 2x2x5 matrix (should be 2x2x7 for full xterm parity) for each and every single key (and even a single cell might have multiple entries, to try to look up termcap and then fall back to something hardcoded). I'm pretty sure I broke plenty of them (except fkey_default) with my recent changes and noone noticed :P Lack of unittests makes these tables pretty much unverifiable.

In xterm their availability is subject to configure flags, some being enabled, others being disabled by default. Konsole doesn't support these (although it lets you choose from some predefined keymaps and lets you create your own one). Putty, Terminology, St, Urxvt don't seem to support these either.

Without them, we'd only have a 2x2 matrix for each key which is easy to verify.

I'm happy to do this if you approve.

Created attachment 276464 [details]
escapes.sh shell script to print almost all escape sequences

I created a script that dumps the keycodes generated by xterm or vte. It does it by synthesising keypresses, so you should leave it running for about 3 minutes without touching the keyboard.

The output (attached) reveals that the normal fkey mode is pretty much okay, KP_Home/KP_End are the only remaining serious issue. The other fkey modes are quite off from xterm, probably a good reason to drop them.

After cleaning up, this script could be put in git. One remaining TODO: we could pass the window id to xdotool, but that'd require vteapp to set $WINDOWID.

Created attachment 276465 [details]
current vte escape sequences

Created attachment 276466 [details]
current xterm escape sequences

Created attachment 276538 [details] [review]
Fix Home/End on non-broken keyboards, take 2

This one really fixes keypad home/end. This time I've verified with the script :) so I'm committing right away.

Only the default fkey mode is fixed, vt220 is unchanged (correct), hp/sun/legacy were broken anyways and now they are still broken in a slightly different way.

Created attachment 276539 [details]
current vte escape sequences (after comment 77)

Escape sequences of the "default" kbd mode should be okay now.

Removal of non-default kbd modes is continued in bug 730137.

(In reply to comment #76)
> Created an attachment (id=276466) [details]
> current xterm escape sequences

Any plan to add support for xterm's modifyOtherKeys=2 key bindings?
Those are very useful...

Nope, no plans, sorry – at least not from me. I'd even wish to eliminate some of the rarely used features (like sun/hp/etc. function keys), not even add a new one.

If you have good reasons and you'd like to convince us, please open a new enhancement request, cc me, and tell us which applications and how would benefit from this. I still don't promise anything, but at least we won't forget about the request. Thanks.

Could we please have that committed also to vte 2.x?

Both privately and at our university, we use xfce, which is gtk 2.x.
Moreover, the primary editor here is geany,
which also uses gtk 2's vte for its integrated terminal.

I don't think so. vte 2.x is unmaintained and likely contains unfixed security bugs, so anything that prolongs its use should be discouraged. If xfce still depends on it, it's them that should step up to maintain it...

*** Bug 763190 has been marked as a duplicate of this bug. ***