When using foot's official terminfo, alt+[key] outputs wrong characters

[AdRuCo]

Problem

Running vis on the foot terminal emu with foot's provided terminfo, Alt+h gets interpreted as è instead of <M-h>.

EDIT: Setting TERM="xterm-256color" fixes the issue.

System details

• Distro: Void Linux. Edit: Happens on Debian 13 too.
• Window Manager: tested on both River and Sway. Bug happens on both.
• Foot package on Void.
• Void patches out ncurses' terminfo entry for foot, so it doesn't factor in. Real terminfo comes from foot's repo.
• Tested with both us and eu keyboard layouts.
• Tested with both Ghostty and Kitty on River WM. Both work as expected; their TERMs are xterm-ghostty and xterm-kitty, respectively.

ncurses and foot

The foot terminfo definitions in ncurses' lack the non-standard capabilities [sic].

Some distros ship a separate foot-terminfo package that contains a foot-extra terminfo file.

Void patches out de definition from ncurses and ships the foot-terminfo package instead, built from foot's sources.

• Foot's source terminfo file: foot.info.
• Terminfo build instructions.
• IRC logs with dnkl (foot's maintainer). Note: press "Live updates" for better contrast on the chat.

Visidata has the same bug

visidata has this same bug. alt+[key] sends the same wrong characters. Seems related to the handling of meta by foot.

Steps to reproduce

1. Open vis in foot.
2. Enter INSERT mode, then press Alt+h.

Expected results

Vis inserts <M-h>.

What really happens

Vis inserts è.

vis version (vis -v)

vis 0.9 +curses +lua +acl

Terminal name/version

foot version: 1.22.3 -pgo +ime +graphemes -assertions

$TERM environment variable

foot

[dnkl]

The core issue is most likely that vis calls meta(TRUE) in its ncurses backend. This causes ncurses to emit the smm terminfo property (smm == meta-on == turn on meta mode (8th-bit on).

In foot's own terminfo (not the one distributed with ncurses), smm does precisely that, by a) disabling metaSendsEscape (CSI ? 1036 l, and b) ensuring 8-bit really is enabled by emitting CSI ? 1034 h).

The issue does not reproduce with xterm-256color, or any other terminfo that does not have both of those two escapes in their smm property.

Before you say the issue is with foot's terminfo, consider this:

• smm is supposed to enable 8-bit mode, and that's what foot's terminfo does. If we remove CSI 1036 l from smm, the issue wouldn't appear in vis, but it also wouldn't be possible to enter 8-bit mode in foot, using terminfo capabilities.
• xterm itself has the same ("wrong") behavior as described here, when used in its default configuration (where xterm.vt100.metaSendsEscape is false)