dnkl/foot
41
2.0k
Fork
You've already forked foot
243

Terminal state is not properly cleared after leaving mutt #2393

Closed
opened 2026年06月21日 14:45:45 +02:00 by nikolas · 3 comments

Foot Version

foot version: 1.27.0 +pgo +ime +graphemes +toplevel-tag +blur -assertions

TERM environment variable

foot

Compositor Name and Version

labwc 0.20.1-1-gff95d7f5 (+xwayland +nls +rsvg +libsfdo) wlroots-0.20.1

Distribution

Debian testing

Terminal multiplexer

No response

Shell, TUI, application

bash

Server/standalone mode

  • Standalone
  • Server

Foot config

Default

Description of Bug and Steps to Reproduce

Steps to reproduce:

  • Open foot
  • Word navigation using alt-f and alt-b is usable within the bash shell
  • Open mutt
  • Quit mutt
  • alt-f and alt-b are no longer usable. These commands now insert æ and â characters.

See mutt bug: https://gitlab.com/muttmua/mutt/-/work_items/528

Relevant logs, stacktraces, etc.

No response

### Foot Version foot version: 1.27.0 +pgo +ime +graphemes +toplevel-tag +blur -assertions ### TERM environment variable foot ### Compositor Name and Version labwc 0.20.1-1-gff95d7f5 (+xwayland +nls +rsvg +libsfdo) wlroots-0.20.1 ### Distribution Debian testing ### Terminal multiplexer _No response_ ### Shell, TUI, application bash ### Server/standalone mode - [x] Standalone - [ ] Server ### Foot config Default ### Description of Bug and Steps to Reproduce Steps to reproduce: * Open foot * Word navigation using alt-f and alt-b is usable within the bash shell * Open mutt * Quit mutt * alt-f and alt-b are no longer usable. These commands now insert æ and â characters. See mutt bug: https://gitlab.com/muttmua/mutt/-/work_items/528 ### Relevant logs, stacktraces, etc. _No response_
Owner
Copy link

Sorry, but this isn't a bug in foot either :)

First, I think the real problem is that if mutt is calling meta(TRUE), it also needs to call meta(FALSE), to restore that. If you read the man page for meta(), it says that if the terminfo defines meta_on (smm), it will be emitted for TRUE, and likewise rmm will be emitted for FALSE. It does not say that calling endwin() restores anything, or calls meta() automatically in anyway.

Likewise, the man page for endwin() does not mention meta being restored (but does mention what else it restores).

Second, it "works" with TERM=xterm-256color because its smm enables private mode 1034 (eight bit) but does not disable private mode 1036 - esc prefixed ALT keys. This means ALT-keys are still ESC-prefixed, in both foot and xterm.

You can see this in xterm (with TERM=xterm-256color) by running tput smm && showkey -a, then press alt-b, alt-f. You'll see esc-prefixed sequences. Compare that with tput smm && printf "\e[?1036l" && showkey -a - now you get eight-bit characters, without the esc prefix. If I read the mutt issue correctly, that's what it wants (but not actually getting...).

Sorry, but this isn't a bug in foot either :) First, I think the real problem is that if mutt is calling `meta(TRUE)`, it also needs to call `meta(FALSE)`, to restore that. If you read the man page for `meta()`, it says that if the terminfo defines `meta_on` (`smm`), it will be emitted for `TRUE`, and likewise `rmm` will be emitted for `FALSE`. It does _not_ say that calling `endwin()` restores anything, or calls `meta()` automatically in anyway. Likewise, the man page for `endwin()` does **not** mention meta being restored (but does mention what else it restores). Second, it "works" with `TERM=xterm-256color` because its `smm` enables private mode 1034 (eight bit) but **does not disable private mode 1036 - esc prefixed ALT keys**. This means ALT-keys **are still ESC-prefixed**, in both foot and xterm. You can see this in xterm (with `TERM=xterm-256color`) by running `tput smm && showkey -a`, then press alt-b, alt-f. You'll see esc-prefixed sequences. Compare that with `tput smm && printf "\e[?1036l" && showkey -a` - now you get eight-bit characters, without the esc prefix. If I read the mutt issue correctly, that's what it wants (but not actually getting...).
Owner
Copy link

