+# 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 <xenl> 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
+# <xenl> right on vt100. The correct way to handle <xenl> 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 <xenl>
+# 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 <is2>/<tbc>/<hts> 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 <smkx> string. Therefore,
+# the definitions for the cursor keys are made to match what the terminal
+# transmits after the <smkx> string is transmitted. If the <smkx> 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 <rmkx> 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 <smkx> 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 <smkx> string
+# is a null string or is not defined, then the keypad is assumed to be in
+# Numeric Mode. If the <smkx> string switches the keypad into Application
+# Mode, it is expected that the <rmkx> string will contain the control codes
+# necessary to reset the keypad to "Normal" mode, and it is also expected that
+# applications which transmit the <smkx> string will also always transmit the
+# <rmkx> 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,
+ ka1=\EOq, ka3=\EOs, kb2=\EOr, kc1=\EOp, kc3=\EOn,
+vt100+pfkeys|dec vt100 numeric keypad,
+ kent=\EOM, kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
+ use=vt100+keypad,
+vt100+fnkeys|dec vt100 numeric keypad,
+ kf0=\EOy, kf10=\EOx, kf5=\EOt, kf6=\EOu, kf7=\EOv, kf8=\EOl,
+ kf9=\EOw, use=vt100+pfkeys,
+#
+# A better adaptation to modern keyboards such as the PC's, which have a dozen
+# function keys and the keypad 2,4,6,8 keys are labeled with arrows keys, is to
+# use the 5-key arrangement to model the arrow keys as suggested in the
+# terminfo guidelines:
+# _______________________________________
+# | PF1 | PF2 | PF3 | PF4 |
+# | $OP | $OQ | $OR | $OS |
+# |_kf1__k1_|_kf2__k2_|_kf3__k3_|_kf4__k4_|
+# | 7 8 9 - |
+# | $Ow | $Ox | $Oy | $Om |
+# |_ka1__K1_|_________|_ka3__K3_|_________|
+# | 4 | 5 | 6 | , |
+# | $Ot | $Ou | $Ov | $Ol |
+# |_________|_kb2__K2_|_________|_________|
+# | 1 | 2 | 3 | |
+# | $Oq | $Or | $Os | enter |
+# |_kc1__K4_|_________|_kc3__K5_| $OM |
+# | 0 | . | |
+# | $Op | $On | |
+# |___________________|_________|_kent_@8_|
+#
+vt220+keypad|dec vt220 numeric keypad,
+ ka1=\EOw, ka3=\EOy, kb2=\EOu, kc1=\EOq, kc3=\EOs, kent=\EOM,
+ kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS, ka2=\EOx, kb1=\EOt,
+ kb3=\EOv, kc2=\EOr,
+#
+vt100+enq|ncurses extension for vt100-style ENQ,
+ u8=\E[?1;2c, use=ansi+enq,
+vt102+enq|ncurses extension for vt102-style ENQ,
+ u8=\E[?6c, use=ansi+enq,
+#
+# And here, for those of you with orphaned VT100s lacking documentation, is
+# a description of the soft switches invoked when you do `Set Up'.
+#
+# Scroll 0-Jump Shifted 3 0-#
+# | 1-Smooth | 1-British pound sign
+# | Autorepeat 0-Off | Wrap Around 0-Off
+# | | 1-On | | 1-On
+# | | Screen 0-Dark Bkg | | New Line 0-Off
+# | | | 1-Light Bkg | | | 1-On
+# | | | Cursor 0-Underline | | | Interlace 0-Off
+# | | | | 1-Block | | | | 1-On
+# | | | | | | | |
+# 1 1 0 1 1 1 1 1 0 1 0 0 0 0 1 0 <--Standard Settings
+# | | | | | | | |
+# | | | Auto XON/XOFF 0-Off | | | Power 0-60 Hz
+# | | | 1-On | | | 1-50 Hz
+# | | ANSI/VT52 0-VT52 | | Bits Per Char. 0-7 Bits
+# | | 1-ANSI | | 1-8 Bits
+# | Keyclick 0-Off | Parity 0-Off
+# | 1-On | 1-On
+# Margin Bell 0-Off Parity Sense 0-Odd
+# 1-On 1-Even
+#
+# The following SET-UP modes are assumed for normal operation:
+# ANSI_MODE AUTO_XON/XOFF_ON NEWLINE_OFF 80_COLUMNS
+# WRAP_AROUND_ON JUMP_SCROLL_OFF
+# Other SET-UP modes may be set for operator convenience or communication
+# requirements; I recommend
+# AUTOREPEAT_ON BLOCK_CURSOR MARGIN_BELL_OFF SHIFTED_3_#
+# Unless you have a graphics add-on such as Digital Engineering's VT640
+# (and even then, whenever it can be arranged!) you should set
+# INTERLACE_OFF
+#
+# (vt100: I added <rmam>/<smam> based on the init string, also <OTbs>. -- esr)
+vt100|vt100-am|dec vt100 (w/advanced video),
+ OTbs, mc5i, xenl, xon,
+ vt#3,
+ csr=\E[%i%p1%d;%p2%dr, kcub1=\EOD, kcud1=\EOB,
+ kcuf1=\EOC, kcuu1=\EOA, lf1=pf1, lf2=pf2, lf3=pf3, lf4=pf4,
+ mc0=\E[0i, mc4=\E[4i, mc5=\E[5i, rc=\E8, rmam=\E[?7l,
+ rmkx=\E[?1l\E>, rs2=\E<\E>\E[?3;4;5l\E[?7;8h\E[r,
+ sc=\E7,
+ sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5
+ %;m%?%p9%t\016%e\017%;$<2>,
+ smam=\E[?7h, smkx=\E[?1h\E=, smso=\E[7m$<2>,
+ use=vt100+4bsd, use=vt100+fnkeys,
+vt100+4bsd|dec vt100 from 4.0BSD,
+ am, msgr,
+ cols#80, it#8, lines#24,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
+ clear=\E[H\E[J$<50>, cr=\r, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C$<2>,
+ cup=\E[%i%p1%d;%p2%dH$<5>, cuu=\E[%p1%dA,
+ cuu1=\E[A$<2>, ed=\E[J$<50>, el=\E[K$<3>, el1=\E[1K$<3>,
+ enacs=\E(B\E)0, home=\E[H, ht=^I, hts=\EH, ind=\n, kbs=^H,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O, rmso=\E[m$<2>,
+ rmul=\E[m$<2>, rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
+ sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5
+ %;m%?%p9%t\016%e\017%;$<2>,
+ sgr0=\E[m\017$<2>, smacs=^N, smso=\E[1;7m$<2>,
+ smul=\E[4m$<2>, tbc=\E[3g,
+vt100nam|vt100-nam|vt100 no automargins,
+ am@, xenl@,
+ rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7l\E[?8h, use=vt100-am,
+vt100-vb|dec vt100 (w/advanced video) & no beep,
+ bel@, flash=\E[?5h$<100/>\E[?5l, use=vt100,