curses: Just use our hardcoded xterm-256color entry as the fallback#10905
curses: Just use our hardcoded xterm-256color entry as the fallback#10905faho merged 1 commit intofish-shell:masterfrom
Conversation
The values we would try are: xterm-256color, xterm, ansi, dumb This is a pretty useless list, because systems without "xterm-256color" but with "ansi" basically don't exist, and it is very likely that the actual terminal is more xterm-compatible than it is ansi. So instead we just use our xterm-256color definition, which has a high likelihood of being basically correct.
|
I am this close to just ditching any and all reading of the terminfo database. I have a script that tries to figure out how different terminfo entries actually are, and the answer is they barely are. The trick is that you need to filter out a lot of entries - those for 1980s hardware terminals and those invented by ncurses (as well as various variants that just repeat the same information). E.g. there is an "ms-terminal" entry for Microsoft's terminal, which is useless because that terminal uses xterm-256color and to a first approximation nobody sets $TERM (nor should they). It is also just flat out incorrect in some ways, like claiming that "cursor_down" is Or the tmux entry which claims that exit_attribute_mode is I am extremely disillusioned with the entire terminfo system and would like to get away from it. |
|
Agreed, thanks. terminfo seems like a needless indirection; instead of standardizing a terminfo sequence-name it's easier to standardize the actual escape-sequences, because that one needs to exist regardless. I don't know much about this; if there is a chance a user wants to keep terminfo for now (as workaround), we could start with an |
kitty is the only modern terminal I know of that maintains a terminfo. |
|
I think foot too, and both support querying terminfo capabilites via |
The values we would try are:
xterm-256color, xterm, ansi, dumb
This is a pretty useless list, because systems without "xterm-256color" but with "ansi" basically don't exist, and it is very likely that the actual terminal is more xterm-compatible than it is ansi.
So instead we just use our xterm-256color definition, which has a high likelihood of being basically correct.