After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 375652 - unmappable keys / missing generic key-remapping method
unmappable keys / missing generic key-remapping method
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on: 399057
Blocks:
 
 
Reported: 2006-11-15 19:11 UTC by samo
Modified: 2021-06-10 13:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description samo 2006-11-15 19:11:21 UTC
using libvte, i cannot in any way get ctrl-home and ctrl-end or ctrl-tab
through to the shell inside (and have them different from plain home/end/tab). 

- there's no libXt so one cannot use Xresource/xrdb translation, like xterm
- gtkrc binding does not work as u override key-press which is not accessible from there - only things like gtkTextEntry's insert-at-cursor

so the last resort left is to hack the source - but IMO this is not good style.

- the way of checking keymap/entries does not allow to have ctrl-home mapping auto-produced from home's one in same way as ctrl-F5 from F5 is.
- so here a patch: but this is using my own mappings... hardcoded.

IMO linking (optionaly) a libXt (or whatever) and having vte*translation: entry as X-resource will be easiest to do without breaking anything. All else doesn't seem any good. Or maybe gtk stuff but i dont really think so.

--- org/vte-0.14.1/src/keymap.c    2006-08-31 22:56:44.000000000 +0300
+++ src/keymap.c    2006-11-15 20:50:08.000000000 +0200
@@ -123,6 +123,8 @@
    /* Alt+Tab = Esc+Tab */
    {cursor_all, keypad_all, fkey_all,
     VTE_META_MASK, _VTE_CAP_ESC "\t", -1, X_NULL},
+    //ctrl-tab
+   {cursor_all, keypad_all, fkey_all,  GDK_CONTROL_MASK, _VTE_CAP_ESC "{t", -1, X_NULL},
    /* Regular tab. */
    {cursor_all, keypad_all, fkey_all,
     0, X_NULL, 0, "ta"},
@@ -208,14 +210,17 @@
 static const struct _vte_keymap_entry _vte_keymap_GDK_Home[] = {
+   {cursor_all, keypad_all, fkey_all,  GDK_CONTROL_MASK, _VTE_CAP_ESC "{h", -1, X_NULL},
    {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_all, 0, X_NULL, 0, X_NULL},
 };

 static const struct _vte_keymap_entry _vte_keymap_GDK_End[] = {
+   {cursor_all, keypad_all, fkey_all,  GDK_CONTROL_MASK, _VTE_CAP_ESC "{e", -1, X_NULL},
    {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"},
Comment 1 samo 2007-07-16 12:14:42 UTC
after 0.16, this is still same - ctrl-combinations are ignored.

xterm may or may not have these, but for xterm it does not matter - one can redefine _any_ sequence to do anything in xterm, via xrdb *xterm: override
and xterm is 30+years old now.

This is year 2007, and there are still keys on 101-keyboard unreachable... on something new.

IMO u can put some fabricated sequences, similar to the ctrl-del one (the plain sequence + ";5~", and voila.
of course it would be better if all these go into some config file, so at least mime the xterms flexibility.

ciao
Comment 2 David Fraser 2009-03-18 07:09:00 UTC
In Ubuntu as https://bugs.launchpad.net/vte/+bug/342436
Comment 3 Egmont Koblinger 2014-01-03 18:05:53 UTC
Addressing ctrl-home and ctrl-end is being worked on in bug 600659.

ctrl-tab, or a generic rebinding framework won't be addressed there, though.
Comment 4 GNOME Infrastructure Team 2021-06-10 13:34:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/1242.