function keys don't work in gnome-terminal

Sorry for the flood with spelling corrections, I should have guessed it will e-mail every single one to subscribers :)

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=425462

confirmed. Happened after upgrading to feisty.

Is this definitely a problem with gnome-terminal, given that xterm also generates these sequences?

Alex, I've tried to downgrade gnome-terminal to 2.16.1-0ubuntu1 in Feisty and nothing has changed. It means that the problem is indeed not (entirely) in gnome-terminal itself but maybe somewhere else in GNOME -- the thing is that gnome-terminal is where it can be clearly observed. Anyway, I still have an Edgy machine nearby where gnome-terminal 2.16.1 doesn't show the above problems (but xterm still does), and if you need me to test/check something please ask.

This looks to be a problem with vte changing to match XTerm's behaviour, and possibly XTerm not matching how terminfo thinks it behaves.

http://svn.gnome.org/viewcvs/vte/trunk/src/keymap.c?r1=1341&r2=1391 shows the change.

It looks like the distinction is there to differentiate F13-F16 from Shift-F1 through Shift-F4. I don't understand the code well enough to see why it only applies to F1-F4 and not F5-F12.

oh, and according to the comment on the change in question, it was done to fix gnome bug #337252, http://bugzilla.gnome.org/show_bug.cgi?id=337252

Of course, since vte is an xterm emulator, that means that doing what xterm does is 100% correct.

Thus the fault lies either with the terminfo database for claiming that Shift-F1 is F13 is \EO2P or with MC for thinking that Shift-F1 is F13.

This also affects xterm - same behavior as described for gnome-terminal

Adding to ncurses since the terminfo xterm definition doesn't match what xterm actually does.

Alex, Izzy, I'm not sure where you get the idea that xterm should generate those sequences. infocmp gives \EO5P for "function key 25", not for "control-function key 1". Infocmp does not and has never had a mechanism for specifying modifiers to special keys. It looks to me that MC is in the wrong.

I'll say it again, there is no mechanism for ncurses to handle special keys with modifiers; it's an xterm extension that various terminals emulate. It is thus impossible for xterm's infocmp database to "lie" about them.

Micah,

I'm afraid I must disappoint you. The entire problem started (for me) with Feisty and only appears when working locally. When I log in via ssh (i.e. not Ubuntu xterm, but e.g. RHEL4), everything works as expected: Shift-F4 opens a new file to edit. If it was mc causing problems, I would expect the very same problems there as well. Moreover, the same problem is reported for vim as well (I didn't add that here, because I didn't verify). So it is very unlikely that mc is the "troublemaker".

One more "evidence" is: Simply open xterm without starting anything, press the Shift key and tap all function keys one after the other. You will notice, that the reaction on F1..F4 is very different than F5+: F1..F4 simply cause a beep and display one upper-case character (P to S), while everything above that displays ";2~" (also with a beep) - which shows me that there must be something in common to F1..F4 which is different from the others.

Izzy, the second paragraph you wrote is rather uninformative. Many of the characters being generated are being stripped out, using the method you've described. Use "cat" instead.

Note that for many terminals, the sequences generated will depend greatly upon whether the terminal is in "keypad transmit" mode, which most applications that expect to use special keys will set. The sequences for special keys that are described in the terminfo database _only_ apply to behavior when "keypad transmit" mode is activated (when available); it does not describe what the sequences should look like when that mode is not in effect. The best way to see what they look like when "keypad transmit" mode is enabled, is to use the command "tput smkx; cat; tput rmkx" to test the typing.

There is nothing particularly special about F1..F4 compared with F5..., they simply generate different sequences (which are both documented correctly in terminfo).

Xterm's behavior for generating control sequences have _not_ changed recently; gnome-terminal's (and xfce4-terminal's) on the other hand, have (and are broken). And, as I've said, there is no mechanism for terminfo to describe control+<special key>, and thus, no way for xterm to break it.

For much, much more info about the problem in gnome-terminal, see bug 89660.

Micah, since the purpose of terminfo is to recognize what xterm does, it seems to me that suggesting that xterm should follow what terminfo says it does is putting the cart before the horse. terminfo doesn't describe what xterm should do, it (should) describe what xterm *does*.

Of course, it is also possible that the change in xterm's behaviour was unintentional and therefore a bug.

MC/vim/irssi are definitely not at fault, as they simply rely on ncurses to tell them that a function key has been hit.

Also, comments on gnome's bug #337252 suggest that xterm's behaviour *did* change [somewhat] recently:
http://bugzilla.gnome.org/show_bug.cgi?id=337252#c1
http://bugzilla.gnome.org/show_bug.cgi?id=337252#c4
http://bugzilla.gnome.org/show_bug.cgi?id=337252#c9

«Micah, since the purpose of terminfo is to recognize what xterm does, it seems to me that suggesting that xterm should follow what terminfo says it does is putting the cart before the horse. terminfo doesn't describe what xterm should do, it (should) describe what xterm *does*.»

Xterm does, in fact, do what terminfo says. That was my whole point.

There is also, additionally, functionality that xterm does, that is not (and cannot currently be, and has not ever been) described by terminfo. This includes the control-<special key> stuff.

None of MC, vim, nor irssi rely on ncurses to tell them anything about when a function key *plus modifier* has been hit, because, as I've said, ncurses is not capable of telling them this. In the case of vim, at least, vim specifically checks the TERM variable to see if it's an xterm or xterm-clone, and in that case listens for specific control sequences (that are not, and cannot currently be, tracked by terminfo). Again, see bug 89660.

Regardless of whether xterm changed relatively recently, which I haven't had a chance to confirm yet; gnome-terminal has definitely changed in a way that breaks with any sequence xterm has used, either past or present.

by my understanding, xterm is intended to produce F13-F24 for Shift+F1-Shift+F12, F25-F36 for Ctrl+F1-Ctrl+F12, etc.

This is supported by http://webcvs.freedesktop.org/xorg/xc/programs/xterm/terminfo?revision=1.5&view=markup
as well as http://aperiodic.net/phil/archives/Geekery/term-function-keys.html

If that's true, then xterm does not do what terminfo says; i.e. it does not produce kf25 for ctrl+F1.

Am I incorrect in that understanding?

Another file that supports my understanding: debian's (and therefore presumably Ubuntu's) own xterm terminfo file from ncurses-base, includes the comment:

