xterm+x11mouse|X11 xterm mouse protocol:\

	:Km=\E[M:

xterm-x11mouse|X11 mouse:\

	:tc=xterm+x11mouse:tc=xterm:

screen+fkeys|function-keys according to screen:\

	:*6@:@0@:@7=\E[4~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:kh=\E[1~:

screen+italics|screen cannot support italics:\

	:ZH@:ZR@:

screen.xterm-xfree86|screen.xterm-new|screen customized for modern xterm:\

	:bw:ut@:\

	:#3@:%c@:%e@:mk@:ml@:mu@:rp@:\

	:..sa=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p5%t;2%;m:\

	:tc=screen+italics:tc=screen+fkeys:tc=xterm+x11mouse:\

	:tc=xterm-new:

ibm+16color|IBM aixterm color definitions:\

	:Co#16:pa#256:\

	:..AB=\E[%?%p1%{8}%<%t%p1%{40}%+%e%p1%{92}%+%;%dm:\

	:..AF=\E[%?%p1%{8}%<%t%p1%{30}%+%e%p1%{82}%+%;%dm:\

	:..Sb=%p1%{8}%/%{6}%*%{4}%+\E[%d%p1%{8}%m%Pa%?%ga%{1}%=%t4%e%ga%{3}%=%t6%e%ga%{4}%=%t1%e%ga%{6}%=%t3%e%ga%d%;m:\

	:..Sf=%p1%{8}%/%{6}%*%{3}%+\E[%d%p1%{8}%m%Pa%?%ga%{1}%=%t4%e%ga%{3}%=%t6%e%ga%{4}%=%t1%e%ga%{6}%=%t3%e%ga%d%;m:

xterm+256setaf|xterm 256-color (set-only):\

	:cc@:\

	:Co#256:pa#65536:\

	:AB=\E[48;5;%dm:AF=\E[38;5;%dm:Ic@:Sb@:Sf@:op=\E[39;49m:

# ======================================================================

# Entries for GNU Screen with 16 colors.

# Those variations permit to benefit from 16 colors palette, and from

# bold font and blink attribute separated from bright colors. But they

# are less portable than the generic "screen" 8 color entries: Their

# usage makes real sense only if the terminals you attach and reattach

# do all support 16 color palette.

screen-16color|GNU Screen with 16 colors:\

	:tc=ibm+16color:tc=screen:

screen-16color-s|GNU Screen with 16 colors and status line:\

	:tc=ibm+16color:tc=SH:

screen-16color-bce|GNU Screen with 16 colors and BCE:\

	:tc=ibm+16color:tc=screen-bce:

screen-16color-bce-s|GNU Screen with 16 colors using BCE and status line:\

	:ut:tc=ibm+16color:tc=SH:

# ======================================================================

# Entries for GNU Screen 4.02 with --enable-colors256.

screen-256color-s|GNU Screen with 256 colors and status line:\

	:tc=xterm+256setaf:tc=SH:

screen-256color-bce|GNU Screen with 256 colors and BCE:\

	:ut:tc=xterm+256setaf:tc=screen-bce:

screen-256color-bce-s|GNU Screen with 256 colors using BCE and status line:\

	:ut:tc=xterm+256setaf:tc=SH:

screen.xterm-256color|GNU Screen with xterm using 256 colors:\

	:tc=xterm+256setaf:tc=screen.xterm-new:

screen.putty-256color|GNU Screen with putty using 256 colors:\

	:tc=xterm+256setaf:tc=screen.putty:

screen.xterm-r6|screen customized for X11R6 xterm:\

	:bw:tc=xterm+x11mouse:tc=screen+fkeys:tc=xterm-r6:

# Color applications running in screen and TeraTerm do not play well together

# on Solaris because Sun's curses implementation gets confused.

screen.teraterm|disable ncv in teraterm:\

	:NC#127:\

	:ac=+\020,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376:\

	:tc=screen+fkeys:tc=xterm+x11mouse:tc=screen:

#### DEC VT100 and compatibles

#

# DEC terminals from the vt100 forward are collected here. Older DEC terminals

# and micro consoles can be found in the `obsolete' section.  More details on

# the relationship between the VT100 and ANSI X3.64/ISO 6429/ECMA-48 may be

# found near the end of this file.

#

# Except where noted, these entries are DEC's official terminfos.

# Contact Bill Hedberg <hedberg@hannah.enet.dec.com> of Terminal Support

# Engineering for more information.  Updated terminfos and termcaps

# are kept available at ftp://gatekeeper.dec.com/pub/DEC/termcaps.

#

# In October 1995 DEC sold its terminals business, including the VT and Dorio

# line and trademark, to SunRiver Data Systems.  SunRiver has since changed

# its name to Boundless Technologies; see http://www.boundless.com.

#

# NOTE:  Any VT100 emulation, whether in hardware or software, almost

# certainly includes what DEC called the `Level 1 editing extension' codes;

# only the very oldest VT100s lacked these and there probably aren't any of

# those left alive.  To capture these, use one of the VT102 entries.

#

# Note that the :xn: glitch in vt100 is not quite the same as on the Concept,

# since the cursor is left in a different position while in the

# weird state (concept at beginning of next line, vt100 at end

# of this line) so all versions of vi before 3.7 don't handle

# :xn: right on vt100. The correct way to handle :xn: is when

# you output the char in column 80, immediately output CR LF

# and then assume you are in column 1 of the next line. If :xn:

# is on, am should be on too.

#

# I assume you have smooth scroll off or are at a slow enough baud

# rate that it doesn't matter (1200? or less). Also this assumes

# that you set auto-nl to "on", if you set it off use vt100-nam

# below.

#

# The padding requirements listed here are guesses. It is strongly

# recommended that xon/xoff be enabled, as this is assumed here.

#

# The vt100 uses <rs2> and <rf> rather than :is:/:ct:/:st: because the

# tab settings are in non-volatile memory and don't need to be

# reset upon login. Also setting the number of columns glitches

# the screen annoyingly. You can type "reset" to get them set.

#

# The VT100 series terminals have cursor ("arrows") keys which can operate

# in two different modes: Cursor Mode and Application Mode.  Cursor Mode

# is the reset state, and is assumed to be the normal state.  Application

# Mode is the "set" state.  In Cursor Mode, the cursor keys transmit

# "Esc [ {code}" sequences, conforming to ANSI standards.  In Application

# Mode, the cursor keys transmit "Esc O <code>" sequences.  Application Mode

# was provided primarily as an aid to the porting of VT52 applications.  It is

# assumed that the cursor keys are normally in Cursor Mode, and expected that

# applications such as vi will always transmit the :ks: string.  Therefore,

# the definitions for the cursor keys are made to match what the terminal

# transmits after the :ks: string is transmitted.  If the :ks: string

# is a null string or is not defined, then cursor keys are assumed to be in

# "Cursor Mode", and the cursor keys definitions should match that assumption,

# else the application may fail.  It is also expected that applications will

# always transmit the :ke: string to the terminal before they exit.

#

# The VT100 series terminals have an auxiliary keypad, commonly referred to as

# the "Numeric Keypad", because it is a cluster of numeric and function keys.

# The Numeric Keypad which can operate in two different modes: Numeric Mode and

# Application Mode.  Numeric Mode is the reset state, and is assumed to be

# the normal state.  Application Mode is the "set" state.  In Numeric Mode,

# the numeric and punctuation keys transmit ASCII 7-bit characters, and the

# Enter key transmits the same as the Return key (Note: the Return key

# can be configured to send either LF (\015) or CR LF).  In Application Mode,

# all the keypad keys transmit "Esc O {code}" sequences.  The PF1 - PF4 keys

# always send the same "Esc O {code}" sequences.  It is assumed that the keypad

# is normally in Numeric Mode.  If an application requires that the keypad be

# in Application Mode then it is expected that the user, or the application,

# will set the TERM environment variable to point to a terminfo entry which has

# defined the :ks: string to include the codes that switch the keypad into

# Application Mode, and the terminfo entry will also define function key

# fields to match the Application Mode control codes.  If the :ks: string

# is a null string or is not defined, then the keypad is assumed to be in

# Numeric Mode.  If the :ks: string switches the keypad into Application

# Mode, it is expected that the :ke: string will contain the control codes

# necessary to reset the keypad to "Normal" mode, and it is also expected that

# applications which transmit the :ks: string will also always transmit the

# :ke: string to the terminal before they exit.

#

# Here's a diagram of the VT100 keypad keys with their bindings.

# The top line is the name of the key (some DEC keyboards have the keys

# labelled somewhat differently, like GOLD instead of PF1, but this is

# the most "official" name).  The second line is the escape sequence it

# generates in Application Keypad mode (where "$" means the ESC

# character).  The third line contains two items, first the mapping of

# the key in terminfo, and then in termcap.

#   _______________________________________

#  |   PF1   |   PF2   |   PF3   |   PF4   |

#  |   $OP   |   $OQ   |   $OR   |   $OS   |

#  |_kf1__k1_|_kf2__k2_|_kf3__k3_|_kf4__k4_|

#  |    7         8         9         -    |

#  |   $Ow   |   $Ox   |   $Oy   |   $Om   |

#  |_kf9__k9_|_kf10_k;_|_kf0__k0_|_________|

#  |    4    |    5    |    6    |    ,    |

#  |   $Ot   |   $Ou   |   $Ov   |   $Ol   |

#  |_kf5__k5_|_kf6__k6_|_kf7__k7_|_kf8__k8_|

#  |    1    |    2    |    3    |         |

#  |   $Oq   |   $Or   |   $Os   |  enter  |

#  |_ka1__K1_|_kb2__K2_|_ka3__K3_|  $OM    |

#  |         0         |   .     |         |

#  |        $Op        |  $On    |         |

#  |___kc1_______K4____|_kc3__K5_|_kent_@8_|

#

# Note however, that the arrangement of the 5-key ka1-kc3 do not follow the

# terminfo guidelines.  That is a compromise used to assign the remaining

# keys on the keypad to kf5-kf0, used on older systems with legacy termcap

# support:

vt100+keypad|dec vt100 numeric keypad no fkeys:\

	:K1=\EOq:K2=\EOr:K3=\EOs:K4=\EOp:K5=\EOn:

screen.Eterm|screen in Eterm:\

	:tc=xterm+x11mouse:tc=screen+fkeys:tc=Eterm:

# fix the backspace key

screen.linux|screen in linux console:\

	:bw:\

	:kB@:kb=\177:tc=xterm+x11mouse:tc=screen+fkeys:tc=screen:

screen.putty|screen in putty:\

	:tc=xterm+x11mouse:tc=screen+fkeys:tc=putty:

# The default "screen" entry is reasonably portable, but not optimal for the

# most widely-used terminal emulators.  The "bce" capability is supported in

# screen since 3.9.13, and when used, will require fewer characters to be sent

# to the terminal for updates.

#

# If you are using only terminals which support bce, then you can use this

# feature in your screen configuration.

#

# Adding these lines to your ".screenrc" file will allow using these customized

# entries:

#	term screen-bce

#	bce on

#	defbce on

screen-bce.xterm-new|screen optimized for modern xterm:\

	:ut:\

	:ec@:tc=screen+italics:tc=screen.xterm-new:

screen-bce.Eterm|screen optimized for Eterm:\

	:ut:\

	:ec@:tc=screen.Eterm:

screen-bce.linux|screen optimized for linux console:\

	:ut:\

	:ec@:tc=screen.linux:

screen2|old VT 100/ANSI X3.64 virtual terminal:\

	:co#80:it#8:li#24:\

	:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\

	:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:al=\E[L:bt=\E[Z:cd=\E[J:\

	:ce=\E[K:cl=\E[2J\E[H:cm=\E[%i%d;%dH:cr=\r:ct=\E[3g:\

	:dc=\E[P:dl=\E[M:do=\E[B:ei=\E[4l:ic=:im=\E[4h:k0=\E~:\

	:k1=\ES:k2=\ET:k3=\EU:k4=\EV:k5=\EW:k6=\EP:k7=\EQ:k8=\ER:\

	:k9=\E0I:kb=^H:kd=\EB:kh=\EH:kl=\ED:kr=\EC:ku=\EA:le=^H:\

	:me=\E[m:nd=\E[C:nw=\r\n:r1=\Ec:rc=\E8:sc=\E7:se=\E[23m:\

	:sf=\n:so=\E[3m:sr=\EM:st=\EH:ta=^I:ue=\E[24m:up=\E[A:\

	:us=\E[4m:

# (screen3: removed unknown ":xv:LP:G0:" -- esr)

screen3|older VT 100/ANSI X3.64 virtual terminal:\

	:km:mi:ms:\

	:co#80:it#8:li#24:\

	:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\

	:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:al=\E[L:bl=^G:bt=\E[Z:\

	:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:cr=\r:\

	:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=\n:ei=\E[4l:\

	:ho=\E[H:im=\E[4h:is=\E)0:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\

	:kb=^H:kd=\EOB:ke=\E>:kl=\EOD:kr=\EOC:ks=\E=:ku=\EOA:le=^H:\

	:mb=\E[5m:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:nw=\EE:r1=\Ec:\

	:rc=\E8:sc=\E7:se=\E[23m:sf=\n:so=\E[3m:sr=\EM:st=\EH:ta=^I:\

	:ue=\E[24m:up=\EM:us=\E[4m:

# screen 4.0 was released 2003-07-21, and as of March 2019, its terminfo file

# was last updated in 2009 to include 256-color support.  The most recent

# release is 4.6.2 (October 2017).

screen4:\

	:tc=screen:

# As of March 2019, screen 5.0 has not been released.

#

# However,

#

#	https://savannah.gnu.org/bugs/?36676

#

# mentions a change to implement italics which should be in a version 5,

# (implemented 2016-11-05, but merged 2017-07-09).  That does away with the

# longstanding use of SGR 3 for standout, and interprets it as italics.

#

# The same development branch has some support for direct-colors, but none

# of this has been documented.

screen5|VT 100/ANSI X3.64 virtual terminal (someday):\

	:..sa=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p5%t;2%;m%?%p9%t\016%e\017%;:\

	:se=\E[27m:so=\E[7m:tc=ecma+italics:tc=screen: