Ghostty issue w shifted Fn keys

[edrozenberg]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

GNU Midnight Commander 4.8.33
Built with GLib 2.82.4
Built with S-Lang 2.3.3 with terminfo database
Built with libssh2 1.11.1
With builtin editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems:
 cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, shell
Data types:
 char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;

Operating system

Darwin viper 24.6.0 Darwin Kernel Version 24.6.0: Mon Jan 19 22:01:58 PST 2026; root:xnu-11417.140.69.708.3~1/RELEASE_ARM64_T6041 arm64

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

• Run Ghostty terrminal app
• Doublecheck that TERM is set to TERM=xterm-ghostty (default value)
• Run mc
• Press Shift + F4, this will have the effect of Shift + F6

Expected behavior

For ex. Shift + F4 has the effect of Shift + F4

Actual behavior

For ex. Shift + F4 has the effect of Shift + F6

Additional context

When using the Ghostty terminal app (Mac/Linux), shifted Fn combos (for ex. Shift + F6) are interpreted as being a +2 Fn key. So in order to make mc perform a Shift + F6 (rename) the user needs to press Shift + F4.

This appears due to mc hardcoding various behaviors and not currently hardcoding the proper handling for Ghostty.

Issue reported to Ghostty here:
ghostty-org/ghostty#4681
ghostty-org/ghostty#3777

And responded by Ghostty as likely an mc issue with additional suggestions of related items:

mc/lib/tty/tty.c

Lines 113 to 125 in a37ae1c

	static const char *xterm_compatible_terminals[] = {
	"alacritty", //
	"contour", //
	"dtterm", //
	"Eterm", //
	"foot", //
	"konsole", //
	"rxvt", //
	"screen", //
	"tmux", //
	"xterm", //
	NULL,
	};

https://github.com/MidnightCommander/mc/blob/master/lib/tty/key.c#L318

#4762

I suspect the easiest short-term solution would be for mc to hardcode detection of the Ghostty terminal as being xterm-compatible.

[egmontkob]

There's a lot of ongoing work hereabouts, e.g. in #3254, #4632, #4317, #4512. I want to fix this reoccurring off-by-2 issue as much as possible for our forthcoming 4.9.0 release (even though terminfo is not fully our friend here. Let's say: I want to fix this issue once and for all for terminals with xterm-like keyboard escape sequences, which as far as I understand, ghostty is).

It will probably be desirable to add it to the hardcoded list of xterm-compatible terminals, as you've shown, along with a few others (putty occurs to me right now); although they should work purely via terminfo, too (we interpret terminfo's kf11 etc. with an off-by-10 semantics which I'm changing to off-by-12 which is way more commonly used, and is the one that matches xterm and alike terminals).

We should even consider loading our hardwired default escape sequences for all terminals, not just a few $TERM values we explicitly enabled.

[edrozenberg]

Thanks for the great response! I'm not an expert on terminal internals so don't follow all of it but it sounds great. Off-by-10 vs off-by-12 I only know my keyboards all have F1 -> F12 keys :).

If you need further feedback on any of this or Ghostty specifically feel free to post to Ghostty Discussions or the Discord, a bunch of the folks there are hardcore experts and on the leading edge imo of terminal advancement and modernization in all of its aspects -

https://github.com/ghostty-org/ghostty/discussions
https://discord.gg/ghostty

[egmontkob]

Thanks for the response!

Terminfo defines a flat list from kf1 to up to kf63, but knows nothing about modifiers. In the terminfo description, for most terminals kf13 defines what Shift+F1 sends, kf14 defines Shift+F2 etc. (off-by-12), but for some terminals kf11 defines Shift+F1 etc. (off-by-10), we have no chance of figuring out which one's the case other than having some hardcoded stuff. (The Linux console is even worse: there loadkeys or lack thereof might set up the keys this way or that way, so we can't even detect based on $TERM.)

There's a lot of juicy details in the linked bugs if you feel like reading them :)

I myself am also quite active in the terminal emulation world, being the co-developer of one of them. I haven't tried Ghostty yet, I really should, there's a lot of buzz around it. But as far as I understand, regarding compatibility, it follows xterm and the ones that closely follow it (in the last decade or so I have the feeling that the behavior of graphical terminals have converged luckily; if Ghostty is also one of the converging ones as I presume it is (if not then purely due to using TERM=xterm-...), rather than something brand new different incompatible, then we have nothing to worry about.)

[edrozenberg]

Really interesting thanks. Afaik Ghostty is xterm-compatible but uses its own TERM setting in order to provide additional capabilities. In recent months ncurses added Ghostty support so it's no longer necessary to deploy Ghostty's terminfo to remote servers that have an updated ncurses.

Definitely worth trying Ghostty, it's become my main driver over Terminal.app on Mac due to features like the popup Quick Terminal, extended color support, extensive split features (split, split drag handle to reorg splits), and an obsessive focus on being platform native on each platform (Mac, GTK, and I think soon Windows). Big focus on font/special char/intl support. Also becoming scriptable now, and embeddable as terminal engine for other projects. I looked at other terminal apps on Mac in the past but none of them were properly native, they all smelled weird so I stuck with Terminal.app until now.

[egmontkob]

By trying I meant to add it to the dozen-ish terminals whose behavior I check whenever it comes to compatibility questions (e.g. right now which sequences do they generate for various modifiers + keys).

Having been a regular heavy contributor to a terminal for 6+ years and an occasional contributor for another 6+, I'm quite unlikely to switch :)

Anyway, we digressed, let's get back to the real business...