# Function keys with modifiers (Sun/PC):
# -------------------------------------
# Shift-Fx - kf{12+x}
# Control-Fx - kf{24+x}
# Shift-Control-Fx - kf{36+x}

Okay, thanks Alex, that clarifies things quite a lot. I guess Xterm and its sisters have repurposed the kfX strings. It might help for terminfo(5) to clarify this situation (even though it really isn't ncurses' responsibility to do so, since that's not the original meaning of those names; still, it does briefly address XTerm/DEC mouse handling).

What I've said up until now actually does apply to the other special keys (such as cursor keys), though, but that's irrelevant to this bug.

Ah, I see your point about the other special keys (cursor in particular)

there's cuu1, cuf1, cud1, and cub1...but shifted variants only for left and right (kLFT and kRIT); and no control variants whatsoever. And this all without getting into alt/meta/super variants... ;-)

Did any terminal ever actually have 64 function keys, as the existence of kf0-kf63 suggests?

> Did any terminal ever actually have 64 function keys, as the existence
> of kf0-kf63 suggests?

I doubt it. And I had been wondering about that. :)

Seems to me, though, if terminfo has 'em in there _specifically_ for
usages like xterm's, they're without excuse for not saying something
about how they tend to be used. :p

Instead of fighting for who's fault it is: Is it somehow likely that this will be fixed in the near future? I guess the "standard user" is not interested in the fact whether the bug is because of ncurses, xterm or whatever. To me it is completely irrelevant whether xterm follows the rules described by terminfo, or terminfo describes the behavior of xterm - as long as the information matches correctly (which is obviously not the case at the moment). And I think we all agree that the current behavior is not what it should be. The version of mc is still 4.6.1 as it already has been on Dapper, so changes here are unlikely (and, as I pointed out in my last post, see #12 above) it works fine when accessed remotely via ssh from a different system (in my case, RHEL4 or CentOS 4.5 to be more precise). And it is very unlikely that a bunch of apps broke the same thing in the same manner (vim and irsii mentioned here explicitely). So it must be some underlying thing.
From the sources I found on that issue at least to me it looks quite clear, that only F1..F4 are affected (and in mc, for me these seem the only broken keys as far as I can tell by now). Since xterm and gnome-terminal (and possibly some other terms and apps as well) seem affected, it may be some underlying library or the like. Is it possible to locate the change - and how could we possibly help locating?

Wasn't fighting for whose fault it was; was "fighting" whether it was a really bug, and whether infocmp's output really was meant to describe modified function keys. Now that that's been established, I think the change should be relatively straightforward; assuming xterm has changed its behavior _intentionally_, the terminfo database needs to change. Assuming gnome-terminal has changed compatibly, that should be all. If gnome-terminal is currently behaving differently from xterm, then gnome-terminal would need to stop claiming to be xterm ^_^

As I mentioned, gnome-terminal _has_ changed incompatibly wrt to xterm, in its handling of modified cursor keys and the like. AFAICT, this was an unintentional change, however, and so the fix needs to be made in gnome-terminal. And that's a separate bug.

A brief discussion with upstream would be good, to verify that the terminfo needs to change. Because, if the change was intentional, it seems like they should have updated the terminfo in the X source as well; but the link Alex gave shows a terminfo with still-broken control sequences.

OK - sounds like progress, we were just clearing up things and now the *issue* is clear. Agree with you we need to check which package needs the corrections: Whether xterm behaves correctly (and terminfo needs to be fixed), or xterm is broken (which means xterm, gnome-terminal etc. need to be fixed). The easiest way would be a fix to terminfo. Since I'm not so familiar with this: Could someone post a "work-around" to "correct" terminfo until the final decision is made and the fix available? Guess it's just a few lines somewhere in /usr/share/terminfo/x/xterm, and some call to merge the changes?

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:
From http://invisible-island.net/xterm/ctlseqs/ctlseqs.html:
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

Agree: gnome-terminal has never emulated all of xterm's control sequences, and it is unlikely
that it ever will. That's why there is a separate terminfo entry "gnome" to address its actual
behavior. Set $TERM to "gnome" and report discrepancies there.

For instance, the comment about gnome's bug #337252 points to a change in xterm 5 years ago.
That's not recent.

