As I've alluded to before, I think we should stop listening to the terminfo database entirely. This is because:

• we barely use it
• it is frequently wrong
• it is massively incomplete and shows no signs of improving
• it does not have versioning so old entries remain in use even on new terminals
• it would remove a dependency and make fish more resilient to misconfiguration and over ssh
• it is a source of confusion

We've already stopped using its keys except for when you use bind -k, and that's slated to be removed with #11342. The rest of the sequences we use basically do not differ usefully between terminals in actual use.

Quantifying this is pretty annoying, mostly because terminfo is full of ancient guff and misinformation. A lot of the entries are made up to describe terminals that use xterm-256color (these are wrong very often - see "konsole" and "ms-terminal"). I will be discounting these entirely. If an entry isn't used by a terminal by default it isn't used (one exception being tmux-256color - tmux at least used to tell people to switch to that if they had it)

The sequences we use are:

Now, excluding the keys, the terminfo entries that are exactly the same as xterm-256color are: alacritty foot ghostty hterm-256color rio terminology xterm-ghostty

Excluding the sequences that we only remove from text for measuring runs adds contour mintty xterm-kitty - a lot of these just don't have "enter_secure_mode" and similar. I don't believe I've ever seen them used anywhere.

And then there are a lot of differences that are just incorrect. They're either actively wrong (and don't work like that), or they're useless because the terminal also understands the xterm-256color sequence. These include e.g.

tmux-256color
        cursor_up: '\EM', '\E[A'.
        exit_attribute_mode: '\E[m^O', '\E(B\E[m'.

All of these work in tmux, so we can just treat it like xterm-256color. Sometimes they're also just cosmetic differences - rxvt-unicode-256color lists exit_attribute_mode: '\E[m\E(B instead of '\E(B\E[m', but that's just the two parts of the sequence swapped.

Some sequences just do not differ at all in any terminal made after the 80s - e.g. "init_tabs" and "auto_right_margin" don't have any differences in any of the entries that feature at least 256 colors (as a proxy for "modern"). There are terminals that list a difference for "eat_newline_glitch", I don't believe them (because it includes wezterm, which uses xterm-256color). In other cases the sequence is marked as "NULL" but the terminal correctly ignores it, so we can just use it.

If anyone wants, I have written a script that I could share that lists a bunch of differences, I can go through each and every one and explain why exactly it is useless.

The only vaguely sensible remaining use of terminfo is to turn off color. That's a bit weird for us because it makes any use of set_color non-functional. We might want to support $NO_COLOR instead. A better solution is the "Almost no color" theme because we can't really do autosuggestions or marking the current entry in the pager without color.

So I propose we:

• remove the terminfo crate dependency
• keep the xterm-256color sequences for what we use them for (but remove init_tabs/auto_right_margin/eat_newline_glitch and other pointless ones)
• if necessary add our own quirks like we already do for things that terminfo doesn't specify

The only sequences where we even add any arguments are set_a_foreground/background, and in those cases we don't need the terminfo DSL, we can just sprintf("\x1b[%dm", number). We already do that for 24-bit color and it's worked fine for years.

This will cut off fish use on the Data General Dasher D220 and Wyse WY-350 for good. To be honest: I am fine with that. It is not a usecase I am interested in. Retrocomputing is neat, but I ain't spendin' any time on it. If it turns out we don't agree on that, we presumably need to keep using terminfo, but I don't believe fish is functional there to begin with.