GNOME Bugzilla – Bug 425462
function keys don't work in gnome-terminal
Last modified: 2014-01-03 18:09:14 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/96676 "Binary package hint: gnome-terminal After upgrading from Edgy to Feisty, gnome-terminal started to generate "wrong" sequences when pressing Shift/Alt/Ctrl-F1..F4 keys, and some other (like Shift-Arrows). In particular, it generates: Shift...Alt.....Ctrl F1 \EO1;2P \EO1;3P \EO1;5P F2 \EO1;2Q \EO1;3Q \EO1;5Q F3 \EO1;2R \EO1;3R \EO1;5R F4 \EO1;2S \EO1;3S \EO1;5S while it should: Shift.Alt...Ctrl F1 \EO2P \EO3P \EO5P F2 \EO2Q \EO3Q \EO5Q F3 \EO2R \EO3R \EO5R F4 \EO2S \EO3S \EO5S according to the output of the infocmp command (TERM is set to xterm here, by default). The second ("correct") variant of sequences is also exactly what happens in the Edgy installation on another computer. It looks like 1; gets inserted into the middle of the sequence for these function keys and also into the middle of sequences for combinations like Shift-Up/Down/Left/Right. As a result, it's not possible anymore to e.g. create a new file using Shift-F4 in Midnight commander, or to select text in its built-in editor using Shift+Arrows. By the way, the xterm application both in Edgy and Feisty generates sequences from the first table (i.e. with 1; inserted), but I found how to change it by editing xterm resources (/etc/X11/app-defaults/XTerm-color), which didn't influence gnome-terminal though. It also didn't completely restore the normal behavior of Midnight Commander (Shift-F1..F4 started to work but other function keys stopped to work properly). It looks like these problems in xterm and in gnome-terminal have a common root. Also, I tried to alter the xterm definition in terminfo by replacing sequences from the second table with ones from the first one. It also worked, but again, only for those F1..F4 keys, and broke recognition of other function keys. Anyway, I don't think that changing the xterm definition is a correct way to go, because what is in terminfo by default seems to be a kind of standard nowadays (at least for common keys and combinations). dmik@ubuntu:~$ dpkg -s gnome-terminal Package: gnome-terminal Status: install ok installed Priority: optional Section: gnome Installed-Size: 432 Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com> Architecture: i386 Version: 2.18.0-0ubuntu1 Replaces: gnome-terminal2 Provides: x-terminal-emulator ..."
confirmed. Same problem.
i think this belongs to vte rather than gnome-terminal, and it appears to not be a bug in them, anyway. See my comments on Ubuntu bug #96676, linked in the original bug report.
Chris, Mariano, can you check the patch here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232373#c5
That patch certainly clears up the ctrl-arrow mishandling in vim, but does not affect the esc-codes sent for the modified function keys. Instead of applying that patch, switching between the «match Xterm» and «match expectations» alternates improves vim and the function key sequences. So the open question is under what circumstances is it incorrect?
Created attachment 87780 [details] [review] Flip the modfiier branches
If vte is an XTerm emulator, it is incorrect to behave differently from Xterm, is it not?
xterm / aterm behaves correct. Only vte based terminals (gnome, xfce) are broken.
for me, Xterm produces Ctrl+Up - ^[[1;5A Ctrl+Dn - ^[[1;5B Ctrl+Rt - ^[[1;5C Ctrl+Lt - ^[[1;5D gnome-terminal produces Ctrl+Up - ^[[1;5A Ctrl+Dn - ^[[1;5B Ctrl+Rt - ^[[1;5C Ctrl+Lt - ^[[1;5D This indicates to me, as do the comments in the code, that XTerm's behavior changed, and then vte's behavior changed, and vim (and possibly other apps) does not understand that behavior (yet)
Created attachment 87833 [details] [review] Update the keymaps. This patch converts the SS3 code to CSI for the default key mode for F1-F4 and the cursor keys. It generates correct behaviour wrt xterm for the od/vim test cases - though I haven't tried irsii. I'm a little hazy on just what is going on here though...
(In reply to comment #9) > Created an attachment (id=87833) [edit] > Update the keymaps. > > This patch converts the SS3 code to CSI for the default key mode for F1-F4 and > the cursor keys. It generates correct behaviour wrt xterm for the od/vim test > cases - though I haven't tried irsii. > Xterm actually seems to send SS3, but changes the way it adds the modifier for F1-F4. See http://cvsweb.xfree86.org/cvsweb/xc/programs/xterm/input.c?annotate=3.76 lines 669 through 667
Created attachment 87842 [details] [review] Add modifiers to F1-F4 as Xterm does Here's an patch that gets vte adding modifiers to F1-F4 the same way that Xterm does.
Also have a look at: http://bugzilla.gnome.org/show_bug.cgi?id=418732 Which seems to be similar/duplicate
The patches are to vte, so moving this bug there too.
Chris, do you know how to resolve this?
*** Bug 418732 has been marked as a duplicate of this bug. ***
are ctrl-pgup, ctrl-pgdown (not move to begin/end of document in mcedit) and shift-up, shift-down (not list output history (stdout)) the same bug?
Hi guys, just to let you know, this still affects Ubuntu, and has continued into 9.10. gnome-terminal version affected: 2.28.1-0ubuntu1
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.
Sorry, wrong bug. It seems that there are already at least 3 bugs filled concerning my issue... https://bugzilla.gnome.org/show_bug.cgi?id=599634 https://bugzilla.gnome.org/show_bug.cgi?id=600659 https://bugzilla.gnome.org/show_bug.cgi?id=612453 Copying my comments there...
Tadam!
I think this bug: https://bugzilla.gnome.org/show_bug.cgi?id=375652 is a subset of the present bug. If the present bug can be fixes, the bug above also can be closed. Hey, we are April 2011 by the way. Where is Behdad when we most need him :-( ...
Yury, I'm really sorry to disappoint you, but I can't find time to review these in the near future :(.
Is there anyone else maintaining vte / gnome-terminal dead or alive? :-( To me it looks like a very major and important piece of Gnome and it's amazing how little attention it actually gets.
Not really. It was unmaintained when I first touched it in 2006, and I got to own it. No one else has claimed it since. ChPe hacks on it sometimes, but typically more on the frontend and API side, not the emulation code. No one wants to touch the emulation code as it will break 10 other things if you don't know what exactly you are doing. And honestly I don't know exactly I'm doing myself when it comes to the dark parts of it like the ones affecting this one :(. My guess is that the root of all these problems lies into using our own obsolete termcap instead of relying on terminfo. I have not got the time to test that hypothesis though.
*** Bug 540179 has been marked as a duplicate of this bug. ***
Bug 600659 seems to have more recent progress on this, so I recommend let's continue there. *** This bug has been marked as a duplicate of bug 600659 ***