xterm and mintty) and add an option to make tmux send it. Only forward
extended keys if the application has requested them, even though we use
the CSI u sequence and xterm uses CSI 27 ~ - this is what mintty does as
well.
get XT added and using that as a marker for xterm(1)-like, assume that
if the terminfo(5) entry already has XT or the clear capability starts
with CSI then the terminal is VT100-like and it should be safe to send
DA requests. The DA responses trigger additional features being added.
added and using that as a marker for xterm(1)-like, assume that if the
terminfo(5) entry already has XT or the clear capability starts with CSI then
the terminal is VT100-like and it should be safe to send DA requests. The DA
responses trigger additional features being added.
This is all to detect extensions if terminfo(5) is wrong or inadequate. If it
fails, tmux will just fall back to using the capabilities in the terminfo(5)
entry alone.
terminal features, each of which are defined in one place and map to a
builtin set of terminfo(5) capabilities. Features can be specified based
on TERM with a new terminal-features option or with the -T flag when
running tmux. tmux will also detect a few common terminals from the DA
and DSR responses.
This is intended to make it easier to configure tmux's use of
terminfo(5) even in the presence of outdated ncurses(3) or terminfo(5)
databases or for features which do not yet have a terminfo(5) entry.
Instead of having to grok terminfo(5) capability names and what they
should be set to in the terminal-overrides option, the user can
hopefully just give tmux a feature name and let it do the right thing.
The terminal-overrides option remains both for backwards compatibility
and to allow tweaks of individual capabilities.
tmux already did much of this already, this makes it tidier and simpler
to configure.