First, I think the real problem is that if mutt is calling meta(TRUE), it also needs to call meta(FALSE), to restore that. If you read the man page for meta(), it says that if the terminfo defines meta_on (smm), it will be emitted for TRUE, and likewise rmm will be emitted for FALSE. It does not say that calling endwin() restores anything, or calls meta() automatically in anyway.

"Verified" with this super simple test program. Without the meta(win, FALSE) at the end, rmm is not emitted, and esc-prefixing is not restored.

#include <curses.h>
int
main(int argc, const char *const *argv)
{
 WINDOW *win = initscr();
 meta(win, TRUE);
 meta(win, FALSE); /* Remove to trigger bug */
 endwin();
}
> First, I think the real problem is that if mutt is calling meta(TRUE), it also needs to call meta(FALSE), to restore that. If you read the man page for meta(), it says that if the terminfo defines meta_on (smm), it will be emitted for TRUE, and likewise rmm will be emitted for FALSE. It does not say that calling endwin() restores anything, or calls meta() automatically in anyway. "Verified" with this super simple test program. Without the `meta(win, FALSE)` at the end, `rmm` is **not** emitted, and esc-prefixing is **not** restored. ```c #include <curses.h> int main(int argc, const char *const *argv) { WINDOW *win = initscr(); meta(win, TRUE); meta(win, FALSE); /* Remove to trigger bug */ endwin(); } ```
dnkl 2026年06月21日 20:15:57 +02:00
Owner
Copy link

You can see this in xterm...7

This assumes you have xterm.vt100.metaSendsEscape: true (most people do). Otherwise no alt-combos are ever esc prefixed in xterm.

You can get the same effect though, by manually enabling esc-prefixed alt-combos: printf "\e[?1036h" && tput smm && showkey -a

> You can see this in xterm...7 This assumes you have `xterm.vt100.metaSendsEscape: true` (most people do). Otherwise no alt-combos are ever esc prefixed in xterm. You can get the same effect though, by manually enabling esc-prefixed alt-combos: `printf "\e[?1036h" && tput smm && showkey -a`
Sign in to join this conversation.
No Branch/Tag specified
master
osc-5522
sixel-heap-buffer-overflow
releases/1.27
releases/1.26
releases/1.25
releases/1.24
multi-cursor
releases/1.23
pixman-16f-2
releases/1.22
releases/1.21
releases/1.20
releases/1.19
releases/1.18
releases/1.17
releases/1.16
releases/1.15
releases/1.14
releases/1.13
releases/1.12
releases/1.11
releases/1.10
releases/1.9
releases/1.8
releases/1.7
releases/1.6
releases/1.5
releases/1.4
releases/1.3
releases/1.2
releases/1.1
releases/1.0
1.27.0
1.26.1
1.26.0
1.25.0
1.24.0
1.23.1
1.23.0
1.22.3
1.22.2
1.22.1
1.22.0
1.21.0
1.20.2
1.20.1
1.20.0
1.19.0
1.18.1
1.18.0
1.17.2
1.17.1
1.17.0
1.16.2
1.16.1
1.16.0
1.15.3
1.15.2
1.15.1
1.15.0
1.14.0
1.13.1
1.13.0
1.12.1
1.12.0
1.11.0
1.10.3
1.10.2
1.10.1
1.10.0
1.9.2
1.9.1
1.9.0
1.8.2
1.8.1
1.8.0
1.7.2
1.7.1
1.7.0
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.4
1.5.3
1.5.2
1.5.1
1.5.0
1.4.4
1.4.3
1.4.2
1.4.1
1.4.0
1.3.0
1.2.3
1.2.2
1.2.1
1.2.0
1.1.0
1.0.0
0.9.0
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dnkl/foot#2393
Reference in a new issue
dnkl/foot
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?