By the way - to get correct information (rather than the miscellany of 2-3 year old secondary sources,
you might look at the xterm source itself. gnome-terminal developers do...

First it is very funny: Half a year just pointing at each other saying "There's the problem, not here!". :-(

@Thomas Dickey goes Second:
===[ cut here ]===
izzy@nebo:~$ echo $TERM
gnome
izzy@nebo:~$ mc
Unknown terminal: gnome
Check the TERM environment variable.
Also make sure that the terminal is defined in the terminfo database.
Alternatively, set the TERMCAP environment variable to the desired
termcap entry.
izzy@nebo:~$
===[ end quote ]===
So much about setting TERM=gnome - and here's your report.

Honestly: Does anybody at least know a work-around for this? It's pretty annoying... Shift-F1 to Shift-F4 are completely unusable - regardless whether one uses xterm or gnome terminal. Konsole also, even if it simply "eats" the keystrokes (without displaying anything).

On Sun, Aug 05, 2007 at 08:58:45PM -0000, Izzy wrote:
> First it is very funny: Half a year just pointing at each other saying
> "There's the problem, not here!". :-(
>
> @Thomas Dickey goes Second:
> ===[ cut here ]===
> izzy@nebo:~$ echo $TERM
> gnome
> izzy@nebo:~$ mc
> Unknown terminal: gnome
> Check the TERM environment variable.
> Also make sure that the terminal is defined in the terminfo database.
> Alternatively, set the TERMCAP environment variable to the desired
> termcap entry.

hmm - yes. It's a shame about the termcap package - hasn't been maintained for
several years. That's using a file that was last updated in March 2000. I
added the gnome entry late in 1999 - shortly after ncurses 5.0.

Eric Raymond's file is mostly (aside from reordering the entries to assert
"creative" input, and changing the version number) a copy of the ncurses 5.0
file with less than 500 lines added. At best it's a nuisance.

> izzy@nebo:~$
> ===[ end quote ]===
> So much about setting TERM=gnome - and here's your report.

See
 ftp://invisible-island.net/ncurses/termcap.src.gz

for an authentic up-to-date termcap source.

(report bugs - but don't waste time with things that were fixed long ago)

> Honestly: Does anybody at least know a work-around for this? It's pretty
> annoying... Shift-F1 to Shift-F4 are completely unusable - regardless
> whether one uses xterm or gnome terminal. Konsole also, even if it
> simply "eats" the keystrokes (without displaying anything).

( works for me ;-)

--
Thomas E. Dickey <email address hidden>
http://invisible-island.net
ftp://invisible-island.net

On Sun, Aug 05, 2007 at 08:58:45PM -0000, Izzy wrote:
> gnome
> izzy@nebo:~$ mc
> Unknown terminal: gnome
> Check the TERM environment variable.
> Also make sure that the terminal is defined in the terminfo database.
> Alternatively, set the TERMCAP environment variable to the desired
> termcap entry.

For reference, here's what a current "gnome" looks like in terminfo:

# Reconstructed via infocmp from file: /usr/local/ncurses/lib/terminfo/g/gnome
gnome|GNOME Terminal,
 am, bce, mir, msgr, xenl,
 colors#8, cols#80, it#8, lines#24, pairs#64,
 acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
 bel=^G, bold=\E[1m, civis=\E[?25l, clear=\E[H\E[2J,
 cnorm=\E[?25h, cr=^M, csr=\E[%i%p1%d;%p2%dr,
 cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J,
 cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
 cuu=\E[%p1%dA, cuu1=\E[A, dch=\E[%p1%dP, dch1=\E[P,
 dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
 enacs=\E)0, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
 hpa=\E[%i%p1%dG, ht=^I, hts=\EH, il=\E[%p1%dL, il1=\E[L,
 ind=^J, is2=\E[m\E[?7h\E[4l\E>\E7\E[r\E[?1;3;4;6l\E8,
 kDC=\E[3;2~, kLFT=\EO2D, kRIT=\EO2C, kb2=\E[E, kbs=\177,
 kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
 kdch1=\E[3~, kend=\EOF, kf1=\EOP, kf10=\E[21~, kf11=\E[23~,
 kf12=\E[24~, kf13=\EO2P, kf14=\EO2Q, kf15=\EO2R,
 kf16=\EO2S, kf17=\E[15;2~, kf18=\E[17;2~, kf19=\E[18;2~,
 kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~, kf22=\E[21;2~,
 kf23=\E[23;2~, kf24=\E[24;2~, kf25=\EO5P, kf26=\EO5Q,
 kf27=\EO5R, kf28=\EO5S, kf29=\E[15;5~, kf3=\EOR,
 kf30=\E[17;5~, kf31=\E[18;5~, kf32=\E[19;5~,
 kf33=\E[20;5~, kf34=\E[21;5~, kf35=\E[23;5~,
 kf36=\E[24;5~, kf37=\EO6P, kf38=\EO6Q, kf39=\EO6R,
 kf4=\EOS, kf40=\EO6S, kf41=\E[15;6~, kf42=\E[17;6~,
 kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~,
 kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~, kf49=\EO3P,
 kf5=\E[15~, kf50=\EO3Q, kf51=\EO3R, kf52=\EO3S,
 kf53=\E[15;3~, kf54=\E[17;3~, kf55=\E[18;3~,
 kf56=\E[19;3~, kf57=\E[20;3~, kf58=\E[21;3~,
 kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~, kf61=\EO4P,
 kf62=\EO4Q, kf63=\EO4R, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
 kfnd=\E[1~, khome=\EOH, kich1=\E[2~, kmous=\E[M, knp=\E[6~,
 kpp=\E[5~, kslt=\E[4~, meml=\El, memu=\Em, op=\E[39;49m,
 rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O, rmam=\E[?7l,
 rmcup=\E[2J\E[?47l\E8, rmir=\E[4l, rmkx=\E[?1l\E>,
 rmso=\E[m, rmul=\E[m, rs1=\Ec,
 rs2=\E7\E[r\E8\E[m\E[?7h\E[!p\E[?1;3;4;6l\E[4l\E>\E[?1000l\E[?25h,
 sc=\E7, setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
 sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;m%?%p9%t\016%e\017%;,
 sgr0=\E[0m\017, smacs=^N, smam=\E[?7h, smcup=\E7\E[?47h,
 smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m,
 tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
 u8=\E[?%[;0123456789]c, u9=\E[c, vpa=\E[%i%p1%dd,

and in termcap - ignoring size limit:

# Reconstructed via infocmp from file: /usr/local/ncurses/lib/terminfo/g/gnome
gnome|GNOME Terminal:\
 :am:bs:mi:ms:ut:xn:\
 :Co#8:co#80:it#8:li#24:pa#64:\
 :#4=\EO2D:%i=\EO2C:*4=\E[3;2~:*6=\E[4~:@0=\E[1~:@7=\EOF:\
 :AB=\E[4%dm:AF=\E[3%dm:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:\
 :DO=\E[%dB:F1=\E[23~:F2=\E[24~:F3=\EO2P:F4=\EO2Q:F5=\EO2R:\
 :F6=\EO2S:F7=\E[15;2~:F8=\E[17;2~:F9=\E[18;2~:\
 :FA=\E[19;2~:FB=\E[20;2~:FC=\E[21;2~:FD=\E[23;2~:\
 :FE...

I just found out that the problem does *NOT* appear with konsole. Checking a bit deeper, it uses TERM=linux - setting TERM=xterm here breaks a few things again. The other way round (setting TERM=linux in a xterm session) is not helpful at all. Side-effect of TERM=linux is that you lose mouse support (at least as far as Midnight Commander is affected). So you have the choice of "mouse XOR keyboard working fine".

@Thomas Dickey: If you could send me the affected termcap files (and say where they belong to), I would try to replace mine (after a backup). If that solves the issue, we at least know how to work around the bug until it's solved (which I guess will not happen that soon - to be honest, I would even be surprised if it was solved in Gutsy).

On Tue, 14 Aug 2007, Izzy wrote:

> I just found out that the problem does *NOT* appear with konsole.

That's not unexpected, given the history of the feature.

I implemented the original flavor in (xterm of course)
  Patch #94 - 1999/3/27 - XFree86 3.9Pf
and made the change which seems to be the root of this discussion in
  Patch #167 - 2002/8/24 - XFree86 4.2.0
and documented/extended the permutations in
  Patch #216 - 2006/8/3
  Patch #223 - 2006/11/30

iirc, konsole is using the original flavor, while as noted, gnome-terminal
attempts to use the terminfo entry but reportedly is not associating
things in the same way that I setup for xterm.

Aside from unintentionally changing the default for the behavior that
corresponds to the modifyCursorKeys resource as noted for #223, I don't
_recall_ having changed anything in the terminfo which would be
incompatible - for xterm itself. gnome-terminal, of course, is expected
to work either way since it reads the terminal description.

> Checking a bit deeper, it uses TERM=linux - setting TERM=xterm here
> breaks a few things again. The other way round (setting TERM=linux in a
> xterm session) is not helpful at all. Side-effect of TERM=linux is that
> you lose mouse support (at least as far as Midnight Commander is
> affected). So you have the choice of "mouse XOR keyboard working fine".

Midnight Commander is probably linked with s-lang, which only looks for
"xterm" in $TERM to decide if the terminal supports mouse. ncurses
looks at the kmous capability (which is more reliable).

btw - the extra key-bindings for alt/shift/control modifiers in the
terminfo descriptions are invisible to s-lang, since it has its own
terminfo reader... (not really noticeable for Midnight Commander if
you're using the learn-keys feature).

> @Thomas Dickey: If you could send me the affected termcap files (and say
> where they belong to), I would try to replace mine (after a backup). If
> that solves the issue, we at least know how to work around the bug until
> it's solved (which I guess will not happen that soon - to be honest, I
> would even be surprised if it was solved in Gutsy).

I'm puzzled by the original description, which states that infocmp is
showing \EO rather than \E[ for the control sequence initiator, but am
guessing that Ubuntu is still assigning "xterm" to the 5-year-old version
of xterm. (While xterm can be configured to match this, that was changed
for a good reason, and it would be nice if we didn't have to deal with
antique bugs).

The way to construct a _terminfo_ entry (I thought Ubuntu is a repackager
of Debian...), is to make a text file such as

xterm|customized entry,
  use=xterm-xf86-v44,

and compile that with tic (noting that if you're not root, then it may
go to $HOME/.terminfo - a bad feature which was depcrecated long ago).

See also
  http://invisible-island.net/ncurses/ncurses.faq.html#unknown_term

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

arrow keys don't work in vi in an ssh session either

Can anyone please explain what exactly has to be done with termcap files in order to actually use them? TD is unreasonably terse which makes it very difficult to decipher the advice that he offers.

Please, most people have not had to deal with terminfo or tic before... the last time I saw a bug in a terminal definition it was back in the dark ages of termcap. We don't work with this stuff every day and really need to be told exactly what to do.

It's incredibly frustrating to watch people pointing fingers at each other, or debating whether this is really a bug like a bunch of pissy schoolgirls, please everybody if you're not going to bother fixing this problem, can you at least give me the information to fix this myself!?

Terminfo and tic are incredibly poorly documented to the point that hours of googling has failed to turn up a single example of an invocation of tic. Given the poor state of support and documentation can I suggest that ubuntu upgrade to /etc/termcap?

I'd like to second steviant's request. For a long time this bug forced me to use konsole instead of gnome-terminal, just for ability to press Shift+F4. Unfortunately with konsole Shift+Left/Shift+Right don't work (which work under gnome-terminal), so editing text files is not of much use. It's really annoying that I can get one part of a functionality with only one terminal and the other half only with other. :-/

I've just downloaded ncurses sources and finally found why Thomas Dickey's example didn't make sense (and didn't compile). There's no xterm-xf86-v44. Ubuntu actually uses xterm-debian. So the first attempt was like this:

$ cat >myxterm.ti
xterm|X11 terminal emulator with correct kf-sequences,
  kf13=\EO1;2P,
  kf14=\EO1;2Q,
  kf15=\EO1;2R,
  kf16=\EO1;2S,
  use=xterm-debian,
^D
$ tic myxterm.ti
$ mc

And then I figured that now Shift+F2 acts like Shift+F4. Either Midnight Commander expects kf14 to be Shift+F4 (which doesn't seem to be correct, I'll show later why), or something is fishy here. Now I made it like this:

$ cat >myxterm.ti
xterm|X11 terminal emulator with correct kf-sequences,
  kf11=\EO1;2P,
  kf12=\EO1;2Q,
  kf13=\EO1;2R,
  kf14=\EO1;2S,
  use=xterm-debian,
^D
$ tic myxterm.ti
$ mc

Now it works in mc, but it seems extremely, EXTREMELY, wrong to me.

What do I actually see when I run konsole and try pressing Shift+F1..F4?

$ cat
^[O2P^[O2Q^[O2R^[O2S
$ echo $TERM
xterm

Now, if you look at xterm+pcfkeys in ncurses-5.6+20070716/debian/xterm.ti you'll see that ^[O2S (Shift+F4) is mapped to kf16, yet when I press Shift+F4 in Midnight in konsole, it works correctly! So what's exactly happening? I clearly can't sanely map kf11...kf14 to be Shift+F1...F4 just for midnight (I assume something else will likely break then). How do I make Shift+F1...F4 work like they work in konsole?

Hmm... about xterm-xf86-v44 I apologize since now it is somehow working. :-/ I wonder why it didn't work a couple of months ago when I first tried that.

Also I just found that xterm sends slightly different codes for Shift+F1...F4, so this myxterm.ti is also for xterm:

xterm|X11 terminal emulator with correct kf-sequences,
 kf13=\EO1;2P,
 kf14=\EO1;2Q,
 kf15=\EO1;2R,
 kf16=\EO1;2S,
 kf13=\E[1;2P,
 kf14=\E[1;2Q,
 kf15=\E[1;2R,
 kf16=\E[1;2S,
 use=xterm-xf86-v44,

However Shift+F2 acts as Shift+F4 (in mc) in xterm too.

On Tue, 23 Oct 2007, Alexey Borzenkov wrote:

> Also I just found that xterm sends slightly different codes for
> Shift+F1...F4, so this myxterm.ti is also for xterm:
>
> xterm|X11 terminal emulator with correct kf-sequences,

This would be for xterm with modifyFunctionKeys:0

I made a list in xterm (duplicated in ncurses) called "xterm+pcf0".

> kf13=\EO1;2P,
> kf14=\EO1;2Q,
> kf15=\EO1;2R,
> kf16=\EO1;2S,

and this would be with modifyFunctionKeys:2

The corresponding list is called "xterm+pcf2", and corresponds to the
default settings.

The terminfo entries are built up in chunks to make it (relatively) simple
to patch the terminfo to reflect different preferences for
resource-settings.

> kf13=\E[1;2P,
> kf14=\E[1;2Q,
> kf15=\E[1;2R,
> kf16=\E[1;2S,

> use=xterm-xf86-v44,
>
> However Shift+F2 acts as Shift+F4 (in mc) in xterm too.

refer to

ftp://invisible-island.net/ncurses/terminfo.src.gz

which lists several of the chunks for xterm (not all combinations - there
are many).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

On Tue, 23 Oct 2007, Alexey Borzenkov wrote:

> I'd like to second steviant's request. For a long time this bug forced
> me to use konsole instead of gnome-terminal, just for ability to press
> Shift+F4. Unfortunately with konsole Shift+Left/Shift+Right don't work
> (which work under gnome-terminal), so editing text files is not of much
> use. It's really annoying that I can get one part of a functionality
> with only one terminal and the other half only with other. :-/

It sounds as if someone's trying to use TERM=xterm for all three,
which won't work.

> I've just downloaded ncurses sources and finally found why Thomas
> Dickey's example didn't make sense (and didn't compile). There's no
> xterm-xf86-v44. Ubuntu actually uses xterm-debian. So the first attempt

terminfo.src change history shows it's been in the sources a while:

# 2004-06-26
# * add mlterm -TD
# * add xterm-xf86-v44 -TD
# * modify xterm-new aka xterm-xfree86 to accommodate luit, which relies
# on G1 being used via an ISO-2022 escape sequence (report by
# Juliusz Chroboczek) -TD
# * add 'hurd' entry -TD
#
> was like this:
>
> $ cat >myxterm.ti
> xterm|X11 terminal emulator with correct kf-sequences,
> kf13=\EO1;2P,
> kf14=\EO1;2Q,
> kf15=\EO1;2R,
> kf16=\EO1;2S,
> use=xterm-debian,
> ^D
> $ tic myxterm.ti
> $ mc
>
> And then I figured that now Shift+F2 acts like Shift+F4. Either Midnight
> Commander expects kf14 to be Shift+F4 (which doesn't seem to be correct,
> I'll show later why), or something is fishy here. Now I made it like
> this:

Some packagers prefer to number shifted-f1 to shifted-f12 as F10-F22.
Some terminals implement this, some implement F13-F24 (hardcoded).

xterm has a resource-setting to select it -

        ctrlFKeys (class CtrlFKeys)
                In VT220 keyboard mode (see sunKeyboard resource),
                specifies the amount by which to shift F1-F12
                given a control modifier (CTRL). This allows you
                to generate key symbols for F10-F20 on a Sun/PC
                keyboard. The default is ``10'', which means that
                CTRL F1 generates the key symbol for F11.

which I added in 2000. The terminfo entries I maintain for ncurses and
xterm reflect the default resource settings. If you want to change the
resource settings, you need a new terminfo entry (suggest doing it with
a script ;-).

> $ cat >myxterm.ti
> xterm|X11 terminal emulator with correct kf-sequences,
> kf11=\EO1;2P,
> kf12=\EO1;2Q,
> kf13=\EO1;2R,
> kf14=\EO1;2S,
> use=xterm-debian,

by the way, Debian maintains "xterm-debian" - it won't be in ncurses
upstream, nor in xterm upstream.

> ^D
> $ tic myxterm.ti
> $ mc
>
> Now it works in mc, but it seems extremely, EXTREMELY, wrong to me.
>
> What do I actually see when I run konsole and try pressing Shift+F1..F4?
>
> $ cat
> ^[O2P^[O2Q^[O2R^[O2S
> $ echo $TERM
> xterm
>
> Now, if you look at xterm+pcfkeys in
> ncurses-5.6+20070716/debian/xterm.ti you'll see that ^[O2S (Shift+F4) is
> mapped to kf16, yet when I press Shift+F4 in Midnight in konsole, it
> works correctly! So what's exactly happening? I clearly can't sanely map
> kf11......

Thomas, I don't seem to understand you. I just grabbed and compiled terminfo.src you gave and while it helped with xterm (except that it's just like with my previous attempts, Shift+F2 starts a new file in mc instead of Shift+F4) it didn't work in gnome-terminal (because of \E[ and \EO difference I pointed before). However I just recompiled libvte with changing "#if 1" to "#if 0" and gnome-terminal now works correctly (Shift+F4 now starts a new file in mc, with original ubuntu terminfo, no other modifications were needed). The change in the source only affects addition of "1;" and shouldn't make any difference in regards to Shift+F2/Shift+F4 (since I didn't change any resources), should it? If it does then I'm clearly missing something big here and I'd like to know where I could read what this "1;" actually means at all?

P.S. I'm not affiliated with ubuntu/debian development yet (merely a "new" user who recently returned back to linux after moving to windows a decade ago), so I can't even suggest anything going or not going upstream. I'm just trying to understand what's going on here with this bug.

On Tue, 23 Oct 2007, Alexey Borzenkov wrote:

> Thomas, I don't seem to understand you. I just grabbed and compiled
> terminfo.src you gave and while it helped with xterm (except that it's
> just like with my previous attempts, Shift+F2 starts a new file in mc
> instead of Shift+F4) it didn't work in gnome-terminal (because of \E[
> and \EO difference I pointed before). However I just recompiled libvte

I don't use mc, but have read that it stores key-definitions per $TERM
with its learn-keys feature. That may be what's confusing it. Also,
recall that I pointed out that some terminals use different numbering
for the shift-F1 to F10 or F12.

gnome-terminal is a different problem since it hardcodes $TERM to "xterm"
and attempts to read function-key definitions from the termcap interface.
Note that I said "termcap" - iirc, it's only got one table. This makes it
do interesting (buggy) behavior for the shift/control cursor/function
keys, since it guesses incorrectly on the cases where they're not in
termcap.

It does sort-of work for the codes in termcap. (I haven't noticed any
mismatches for the common cases of TERM using tack).

> with changing "#if 1" to "#if 0" and gnome-terminal now works correctly

I'm not sure which "#if 1" you're talking about here.

> (Shift+F4 now starts a new file in mc, with original ubuntu terminfo, no
> other modifications were needed). The change in the source only affects
> addition of "1;" and shouldn't make any difference in regards to
> Shift+F2/Shift+F4 (since I didn't change any resources), should it? If
> it does then I'm clearly missing something big here and I'd like to know
> where I could read what this "1;" actually means at all?

you seem to be referring to here to something like
  \E[1;2A

The "1;" is the first parameter in the control sequence. In my first
version of function-key modifiers, I did something like
  \E[2A

but after some time someone pointed out that it violated the convention
that the cursor key strings could be interpreted the same as the
corresponding cursor movement controls. The first parameter for cursor
movements is a repeat-count. So I added a dummy parameter "1" to fix
that.

gnome-terminal and konsole copied the first version, did not adapt the
improved version. (xterm provides both, and more via the modifyXXX
resources). After some time, gnome-terminal was modified (unsure when -
neither GNOME nor KDE developers document things) to read the termcap.
So it sort-of works.

>
> P.S. I'm not affiliated with ubuntu/debian development yet (merely a
> "new" user who recently returned back to linux after moving to windows a
> decade ago), so I can't even suggest anything going or not going
> upstream. I'm just trying to understand what's going on here with this
> bug.
>
> --
> [feisty] function keys don't work in gnome-terminal
> https://bugs.launchpad.net/bugs/96676
> You received this bug notification because you are a direct subscriber
> of the bug.
>
>

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

> I don't use mc, but have read that it stores key-definitions per $TERM
> with its learn-keys feature. That may be what's confusing it.

God, you are right!! I was looking at config in my home directory and was already going to say that it's not like that, when an idea striked me that maybe there's some system-wide config. And yet is it, /etc/mc/mc.lib:

...
[terminal:xterm]
...
# Sequences below are for Konsole, which also sets TERM=xterm
kf11=\eO2P
kf12=\eO2Q
kf13=\eO2R
kf14=\eO2S
...

So that's why I'm seeing it working in an unexpected way when terminfo entries are correct! So for anyone interested, there are two choices:

1) recompile vte with this change reverted: http://svn.gnome.org/viewcvs/vte/trunk/src/keymap.c?r1=1341&r2=1391
2) create myxterm.ti like I displayed below (or grab full terminfo.src at invisible-island.net, mentioned earlier by Thomas), compile it with tic, then add appropriate entries to /etc/mc/mc.lib, using \e[1;2P...\e[1;2S for xterm and \eO1;2P...\eO1;2S for gnome-terminal (you can specify both). Sadly, if I'm not missing something, only one of these notations (xterm or gnome-terminal) can be specified in myxterm.ti file (infocmp and ncurses seem to use only one of them).

The problem with solution 1 is that xterm will still stay misunderstood on your system (though I'm not using xterm, thus I'm personally going with number 1 at the moment, to retain compatibility with konsole).

The problem with solution 2 is that xterm, gnome-terminal and konsole are all three mutually incompatible in this regard. You can make mc understand all three, but it's not going to be universal and might not work with other programs. :-/ Now, to me it seems that current vte behavior is a bug and should match xterm. And most of all konsole should do that too, or stop pretending to be xterm!

Below is an example of my final myxterm.ti:

xterm-kfpc-13-16-xterm|kf13..kf16 for xterm,
 kf13=\E[1;2P,
 kf14=\E[1;2Q,
 kf15=\E[1;2R,
 kf16=\E[1;2S,

xterm-kfpc-13-16-gterm|kf13..kf16 for gnome-terminal,
 kf13=\EO1;2P,
 kf14=\EO1;2Q,
 kf15=\EO1;2R,
 kf16=\EO1;2S,

xterm|X11 terminal emulator with correct kf-sequences,
 use=xterm-kfpc-13-16-xterm,
 use=xterm-debian,

Here you can choose between xterm and gnome-terminal in the use statement. Further comments are welcome, and I hope this will help workaround the problem for others too.

Just wanted to report that the problem disappeared for me after a dist-upgrade to Hardy (via Gutsy, of course). So maybe the bug is silently solved?

On Fri, 25 Jul 2008, Izzy wrote:

> Just wanted to report that the problem disappeared for me after a dist-
> upgrade to Hardy (via Gutsy, of course). So maybe the bug is silently
> solved?

No bug here - it's either a fix in gnome-terminal, or the application
using it, e.g., vim.

>
> --
> [feisty] function keys don't work in gnome-terminal
> https://bugs.launchpad.net/bugs/96676
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Must be a fix in some underlying libraries - for me it's not only solved in gnome-terminal, but in xterm as well (I only tested with the Midnight Commander). So if some more people can confirm it's gone, the maintainer maybe can close the bug as solved.

No, the bug is still present here (8.04). I.e. pressing F1, F2, F3 and F4 with modifiers still doesn't work and generates the same sequence as demonstrated in the description. Shift+Arrows work though.

I too still see this bug in 8.04.

Ooops - confirmed: With modifiers it still doesn't work neither in xterm nor in gnome-terminal. In konsole, however, everything is still fine...

At some point gnome-terminal changed its strings for modified function-keys. I documented those
in terminfo.src for ncurses 5.7 (they don't match xterm, of course).

Confirmed it's still an issue on Jaunty with xterm and gnome-terminal.

I also see that the modifyFunctionKeys:2 section of xterm's terminfo seems to be the default.

Looking at xterm's changelog, the default was changed to 2 in Patch #216 - 2006/8/3:
# change default resource modifyFunctionKeys to 2 to avoid sending SS3 with parameters (report by Kalle Olavi Niemitalo).

Ctrl-End also has a problem; it seems to produce exactly the same codes as End using showkey -s

David, that's really a separate issue and should get a separate report (but I can confirm the same behavior on Intrepid, though showkey doesn't work for me).

Indeed; filed bug 342436 - showkey only seems to work as root, which probably deserves another bug

Wow, I totally don't remember why I assigned myself to this bug.
I don't know what change needs to be done to solve this, so unassigning myself for now.

If anyone runs across a patch, idea for a fix, or whatever, feel free to re-assign this bug to me and outline what needs to be done. Meanwhile I'll stay subscribed to follow the progress.

I can confirm this.

$ lsb_release -rd
Description: Ubuntu jaunty (development branch)
Release: 9.04

Suggested fix: konsole. More options, and as a bonus all the friggin keys work (at least the ones I use anyway). I feel stupid using kde apps on a gnome desktop but even stoopider not being able to use all the keys on the keyboard.

That's at best a workaround, not a fix.

Think this was missed, as per Micah's comment, Invalidating ncurses package.

I can confirm that Karmic also affected.

tms@helios:~$ lsb_release -rd
Description: Ubuntu 9.10
Release: 9.10

Hope this will help to solve this: http://www.midnight-commander.org/ticket/386

I think the GNOME team may have given up on this, there's been no activity for 4 months, will update the GNOME bug so they know 9.10 is affected.

Please don't add the distro-series to the title. It implies the bug is specific to only that series, when that clearly isn't the case here (it also applies to Lucid)

Instead, you are welcomed to propose it for a given release.

On Fri, Jan 08, 2010 at 11:09:04PM -0000, Chris Coulson wrote:
> Please don't add the distro-series to the title. It implies the bug is
> specific to only that series, when that clearly isn't the case here (it
> also applies to Lucid)
>
> ** Summary changed:
>
> - [KARMIC] function keys don't work in gnome-terminal
> + function keys don't work in gnome-terminal
>
> --
> function keys don't work in gnome-terminal
> https://bugs.launchpad.net/bugs/96676
> You received this bug notification because you are a member of Ubuntu-X,
> which is subscribed to xterm in ubuntu.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-x-swat
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ubuntu-x-swat
> More help : https://help.launchpad.net/ListHelp

Once upon a time I back-tracked the problem, and it was somewhere really deep in

gnome/widgets/vte/src/keymap.c:_vte_keymap_key_add_key_modifiers -- it has an algorithm to hack function-key-codes, when SHIFT pressed, eg:

F1 = ESC O P
Shift+F1 = ESC [ O 1 ; 2 P

should be= ESC O 2 P (Shift + F11 = F13 -- (why not F11? dunno.))

It should be completely rewritten (nobody volunteered yet?), or a new terminal-type should be defined which is compatible with these sequences.

It could be something like this: http://web.axelero.hu/lzsiga/xterm-vte.sh

then in /usr/share/mc/mc.lib:

[terminal:xterm-vte]
copy=xterm
f11=\eO1;2P
f12=\eO1;2Q
f13=\eO1;2R
f14=\eO1;2S

and finally:
somewhere in .bashrc or else:

if [ x"$TERM" = x"xterm" ]; then export TERM="xterm-vte"; fi

A little addition: in my debian lenny Shift+F1 produces:

on tty: terminal=linux SF1=ESC[23~ infocmp=kf11 (my own setting)
on rxvt: terminal=rxvt SF1=ESC[23~ infocmp=kf11 (very good (for mc, at least))
on xterm: terminal=xterm SF1=ESC[1;2P infocmp=no such sequence!!!
on gnome-terminal: terminal=xterm SF1=ESC01;2P infocmp=no such sequence!!!
on gnome-terminal: terminal=xterm-vte SF1=ESC01;2P infocmp=kf13 (acceptable, if not intuitive)

My last suggestion (unconditionally change environment TERM from 'xterm' to 'xterm-vte') is a bit rude. How could I do it more nicely? If it were rxvt or xterm, it would be the simplest:

cat >> ~/.Xdefaults:
XTerm.termName=xterm-vte
Rxvt.termName=xterm-vte

xrdb ~/.Xdefaults

But alas, gnome-terminal seems to not use resources, it has an own XML-based configuration system.

I've never come across any useful documentation from the GNOME project.
Just stuff that is targeted at nontechnical end-users.

However, the simplest fix would be setting gnome-terminal's TERM variable
to "gnome", and handling the inevitable release-to-release nits with fixes
in the terminal database.

Ubuntu 10.04 - same sh*t happening!

The problem doesn't seem to solve itself; I'd suggest using xterm, rxvt or konsole.

I guess it won't solve by itself :)
On the other hand I need terminal with tabs... I use 5-6 consoles at a time with gnome. Using konsole under gnome does not seem right..
Installing konsole on purely gnome system means adding a ton of libs I don't need and this will eat my disk, crawl the system and slow system updates! nah ...

On Sun, Nov 7, 2010 at 8:06 PM, Vladimir Smolensky <<email address hidden>
> wrote:

> I guess it won't solve by itself :)
> On the other hand I need terminal with tabs... I use 5-6 consoles at a time
> with gnome. Using konsole under gnome does not seem right..
>

Maybe not, but the keys work correctly, so it may not "seem right" but it
works right ;-) The lack of annoying bugs that don't get fixed, is much less
too.

--
Hal

Hmm, looks like this bug is preventing tmux from receiving shift-F-keys correctly through gnome-terminal (on 11.04).

I've read through all of the comments, related bugs, etc, but I'm wondering: is there any way to fix this via termcap or without changing code for gnome-terminal? Otherwise xterm seems to be the only option for me to run emacs in a tmux session because many of my bindings are Ctrl-Fx.

Changing the code is the only way that I see.
However (since it's been several years) it doesn't appear to be a priority with the gnome developers.

vte 0.36 (gnome 3.12) changes the function keys to be compatible with Xterm.

That's helpful. However, Debian has 034 in testing,
which would tend to indicate that this bug could be closed in perhaps two years.